Tag Archives: Specification

CSS Wish List

Don’t get me wrong, I think CSS is awesome. It is a great way of defining the UI, but it could be even better. I’m excited about the special effects, transitions, and graphic elements currently being added to the CSS specification. They will help us write faster pages by eliminating the need for UI graphics for things like rounded corners. On the other hand, we also need to add structure to the language to make it easier for designers and developers to author new pages and applications. I hope the CSS Working Group will consider my suggestions.

  • Make CSS a better declarative language
  • Abstract repeating patterns in the code
  • Do not make CSS a programming language

Suggestions for the CSS Working Group

The community has been talking about some form of constants or variables in different incarnations for almost a decade, it is time to make this a reality. While it is possible to duplicate this functionality with a preprocessor (an excellent stop gap until browser support catches up), ultimately this is a tool which should live within the CSS itself. It is a powerful way of expressing more about the objects we are building.

The mixins and prototypes (and associated includes and extends properties) are designed to allow document authors to abstract reusable bits of code and better manage and maintain their style sheets. The goal is to mimic the effect of using multiple class names in the HTML without the drawbacks associated with current implementations. Authors need extends and include in order to write faster, smaller, more efficient style sheets.

CSS is a powerful expressive language. It needs certain modifications so that it will be robust, maintainable, and easy to implement.

From JSConf.eu

How did this begin?

At some point, I realized I was coding CSS with a bunch of “rules” and best practices that weren’t the currently accepted norm. I found myself writing comments to try to express these rules like:

/* ----- faq (extends mod) ----- */

and

/* margin top = bottom height - corner height */

At that point I realized that I was trying to express via comments something which was missing from existing CSS syntax. I looked at other proposals and my own work building web sites for the last 9 years (eek! almost a decade). I first cataloged many of the rules because, at this point, they were mostly intuition and I needed to figure out why I do things the way I do.

When that had stabilized, I began to explore a syntax for this new language of declarative objects. Trying to balance standard programming practices with a desire that the syntax fit well with document authors expectations for how the language works.

CSS Inheritance Today

It is currently possible to implement CSS inheritance in three ways, however, each has its drawbacks.

  1. Multiple class names, clog the HTML with classes that have the same semantic value (just more or less abstract). They introduce an unnecessary dependency because CSS inheritance is defined in the HTML.
  2. By chaining comma delimited selector strings, authors lose the ability to group related rules into discrete blocks of code. The quantity of code increases dramatically. A preprocessor could make option #2 more feasible, but abstracting a necessary part of the language into another layer isn’t a permanent solution. As well, the resulting CSS is not human readable, this step should take place in the document tree.
  3. With a JavaScript parser, the heavy lifting could be done on the client-side, however this would likely have a negative performance impact particularly on older browsers and slower machines.

A Concrete Example – Based on YUI Standard Module Format

I found myself writing the following code:

/* weatherModule (extends .mod) */
.weatherModule{...}
.weatherModule .hd{...}
.weatherModule .ft{...}
.weatherModule .bd{...}

The html looked like this:

<div class="mod weatherMod">
  <div class="hd">Local Weather for SF</div>
  <div class="bd">Cloudy with 100% chance of rain, and fog.</div>
  <div class="ft"><a href="newLoc.html">Change your location?</a></div>
</div>

I was using multiple class names (which is great because ultimately it reduces the footprint of the CSS file by an order of magnitude), but it would be better if the browser could understand my intention, and process any instance of weatherModule as if it was also a mod.

<div class="weatherMod"> 
<!-- Can the browser treat this as an instance of mod? -->
  <div class="hd">Local Weather for SF</div>
  <div class="bd">Cloudy with 100% chance of rain, and fog.</div>
  <div class="ft"><a href="newLoc.html">Change your location?</a></div>
</div>

Thanks so much to the following people who gave invaluable advice, feedback, and (in some cases) tolerated an enormous number of iterations. Nothing gets created in a vacuum and dissenting opinions were as helpful as supporters. :) William Cook, David Federman, Gopal Vijayaraghavan, Douglas Crockford, Stoyan Stefanov, Ryan Grove, Marcel Laverdet, Eric Meyer, Dan Cederholm, Ethan Marcotte, Jeffrey Zeldman, Gonzalo Cordero, Jenny Han Donnelly, Chris Klaiber, Tantek Çelik, Jeremy Keith, Wendy Chisholm, Aaron Gustafson, Fred Sauer, Dave Hyatt, Eric Schurman, Brad Neuberg, John Allsopp, Tom Hughes-Croucher, Chris Mills, Nicholas C. Zakas, Peter-Paul Koch, Doug Schepers, Amy Hoy, Kyle Simpson, Brian LeRoux, Chris Blizzard, Philippe Le Hegaret and (of course) Daniel Glazman.

CSS 3 and where we shouldn’t be

Allowing dependencies between CSS rules really isn’t so different (with all the advantages and dangers) from using multiple classes on the same element.

<p class="highlight updated updatedByOthers">my paragraph text</p>

They’ve suggested importing rules into other rules, like so:

.highlight {
color: red;
text-decoration: underline;
}
.updated {
@importRule '.highlight';
background-color: yellow;
}
.updatedByOthers {
@importRule '.updated';
color: #3f5070; /* a nice dark blue */
}

Both can easily end in a rats nest of styles that each do only one thing and make your site unmaintainable. After all, it really isn’t that different from using inline styles or font tags.

If we started using the importRule technique, what happens if you need to use updatedByOthers class independently from the highlight class? The importRule solution would allow you to reorganize the dependencies without touching the HTML, but is it worth losing the independence of the two classes? Especially if they would then author even more CSS to achieve what we already can with a multi-class system:

.updatedByOthersNotHighlighted{}

Does that make anyone else’s stomach turn?

Variables would be lovely, but they can be achieved with some server-side CSS processing. Why add unnecessary complication to the CSS specification? I don’t think any truly viable justification for a massive overhaul of the CSS specification has been made here.

It amuses me that someone who says,

CSS 3 is a joke. A sad, sick joke being perpetrated by people who clearly don’t build actual web apps.

wouldn’t see the irony in suggesting,

Since we can’t reasonably expect IE to support things in a timely fashion, do we owe it to ourselves to start building apps for browsers that will give us what we want?

The emergence of CSS Frameworks doesn’t prove the necessity of a major overhaul of the CSS Spec. Rather it is indicative of the maturity of the medium. Java programmers don’t rewrite the math class every time they code a new application. If you are reinventing the wheel each time you write CSS, you’re doing it wrong.