Author Information

Brian Kardell
  • Developer Advocate at Igalia
  • Original Co-author/Co-signer of The Extensible Web Manifesto
  • Co-Founder/Chair, W3C Extensible Web CG
  • Member, W3C (OpenJS Foundation)
  • Co-author of HitchJS
  • Blogger
  • Art, Science & History Lover
  • Standards Geek
Follow Me On...
Posted on 5/11/2012

(Really) classy CSS

When CSS was conceived, the basic vision was that HTML should provide structure and semantics while CSS would providing styling via rules based on selectors describing (or selecting) what to style. In an ideal world, Web pages could be authored by one group of people independently of the visual needs and then another group (designers) could go and write CSS to style it up. The biggest problem in achieving this ideal was that HTML had such a small number of tags without any real obvious way to add enough semantics to actually accomplish this. Thus, two things were added very early on: The humble div and span tags in HTML and the .class in CSS - the general idea being that the authors of a tree of markup could (quite independently of style concerns) build generic structures and pepper their markup with semantics via classes and ids.

Theory vs Reality

In practice, there have been a relatively few cases (like WordPress blogs, for example) where things are simple and standard enough this has worked out "pretty well" and a whole lot more where that is actually not the common experience. Generally speaking, markup is not created independently of design and changes to design often dictate changes to markup. Even the attaching and management of classes are changes to markup and if they happen purely to achieve design, well, that's less than desirable. There have been lots of blogs and articles written over the years about the problems that this created and the creation of new terms like "classitis" and "divitis" to describe their negative impact.

Still, that was what could get done initially and it was a lot better than what we had prior to it. Considerably more important, however, is that this was never meant to be the end game - even by the people who created it. HTML drove forward, creating some new tags and work began on an XML dialect which promised all kinds of things, while CSS followed up almost immediate with CSS 2/2.1 and began CSS 3 (the first draft was published in August 1999, only 3 months after 2.1 went to REC status). But then, a lot of confusion happened and for a long time, things were pretty stagnant.

Solutions

The solutions to this are pretty clear, and it's arguable just by looking at the history of drafts and discussions that everyone knows what needs to be done about it: HTML authors need more semantic abilities (new tags help and so do things like data-* attributes), CSS needs new concepts (regions and generated content for example) and more powerful selectors. The good news is, things are moving again, though not as quickly as many of us would like...

My friend, and co-author of Hitch, Clint Hill has been posting some good articles about Hitch over on our blog about how Hitch helps with this last part by allowing authors of CSS to use an expanded set of selectors (Hitch provides a selector plugin model, just like jQuery) right in their CSS, affording them with more expressive powers.

I'll let you read the article yourself, but the gist of of it is about a set of selectors for selecting elements based on the numerical qualities of your attributes. For example, the :-math-greaterthan(attr, number) filter allows you to write CSS like this:

/* Let's visually call out players who achieve this... */
.player:-math-greaterthan(data-score, 100000){
    font-weight: bold;
}

Rationale...

Here's a bit more on the theory behind this selector and how it is relevant to the above.

  1. The proposal certainly isn't to throw away .class, merely to use it more "as envisioned" in terms described above. If, indeed, you recognized semantic meaning in your tree and maintain it as a class for reasons other than styling - that's great. In our example above, however, it's definitely possible that that is not the case. Clearly there is semantic meaning to the number, but whether a designer decides to attach some arbitrary styling to that or not shouldn't require changes to the tree. This approach allow the appropriate technology to handle the appropriate concerns. From the perspective of a CSS author: You use the classes you have when they are there, and have the expressive power to style things that are purely visual when they are not. The alternative of scattering presentation logic throughout your php or jsp (or whatever) and your javascript to maintain a class in some of these cases is considerably less desirable.
  2. CSS has had attribute selectors for a long time which allow you to select attribute values that are contained with in, exactly equal to, start with or end with values expressed in your selector. There have long been conversations, even tentative plans to further expand attribute selectors to something with more "regExp" power, there have even been plans for a :content pseudo-class which would allow the same thing with textual content - but it's all string based currently. Attribute selectors already support data-* attributes. Literally all that is added is the ability to write rules that consider something numerically rather than textually.
  3. CSS has rich support for algebraic expressions as they relate to structures (children, characters, etc) in the tree and will soon add a calc() function. Again, it makes sense if you think about it that CSS should have appropriate power to do what is required in order to achieve styling without mucking with the tree...

All of this seems considerably inline with the goals and existing approaches of CSS to me and it seems logical to me, but I'd like to hear what you think...

Hitch is a new, open source project hosted on github which we think has a lot of potential. Check out http://www.hitchjs.com and the articles on the Hitch Blog... Let us know what you think and share your comments, we'd love to hear from you and have a conversation.