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;
<?php header(”Content-type: text/css”); ?>
Your style definitions can then follow so that the top of your style.php document looks something like this:
<?php header(”Content-type: text/css”); ?>
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 <head> section of my webpage:
<link href=”style.php” rel=”stylesheet” type=”text/css” />
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:
<?php header(”Content-type: text/css”);
$linkColor = ‘# #FF0000;
?>
Remember all PHP code must be contained within a php tag which opens with “<?php” or simply “<?” and closes with “?>”
We can now insert the variable into our css code like this:
<?=$linkColor?>
Notice the opening and closing php tags.
So the beginning of our CSS file now looks like this:
<?php header(”Content-type: text/css”);
$ linkColor = ‘# #FF0000;
?>a:link { text-decoration : none; color : <?=$ linkColor?>; }
a:active { text-decoration : underline; color : <?=$ linkColor?>; }
a:visited { text-decoration : none; color : <?=$ linkColor?>; }
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:
<?php header(”Content-type: text/css”);
$ 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.
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.
I recently became involved in an interesting thread in the AIGA Design Education online discussion group. Basically the topic was the increasing complexity and bloating of design software. Here’s a few relevant comments from the discussion:
graphicdavid started it off:
“… it seems that Adobe is making the software increasingly
complex, instead of just making it work better.They seem to think that we all want cross-hybrids of their software.”
from citizendesign
“A number of years ago, Adobe seemed to be headed the other direction. Making things simpler and leaving features up to other developers to ‘plug-in’.”
artgibel
“As far as InDesign, you have pinpointed one of the reasons I still prefer teaching print production starting with Quark and moving to InDesign later. I always tell students, the issues are the same in both programs; if your document is not set up properly for the printing process you are using, it will not print well. With InDesign, they have made it so much easier to make a mess.”
Here’s my thoughts:
I can sympathize with the desire on the part of some designers for Adobe to “simplify” its software. Occasionally I fire up my Mac SE and long for the days when computing was simple. But would I actually trade my current Mac for an SE? Of course not! Neither would I trade Photoshop for MacPaint. I may not use all the features Photoshop CS3 offers but I certainly appreciate the features I do use.
Instead of moaning about bloat, why not try to come up with a list of the features you would like Adobe to REMOVE from their programs? I’m sure, if you could get the profession to agree, Adobe would be happy to offer stripped down “Designer” editions. Of course you’ll never get the profession to agree. The fact is your “bloat” is another designer’s necessity.
I’m also shocked that anyone can suggest plug-ins as the answer to simplifying programs. Plug-ins don’t simplify the user interface or improve the user experience. While a well-designed plug-in can fit seamlessly into a program, it’s rare and the potential pitfalls are numerous including (but not limited to):
- Installations issues
- Inconsistent user interfaces
- Additional costs
- Incompatibilities with other plug-ins or program updates
Consider the nightmare of trying to maintain your suite of Adobe applications along with a set of “core” plug-ins. I’m willing to bet that, once a plug-in became a standard, you’d be among the throng clamoring for Adobe to make the functionality native.
I was also surprised by the kind comments for Quark. Perhaps things have changed since the days when I used XPress but back then the user interface was crap and the company was notorious for its lack of responsiveness to customer concerns. That’s the reason Quark has gone from having a stranglehold on page design software to being an also ran. Adobe, on the other hand, has created well-designed programs and been responsive to its customers.
And, speaking of responsiveness, we should admit that the true cause of program bloat is that we, the users, demand it. If we own Photoshop, we don’t want to buy Illustrator just to add one small bit of functionality, we want Adobe to add that functionality to Photoshop. That new functionality may be “bloat” and it may duplicate functionality already available elsewhere but as Photoshop users we’re grateful. Everyone else can feel free to ignore it.
Finally, simpler isn’t necessarily better. Sure it’s easy to do some bad things using InDesign but it’s also possible to stab someone with an X-acto knife. Neither action is the fault of the tool. There is a learning curve with any tool. It’s possible to ignore InDesign’s learning curve and produce substandard work but that’s not Adobe’s fault. Design professionals need to accept that the software learning curve now extends throughout their professional lifetime. The only alternative is obsolescence.
Back in June I mentioned being surprised by the low number of visitors to this site using 800 x 600 pixel monitors. At the time the exact number was zero. Well it’s increased a bit since then. Now a whopping 0.67% of visitors here have the mini-monitors. In spite of that, I think I’ll still feel comfortable ignoring them when I get around to the redesign.
I still find those results a bit startling, so I decided to do a quick survey of a few other sites I manage. Here’s the results:
Percent of users with 800×600 monitors
Website: 2007 to date / for July 2007 (target audience)
SEOrefugee.com: 2.01% / 2.01% (search engine optimizers)
NetDetours.com: 10.31% / 7.07% (general interest)
TOONrefugee.com: 7.34% / 6.08% (general interest with focus on sports, computers, etc.)
Extrapolating (unscientifically) I’d guess that most sites have already reached the magic 10% level where it suddenly seems OK to ignore the resolution-challenged in their audience. And I wouldn’t rule out that most of them will be at the 5% level by the end of the year.
To help confirm my conclusions, I check five other sites whose information I can only share in a general manner. The highest concentration of the smaller monitors was 13%. Another site was right at the magic 10% level. A third was at 7% and the other two were below 5%.
So it looks like 1024 x 768 is the new 800 x 600.
It makes me feel old, I remember when 800 x 600 was the new 640 x 480.
Note: This is our second tutorial on customizing Spry menu bars in Dreamweaver CS3. The first covered customizing horizontal menu bars. Many of the steps for creating and customizing vertical menu bars are the same as those for horizontal menu bars. That information is repeated here so you won’t have to refer back to the previous article.
» continue reading…