The core need of a CSS scripting system is the need for a color substitution system that would streamline color selection for the web sites I’m working on. Most of the other scriptable CSS systems do exactly that, so we’re not breaking new ground here. Since many of the sites I work on are high bandwidth, heavy usage sites, I need to minimize the server hit as much as possible. Reducing external files, and limiting the calls to the database and PHP are the name of the game here. My tertiary concern is to make the editing of my scripting system as easy and transparent as possible.

Avoiding the Overhead

The issue with many of the other “CSS scripting” systems is that since they rely on PHP at run-time the files need to be processed through PHP each time they are loaded (which means there is additional server load, as well as additional non-CSS code buried in the file). Another (minor) issue is that all of your CSS files also end with “.php” which can make management problematic (especially because chances are your text editor is going to use its PHP syntax highlighter instead of its CSS highlighter). I wanted to avoid all of these issues. The solution here is simple, we compile to CSS once and load the “true” CSS file each time the page is loaded.

How Does it Work?

The core of the CSS scripting is a file I called the “FCSS” file. Because this file is not a PHP file, I can set a rule inside of BBEdit (or other editor) to use CSS syntax highlighting. I built a PHP helper function for my XHTML pages that inserts the correct XHTML code on the page to load my CSS file. I do this because my scripting system runs in two modes: “production” and “testing”. In testing mode my script attempts to compile the FCSS to a normal CSS file. In production the system circumvents the FCSS file and loads the compiled CSS file. This means that PHP is only loaded when I’m testing the CSS on the site, but when the pages get rolled out to production only the compiled CSS pages get called.

Syntax

The syntax inside the FCSS file is simple. I have adopted a function style syntax that allows me to use regular expressions inside my scripting engine to find data that I need to act upon. To support my primary goal, I have created a function called “color”.

Color Substitution

At the most basic level I wanted a system that would allow me to create a named color that I could use across all of my CSS files. For instance I may want to assign the hex color #c312F0 to the named color “background”. This would allow me to create a dictionary of color for each site that would allow me to quickly select the right color (and make global changes easily).

Within the config file for my web site I define an array of name/value pairs for colors I want to use for this particular site. The colors are passed off to the CSS scripting engine to be used

Color Calculations

Having a dictionary of colors used on a site is handy, but really not super useful (how many times will you really need to know the color of the background?) Being able to modify those colors on the fly would be very helpful. For instance perhaps I might want to make a popup box a darker version of the background color, or maybe I want to take the link color, rotate the hue and set that color to the link visited color. You can see how powerful having the ability to calculate colors would be.

Why stop there though? Why not give the author the ability to mix two colors together? Maybe take your background color and mix in a little bit of the link color to give the site credits a subtle look?

Instead of opening up Photoshop (or some other tool) and mixing the colors together, putting it into your CSS file, then testing it, you can write:

p.credits{color:color(background,m:link:25);}

…and if it’s not quite right, you can tweak the colors, and refresh the page until it’s perfect.

That is the power of scriptable CSS.

Down Sides

There are a few negative side effects of this system. The biggest issue is that you need to make sure that Apache has write access to create (or change) the compiled CSS files. Part of my script checks this and attempts to alert the user if there is an issue. A secondary issue (although only for some) is that using this compiled css, you lose the ability for run-time changes (although this can be easily overcome with a trigger on my PHP helper function). Honestly though, CSS doesn’t need real-time scripting. It’s not its job. That is what JavaScript is for.

Although it can be frustrating and annoying, it also gives a designer/developer the freedom to avoid getting mired in the details of the interface (even though many of us love designing interfaces). Taking a page from the corporate world (no pun intended), establishing a set of rules can make a developer’s life easier.

These rules should be created for two important reasons. First, working with other designers and developers becomes easier if they are all working from the same playbook. Second, by providing the rule book to the client before work begins, the client can feel better about the decisions of the developer (they will know that the process has been well thought out, and that there is a reason for the decisions of the developer).

Starting Out

Any developer that has been asked by their client to explain why he/she did something in particular already knows a number of the rules that should be established. I broke my own rule book into six main sections:

• Overview
• Design
• Accessibility
• Usability
• Browser Compatibility
• Coding Practices

Coding Practices is by far the largest section. It includes six sub-sections (General, HTML, CSS, JavaScript, Database, and PHP).

Building on a bad thing

Every time that I run into a conflict with a client or another developer that isn’t covered in my manual, I/we decide on a solution, and it goes into the manual for future reference.

Evolve the rules

Every so often (3-6 months) I read through my rule book to make sure I agree with everything in the rule book. For instance, one of my rules is minimum screen size. In my last read-through, after a little investigation, I decided that 1024×768 is the new minimum size that I would begin working within.

Samples

Here are a few rules from my book:

• All code/layout for publicly accessible pages should be built so that Internet Explorer 6.0, Firefox 1.0, and Safari 1.5 all act similarly.
• CSS styling should only be implemented using linked files.
  • Inline styles should not be used
  • Style definitions in the head of the document should be avoided.
• Forms should always be validated on the server side.
  • JavaScript form validation is a nice extra, but data from the client should never be trusted to be valid.

Lately I’ve been working for a unique client that understands the importance of accessibility, but they view it as a black and white issue. It’s not entirely their fault, but that’s a rant for another day. The core problem is that they equate accessibility to making a site usable by people using a screen reader. If only real accessibility were that easy.

Making a web site accessible for those who can’t see pixels on the screen is important, but for every blind person using a computer, there are (probably) dozens more that we also need to think about, the gray area. These are the people who may have difficulty reading the average well-designed web site. Accessibility for these people is as important as accessibility for the sightless.

These are the people who don’t need a “skip to content” link, but need high contrast, large text pages that are easy to navigate. Liquid layouts and clever design will get you part of the way there, but ultimately, to provide real accessibility you’ll probably have to create an alternate format that these users can use.

So, in the interest of accessibliity, you’ve carefully crafted a primary style and it’s gray area cousin. Your code is clean and accessible, so finally you can step back and admire your beautifuly accessible site right?

Well… almost. You’ve done the legwork, but there is still one major accessibility (and usability) problem. How do you get your gray area users to their version of the site? It’s doubtful the client is going to go for the idea of putting a big black and white button next to their logo advertising the alternate version of the site (it’s not that important to them). There’s really not a place for an accessible link in your standard site design. If only there was a way that we could detect those users that would require the alternate version of the site without the requirement of a link to initiate the switchover.

Introducing Auto Style Switching.

Most average users tend to keep their browsers set to the default font size because this is what most developers design for (or maybe it’s the other way around). Our gray area users have the option to increase the font size globally on all web sites. Those who need a larger font only need to tell their browser to user a larger font.

Using a bit of Javascript we can detect the size of 1em in pixels and judge it’s size relative to the default. This isn’t an exact science since there will always be a variation between browsers and configurations, but we don’t need to be pixel accurate here. If it is beyond a threshold we trigger our high contrast style sheet (using the script by Pault Sowden).

See it in action

Handling the Resize

Although the majority of users will be entering our site with their font size already set to their liking, it is certainly possible that a user might change their font setting after already loading the page.

In Internet Explorer, changing the text size reloads the page (therefore trigering the window.onresize event). So, we could just add that to our initialization:

 window.onresize = window.onload = checkContrast;

Of course it’s never that easy. Safari and Firefox don’t seem to trigger any DOM event so there is no way for us to find out if the text size has been changed.

We could call it a day and accept that we’ve provided support for the majority of users, or we could use setInterval to check our text size a few times a second as a work around. It’s not very elegant, and it almost crosses the line into what might be considered a “hack”, but the setInterval solution is the only one that works for all browsers.

In the end I opted to be as accessable to as many people as possible, which means using the setInterval solution. I check the test area five times a second which should be often enough to provide reasonable feedback, but not so often as to make much impact on our available processor cycles.

See it in action

Allowing Users the Choice

As a last step we should add a link to our site that allows the user to toggle the style that they are presented with. We can work this into our design now without too much fear that those who need it won’t be able to find it. This has been covered in many places, so it’s not really worth reexamining it here.

Variations On a Theme

You don’t need to use the text size to trigger style sheet changes, you could trigger any other interface. Perhaps instead of switching styles, you present a dialog notifying the user of the alternate style, or even send them to a different location.

Additionally, we don’t need to create a binary switch between normal and alternate versions of the site. We really are in the gray area of accessibility. A clever developer can use the realative size difference to adjust the site, triggering variations based on font size using different style sheets, or directly changing the styles of elements. What would you do?