studiojmc.com » Web Design

Using variables in CSS style sheets

studioJMC — Thu, 18 Oct 2007 19:09:17 +0000

Tutorial Difficulty: Moderate – requires basic CSS and PHP skills, requires PHP enabled webserver

CSS style sheets are wonderful things. They offer greater design control than traditional HTML and make it possible to change the look and feel of an entire website by changing only one file. Of course that power comes at a cost. CSS has a steep learning curve and editing a style sheet, especially one you didn’t create, can be a difficult process.

The good news is there is a solution to those problems that requires only a limited knowledge of PHP scripting to implement: using variables in your style sheets. The bad news is, of course, that CSS doesn’t allow for variables. This post will show you how to get around that limitation.

Using PHP to generate a CSS file.

One advantage of CSS is that your styles can be kept in a separate file from the pages that use them. This is simply a text file that ends with the .css suffix such as style.css. The suffix tells the server to treat the contents of the file as CSS. Unfortunately, the CSS standard doesn’t allow for variables within a .css file. The solution is to use a PHP file, such as style.php and include code to let the server know that the contents of the file should be treated as CSS. This can be accomplished by including the following line of PHP at the top of the style sheet;

Your style definitions can then follow so that the top of your style.php document looks something like this:

a:link { text-decoration : none; color : # #FF0000; }
a:active { text-decoration : underline; color : # #FF0000; }
a:visited { text-decoration : none; color : # #FF0000; }
a:hover { text-decoration : underline; color : #660000; }

Your .php style sheet will now function exactly like a .css one. We’ll get to the variables in a minute but first…

Linking to your .php style sheet

You can link to your .php style sheet exactly as you would a regular style sheet. Here’s the code I placed in the section of my webpage:

Using variables in your style.php file

The advantage of a PHP style sheet is that it allows you to define variables and then use those variables throughout your style sheet. So, for the example I gave above where the a:link, a:active and a:visited styles all use the same color (#3366cc), we could define a “$linkColor” variable (The “$” before linkColor simply indicates it is a variable.) and use it in all three styles. The variable definition would look like this:

$linkColor = ‘# #FF0000;
?>

Remember all PHP code must be contained within a php tag which opens with “”

We can now insert the variable into our css code like this:

Notice the opening and closing php tags.

So the beginning of our CSS file now looks like this:

$ linkColor = ‘# #FF0000;
?>

a:link { text-decoration : none; color : ; }
a:active { text-decoration : underline; color : ; }
a:visited { text-decoration : none; color : ; }
a:hover { text-decoration : underline; color : #000021; }

Now to change the color of the a:link, a:active and a:visited links from red (#FF0000) to blue (#0000FF) we need only change the definition of $linkColor:

$ linkColor = ‘# #0000FF;
?>

A word about variables and variable names

It should be easy to see how this trick can make editing your style sheets a lot easier. What’s less obvious (at least initially) is that, if you create a variable for every possible style, your variable list will soon become nearly as complicated and confusing as your original style sheet. Here are a couple tips to keep things simple:

Build your color palette carefully so that you can color as many pieces of the design as possible using the same variable. For instance, if your header, footer and sidebar will be the same color, you can use the same variable (perhaps $secondColor) to define them.
Don’t be too specific with your variable names. You don’t want to use the variable name $red, if you might be changing it to blue later on. Similarly, you probably don’t want to use the variable name $headerColor if the variable is also used for the footer and sidebar. I prefer names such as $themeColor, $hiliteColor, etc.
Plan carefully so that you don’t force yourself into a situation where your type and background have insufficient contrast. In spite of #1 above, you might sometimes need to define more than one variable with the same color to provide future flexibility.
Use PNG graphics for images that are partially transparent. Since PNGs offer true transparency, you can create a drop shadow that will work over any background color. That’s important if you’ll be changing those background colors. Just remember, you need to use a png javascript fix for PNGs to display properly in Explorer 6.

That should get you started. In the next post, I’ll show how to take this one step further by using style variables in WordPress blog themes.

Monitor Resolutions Revisited

studioJMC — Tue, 02 Oct 2007 21:02:00 +0000

I recently had occasion to take another look at the screen resolutions of visitors to the websites I monitor. I used Google Analytics to check the percentage of user with 800 x 600 pixel monitors who visited 9 sites during September. While the results weren’t surprising, they did represent a milestone. For the first time ever all of the sites I checked had fewer than ten percent of users viewing the site with an 800 x 600 monitor. Seven of the sites were at 6% or less with the other two hovering around 9%.

So as I said in my August post, I think it’s safe to say that 1024 x 768 is the new 800 x 600. And I’m standing by my prediction that the percentage of users with the smaller monitor will drop to 5% or less for all my sites by the end of the year.

Coding IS Part of Web Design

studioJMC — Fri, 06 Jul 2007 13:33:51 +0000

My recent post, 50 Common Web Design Mistakes elicited this comment from Wild over at Digg:

These are programming mistakes. Not DESIGN mistakes.

Maybe I sound a bit arrogant, but their [sic]is a difference between a web designer and a web programmer. Its [sic] one the industry needs to understand as it leads to a lot of confusion when it comes to hiring people.

I suppose, if my definition of web design was limited to arranging pixels, I might agree with him but there is more to web design than making pretty pictures on a monitor. According to (who else) Wikipedia, design

…normally requires a designer [to consider] aesthetic, functional, and many other aspects of an object or process…

It’s the “functional, and many other aspects” of web design that people like Wild ignore. In this area I grudgingly give credit to the “experience design” movement for recognizing that the ultimate purpose of design is not to create a printed piece of paper, an attractive arrangement of pixels or an imposing building. The purpose of design is to create an interaction with, or experience for, the end-user using those created objects (real and virtual).

So, in my world, misused HTML tags, typos, broken links, etc. are just as much design errors as choosing the wrong shade of magenta. They are design errors because they negatively affect the end user’s experience.

Wild’s error is to equate design with the creation of work that looks great in static portfolios and awards magazines while ignoring the fact that websites (and even printed pieces) actually need to FUNCTION in a dynamic environment. In reality, the true web design process includes not only the visual look of the pages but also elements such as page titles, valid coding and even “off-page” factors that affect the user experience.

Worse yet, Wild appears to believe that coding skills are valued by employers seeking web designers because of “confusion when it comes to hiring people.” Perhaps, once this confusion is cleared up, Wild and like-minded designers will take their rightful place at the forefront of web development but, in the mean time, I’d recommend learning HTML and CSS along with the history of typography.

The truth is most web designers are not coming from traditional design backgrounds. Instead they are Design Refugees who have migrated to design from other professions including (dare I say it) programming. Even those coming to web design from traditional design careers are likely to be self-taught coders.

The reason is obvious. Given a choice between a beautiful but broken website and an attractive and functional one, most companies choose functional (at least the second time around). Why pay a web “designer” who can’t tell his tag from a hole in the ground to create a design that the “programmers” might not be able to implement and will likely change anyway?

This is not to denigrate traditional graphic design. Design school basics like typography and color theory SHOULD be part of web design. But the fact is that print designers and design schools have been slow to recognize the importance of the web. They view it as a poor stepchild to “real” design rather than its future.

This is unfortunate because the next generation of web designers is being trained now and most design programs are woefully unprepared for the task. They are churning out graduates who can design attractive web pages but can’t design functional web sites. On the other hand, the Design Refugees who understand the workings of HTML, CSS and other web technologies but might not know the difference between Bodoni and Bologna are creating functional (and often very attractive) web sites and getting the design jobs.

Wild can blame it on “confusion” but, in my book, he’s the one who is confused.

Design Consideration: Monitor Resolutions

studioJMC — Thu, 05 Jul 2007 22:54:56 +0000

While putting this site together, my son and I engaged in an argument about the ideal width of web pages.

Based upon the standard advice I give my web design students I argued for a 760 pixel width which, even with scroll bars, can easily be accommodated on an 800 by 600 pixel monitor.

He, on the other hand, argued for a wider design – somewhere in the neighborhood of 960 pixels. The advantages were obvious: we’d have additional design flexibility and be able to move to a three-column design. He also argued that people with small monitors just weren’t worth worrying about (he can be a bit judgmental).

The argument was brief and I won (it’s my site after all). Based upon other websites I monitor, I was expecting 5 to 10 percent of my audience to be using the smaller monitors and I wasn’t willing to alienate them. The result was the narrower, two-column design you’re looking at now.

The numbers are in

Now that we’ve been around for a month and had a few thousand visitors, I decided to check my Google Analytics stats and see if I’d made the right decision. It turns out the answer is an emphatic NO! Of our first 3,845 visitors only 26 (0.67 percent) had monitors narrower than 1024 pixels.

Where I went wrong

In retrospect, it appears I violated one of my own cardinal rules: consider your audience. I based my decision on numbers generated by websites targeted to a general audience. I didn’t consider that an audience of graphic design and web professionals would naturally tend to have larger (in many cases much larger) monitors.

Looking ahead

One month isn’t a scientific sample and, as time goes by, I expect we will reach a wider audience and see the number of visitors using small monitors rise a bit. Still, the numbers are impressive enough that I’m already starting to look at a redesign. After all, if I can offer a better experience to 99 percent of our audience, perhaps the 0.67 percent of designers who won’t spring for a new monitor once a decade really aren’t worth worrying about.

So, son, if you’re reading, here it is: I was wrong and you were right.

50 Common Web Design Mistakes

studioJMC — Tue, 26 Jun 2007 23:36:38 +0000

This started out as a “Top Ten Newbie Web Mistakes” for my beginning web design students but it quickly became obvious that I couldn’t limit it to only ten. I was finally able to edit it down to 50. But I suspect, as soon as the comments start, it will begin growing again.

And, yes, I’ve made them all at one time or another.

Page Titles

1. Untitled documents: “Untitled Document” is the default title for pages created in Dreamweaver and other web design programs. Too many people forget to change it (see My Favorite Google Search).

2. Same title for all pages: The title is important. Help the world know which of your pages they want to see.

3. Non-descriptive titles: The page title is the headline for your link in search results (not to mention an important factor in determining those results). Instead of “Jim’s Page” try something like “Cartoons and Illustrations by Jim” or better yet “Political Cartoons.”

Meta Tags

4. Duplicate meta information on all pages: The keywords and description meta tags in the head of your page help search engines categorize your page. If you duplicate the tags across all pages of your site, they will look alike to searchers. Customize the keywords and descriptions for each page or don’t use them at all.

Site Structure

5. No index.html (or equivalent) in the root directory: By default the index.html (or an equivalent such as index.htm, index.php, default.htm, etc.) is displayed when you visit http://www.yourdomain.com. If you don’t include it, visitors will get an error message or be required to type out the full URI including the file name.

6. Disorganized file structure: How you organize your site files won’t affect what the site looks like but lack of organization can make your life hell down the road when you’re trying to update or redesign the site. Use directories (folders) to help organize your pages and images.

7. Uploading non-web files: Accidentally uploading a few native Photoshop files can eat up your disk space quickly (not to mention take forever). Store your resource files (Photoshop images, Word files, etc.) in a separate folder outside your local web folder.

Pages

8. “Under Construction” pages: If a page isn’t ready to post, don’t post it. If you can’t help yourself, remember “Under Construction” is supposed to be a temporary condition and, after a month or, so it starts to seem permanent.

9. Frames: There are good reasons why you might want to use frames but there are no good reasons to actually use them.

10. Horizontal scrolling: The least common denominator for monitor width is currently 800 pixels. You also need to leave space for scroll bars, page margins etc. so 760 pixels is a good standard width for your web pages. Wider may be acceptable depending upon your target audience but be careful!

11. Worthless content: If you don’t have anything to say, then don’t say it.

12. Out-of date content: If your content is no longer timely, delete it and, if you’re going to include a copyright notice, update it each January.

13. Overly long pages: Contrary to popular belief, there’s nothing wrong with long web pages (that’s what the scroll bar is for) if the content warrants it. But, if it can be done logically, it’s usually a good idea to have several shorter pages than one very long one. If you do have very long pages, provide additional navigation to make it easy for readers to move within or off the page (such as a simplified menu of text links at the bottom of the page).

14. Unnecessarily short pages: In an effort to make the content “fit” the design, designers often resort to a series of short pages when one long one would be more user-friendly.

15. “Orphan” pages: Pages you forget to provide links to don’t exist as far as the rest of the world is concerned.

16. “Alien” pages: Pages that completely ignore the look and feel of the rest of your website leave users feeling like they’ve been suddenly transported to a website far, far away.

Navigation, navigation, who’s got the navigation?

17. Pages without navigation: If you don’t offer them an option, visitors are more likely to close your page than to hit the browser’s “Back” button.

18. Broken links: ‘Nuff said!

19. “Hidden” links: Make links easily identifiable by using a contrasting color, underlining them, using “button” images or altering the rollover state.

20. “False” links: Underlined text and rollover images scream link. Use them cautiously.

21. Menus that move: Establish consistent “navigation zones” and stick with them.

22. Inconsistent navigation: Once the user learns how to use your site’s navigation, don’t change it on him.

Headlines

23. Restyling text instead of using heading tags:

is not the same as big paragraph text.

24. Using heading tags for design: Headings are structural elements and should be used to define the purpose of the text they enclose. Don’t use them just because you want big bold text.

Body Text

25. Using images for text: Text in images can’t be read by search engines or screen readers.

26. Justified type: It’s hard enough to make justified text look presentable on a static printed page. On a dynamic web page it’s nearly impossible.

27. Using

instead of

: It will make formatting difficult.

28. Using
to control line breaks within paragraphs: Let the browser determine where your lines break within paragraphs. If you force the issue you may get strange results as not all browsers size type exactly the same.

29. Typos and grammatical errors: use your spell checker and check out 10 flagrant grammar mistakes that make you look stupid.

30. Type too small: Really, 9 point type on a printed page isn’t comfortable for most people. On screen it’s unreadable for anyone over 30. Except for the “small type” you’re trying to make unreadable 12 points (or even 14) should be your minimum.

31. Too little contrast between text and background: It’s really hard to read!

32. Using non-breaking spaces to align type: For tabular data use tables. To position type as a design element use CSS styles.

33. “Ransom” note styling: Using too many fonts, too many styles, too many weights, too many sizes and too many colors is simply too much.

Images

34. Images without the alt attribute: Search engines, screen readers, and that little text box that sometimes pops up when your mouse is over an image all use the alt attribute. You should too.

35. Jigsaw puzzle graphics: Don’t slice images more than necessary. Each slice requires an extra call to the server.

36. Resizing images in the browser: Size your images in your image editing program before placing them on your pages. Images that are blown up in the browser lose quality and images that are reduced in the browser increase the loading time of a page. For example, a 1 inch by 1 inch image loads 4 times quicker than a 2 inch by 2 inch image, even if they are displayed at the same size.

37. Improper image format: JPEGs are best for photos and continuous tone images. GIFs are best for images with large areas of flat color. Also, transparent GIFs are prone to “ghosting” if used incorrectly.

38. Use of transparent PNGs without Explorer fix: PNGs offer true transparency but it doesn’t work properly in Explorer 6 without a javascript fix.

Animations

39. Gratuitous Flash: No matter how fantastic your Flash splash page is, nobody really wants to watch it more than once. If you must “Flash” yourself, at least provide a “skip animation” link.

40. Non-stop animations: Let your animation cycle a few times and then stop it before it gets overly annoying.

41. Too many animations: More than one animation on a page is just annoying.

42. Use of the tag: Thankfully some browsers ignore it.

Philosophy

43 “Sheet of paper” pages: Your screen is not eight-and-a-half inches wide, things don’t necessarily stay where you put them and, when you get to the bottom, you can scroll. Take advantage of the design possibilities those attributes and others offer.

44 Confusing content and design: HTML tags (p, h1, h2, etc.) are structural elements and, by themselves, say nothing about how your page should look (see for example…). Organize your content using HTML and create the design of your pages with CSS (and maybe a table if absolutely necessary).

Miscellaneous

45. No contact information: The purpose of a website is communication. Right? Make sure people have a way to contact you if they’re interested in your work, product or service.

46. Reliance on email links: E-mail links only work if the user has an email program available and correctly configured. And they don’t work with G-mail and similar services. So people in libraries or school labs can’t use them. Most ISPs offer a form processing script that can convert the contents of a form to an email and send it to you. Use it.

47. Failure to respond to contacts: Sure you can ignore spam but, when a legitimate visitor takes the time to contact you, a prompt reply is just good manners.

48. Auto-play sounds: Unexpected sounds are annoying especially in an office or classroom.

49. Opening too many windows: Cluttering up someone’s screen with a new window every time they click on a link is just bad manners.

50. Failure to check for cross-browser inconsistencies: Your site should work on Macs and Windows, in Explorer, Firefox and Safari. If it doesn’t you’ll drive visitors away.