Design Blog

Using variables in CSS style sheets

Design Refugee — 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

Design Refugee — 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.

Adobe CS3: One man’s bloat is another man’s feature

Design Refugee — Mon, 24 Sep 2007 17:01:24 +0000

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.

800 by 600 pixel monitors: An endangered species

Design Refugee — Fri, 17 Aug 2007 14:40:55 +0000

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.

Creating and Customizing Vertical Spry Menu Bars in Dreamweaver CS3

Design Refugee — Tue, 17 Jul 2007 20:48:40 +0000

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.

As I’ve said already Adobe has documented the CSS files that control the appearance of the menu bars with ample notes to guide the adventurous. They’ve also included a help file that’s actually helpful. YOu can use the information you’ll find there to expand on the lessons of this tutorial.

Getting started:

Before you begin, make sure you have properly defined your website within Dreamweaver.

Creating a vertical menu bar:

Open an existing document or create and save a new one. Dreamweaver CS3 won’t allow you to add a menu bar to an unsaved document. If you try, you’ll be prompted to save the document before proceeding.
Select the location in your document where you want the menu bar to appear.
Select the Spry tab in the Insert palette. (If the Insert pallet is not visible, select Insert from the Windows menu to display it.)
Click on the Spry Menu Bar icon in the Insert palette.
You will be asked to select horizontal or vertical for your menu bar layout. Since we’re making a verical menu bar, select verical and click OK. Your menu bar will be placed on the page.
Immediately save the document. You will be informed that your menu bar requires a number of supporting files and prompted to save them. Click OK and DW will save the files in a SpryAssets folder it will create within the root folder of your website.
With the menu selected, you can use the Properties palette to define the links, menus and submenus of your menu bar (to select the menu bar, click on the blue box labeled “Spry Menu Bar for xxxxx” that appears immediately above your menu bar).

Note that the Properties palette also contains a link, “Customize this widget.” That leads to the Help file that you are hoping to ignore by reading this. Take my word for it, clicking that link will be worth your while. Go ahead, I’ll wait for you.

Customizing the look of the menu bar:

Good, you’re back. In case you didn’t figure it out from the help file, I should let you know that the look of your menu bar is controlled by the styles in the CSS file (SpryMenuBarVertical.css) that Dreamweaver graciously created in the SpryAssets folder. Since we’ll be editing these styles, you’ll need at least a minimal understanding of CSS styles in DW.

Type style and size:

DW does not specify styles for the text in its menu bars so the style attributes are picked up from the page element(s) that enclose the menu bar. If you would like to use a specific font, size, weight, style, variant or case attribute for ALL the text in your menu bar, specify it in the ul.MenuBarVertical style. The color of the text will be defined elsewhere.

Menu bar width:

Note: This is the area that differs significantly from the procedure for customizing horizontal menu bars.

By default, the width of the top-level menu and each menu item is set to 8 ems.

To specify a specific pixel width for the top-level menu: In BOTH ul.MenuBarVertical and ul.MenuBarVertical li styles replace width: 8ems with width: XXXpx.

Note that changes made to ul.MenuBarVertical and ul.MenuBarVertical li affect only the items in your top level menu. The width of pull-down menus is not affected.

Menu bar height:

Caution! You can control the height of items in your menu bar by specifying a height attribute in the ul.MenuBarVertical a style. But be careful. This can cause type to be cropped or even disappear if text is resized or a menu item unexpectedly wraps to a second line. It’s more flexible to let the height of your menu items be determined automatically by the font-size (specified in ul.MenuBarVertical) and the padding (specified in ul.MenuBarVertical a).

Color of menu items:

The color of menu items in the link state (when they are not being hovered over or clicked) is determined by the ul.MenuBarVertical a style. To change the look of your menu items, simply change the default background-color and color styles DW has provided. This is also the place to add borders if you want to visually separate the menu items.

Rollover color of menu items:

To keep it simple, set the background-color and color styles to your preferred rollover colors in the following two style definitions:

ul.MenuBarVertical a:hover, ul.MenuBarVertical a:focus
ul.MenuBarVertical a.MenuBarItemHover, etc.

In THEORY, the first definition determines the hover state of menu items and the second definition controls the appearance of menu items with open submenus. In REALITY that’s the way it works in Explorer. However in Firefox and Safari BOTH the hover state and the appearance of menu items with open submenus are governed by the second definition. I usually just make sure both definitions have the same settings for background-color and color and forget about it.

Menu bar arrows:

In DW’s vertical menu bars, menu items which open to submenus have a right-pointing arrow at their far right edge. These arrows are actually background images. If you change the background color of menu items or their rollover state, the arrows may become difficult to see.

To change the arrows, edit the background image attribute in the appropriate style definition as described below:

Edit ul.MenuBarVertical a.MenuBarItemSubmenu for menu items with a submenu.
Edit ul.MenuBarVertical a.MenuBarItemSubmenuHover for the hover (rollover) state of menu items with a submenu.

For reference, DW makes available the following images in the SpryAssets folder:

SpryMenuBarRight.gif - black arrow pointing right
SpryMenuBarRightHover.gif - white arrow pointing right