Matt Prokes

For those that do not yet know, I work for internet broadcasting. An awesome company out in st. paul, minnesota. While working on some very large scale webapps, an annoyance came to light. Namely coding in styling directly to your webapplication.

Why is this a big no-no?

Well when css came out the big great thing about it is that people had their own language to specify, and seperate look and feel configurations, as well as the ability to take action on specific events like hover. This was a great idea simply because all this data was configuration and NOT code. Also it allowed people like designers to have a single point to go to if they wanted to make a red box green.

CSS was and still is great. So what happened?

DHTML happened. While a great idea dhtml put styling back into code (namely javascript), and css never adapted for this change. Stuff like webanimations started happening and there was no way to put that into css because css isn’t extensible in that way. So what did we as developers do? Well the only thing we could, we tried to put as much in css, and all the dynamic stuff got crammed into code!

But I have a solution for those of you that work on large scale webapps.

Introducing CSSPlusPlus.js!

What is it?: CSSPlusPlus.js allows you to in-a-way extend CSS through custom pseudo classes and property’s!
- Allowing for you to cram all sorts of configuration information, animation info and styling into one easy to use location. Think spring (sorta) for webapplications.

Ok Enough Talk Lets Roll To A Useful Example.

First you need to go out and get CSSPlusPlus.js, its under the MIT license so no worries.
You can find it here: http://www.webactivelabs.com/js/CSSPlusPlus.js

I know the namespace is pretty generic, feel free to rename it if you need to. Anyway Lets start off by creating a simple webapplication for creating boxes. I will also be using jquery for this example to show a practical use, in animation.

What it would look like:
BoxCreator.html
BoxCreator.js

Excellent, humm, if we investigate the box creator you will notice that I have coded in an animation height and width to expand out to, as well as some coloring information, and even a error message.

Humm thats alot of domain specific data coded directly in, what if this was a large scale application, how would we find this in the future? Surfing the code? Find? There must be a better way. Well lets start off by taking out all width and height information. For boxes.

What it would look like:
BoxCreator.html
BoxCreator.js

//Add a pseudo class to listen for!
CSS.addPseudoClassListener(‘boxcreator’,createBoxStyle);

BoxCreatorConfig.css.js

//The CSS parser at work for a custom pseudo-class :boxcreator
CSS.parse(‘.box:boxcreator {height:30px; width:400px; color:purple;}’);

Mmmmm, thats much better, humm.. but we still have some error messages. Lets say that we have a large amount of error messages that we want to keep track of, or we just other configuration data. Humm what if the designers do not like the wording of the messages? Well lets pull those out to, and send the designers the file and go have some coffee.

What it would look like:
BoxCreator.js

BoxCreatorConfig.css.js

//Any number of rules can be defined in a single parse.
CSS.parse(
‘.box:boxcreator {height:30px; width:400px; color:purple;amount:5;}’,
‘*:error{error123:crazy beefy cow!;}’
);

Alright, time to show the company the wonderful box creator that we made, lets go out and take a look at it.

BoxCreator.html

Thats all there is to it!

Whats actually happening here? I am not advocating that you dump all of your css into this tool, though styles that you do not listen for actually flow through the system and get spit out as an inline style tag. The custom css that you are defining is NOT actually real css, its just recognized by a simple glorified css parser that looks for property’s and pseudo classes. In a way it is similar to a sax parser, only for css instead. There is no magic, more like cloak and dagger.

If its a pseudo class listener:
The entire property’s list gets turned into json object and sent to the callback, as well as the selector that was defined for that pseudo class.

If its a property listener:
Just that property gets sent to the callback along with the selector, the rest of the property’s not being listened on get sent to a inline style tag, as standard css.

The Good:
Its just a glorified parser, but the designers won’t know the difference, and its efficient (I am all for tricking designers). Infact if you define custom css and do not listen for it, then it will flow through the system and get spit out in the style tags and the browser simply won’t do anything with that css. Many of you will say whats the point of this, I can create property files right now as a json object.

Yet that will require designers to learn a new language, as well as possibly breaking your app by coding native js. Also the syntax and the readability of this method is superior to that of a json property file in the context of applying a custom css action. Lastly, the pseudo class can be used on any selector, its not a one shot deal.

Example:
#button1:fadeButton {fade-to:green;}
#button2:fadeButton {fade-to:red;}

This method could also be used to fix things like hover, without hacking like crazy. Its in javascript.. but if you are designing a webapp, then that webapp is in javascript anyway. Plus you can be sure you won’t need to find the next greatest css hack when vendors decided to release the next greatest and latest. I advocate coding as much as you feel certain will be supported now, and in the future in css. Then maybe keeping your life simple, and using the parser for the rest .

The Bad:
There is a very small amount of parsing happening, I emphasize small. If you compare the amount of processing used for this method of specifying property’s; I would compare it to 1/1000th of the processing required to cause a animation to happen in the browser, and it only happens once. For those of you that are speed demons, and have to squeeze every last bit of performance out of your code then this might not be the solution for you. But in my case its a perfect fit. Secondly,

I wouldn’t on a regular basis define standard css through this interface unless you know what you are doing, or the definitions are placed in the document head. The reasoning is that your styling won’t be placed in the document until the script loads keep in mind. So IF you place your script tag AFTER your html structure, you will see the action of the standard css being applied to that structure once the js is loaded, which again is AFTER the html structure is displayed.

Anyway, use it at your own discretion, and have fun.

Your Friendly Developer,
~Matt Prokes

This entry was posted on Sunday, February 8th, 2009 at and is filed under Javascript. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.