Seven things still missing from CSS

The first passionate cry for CSS hearkens back to 1994. That’s the same year the W3C formed, which is almost two decades ago! How on earth did a technology we’ve come to rely on as one does family; love to the point of tears; extend to the point of breaking; end up hating and ultimately waging full-out web war for missing critical pieces along the way?

In order to uncover what mischief these flaws in CSS have caused, I went on a mission that revealed what many working web folk find particularly shameful about CSS in its current state. So, whether a result of action or inaction on the part of the W3C, browser and tool implementations, or our own misconduct, here are seven scandalous sagas from the world of CSS.

1. Fear of height

Perhaps if we’d named it the “World High Web” we’d be more concerned with managing height in design. Width we can do, and pretty darned well, but even when it comes to the simplest use of the height property, we find ourselves teetering on the edge. Some of the challenges we face:

• Consistent height handling across browsers
• Equal height columns in floats and positioned elements
• CSS Animations not applying to elements with a height value in browsers

There are countless use cases where height is critical to a design, and this is easily achieved in static media. However, it’s extremely difficult in a variable, vertically scrolled medium such as the web. Width is enforced by the physical limitation of the device at hand, the limitation of software limitations in operating systems and user agents, and finally by convention: The horizontal scroll is a known user experience and accessibility problem, so we tend to avoid it. Vertical scrolling however is an expectation with an online experience.

CSS media queries can help with the height issue by allowing us to provide a style sheet to viewport widths and heights. While extremely helpful in multi-modal design, it’s a far cry from a real solution. Other areas where height control is improving is in paged media, Generated Content for Paged Media (GCPM), multicolumn layout and other layout modules.

2. Clear My Fix

Floating. Away from CSS the word brings to mind lazy summer afternoons, white puffy clouds and a sense of freedom. Why then have floats been exactly the opposite of free, and most importantly, how do we, once and for all, clear them properly?

Float clearing wasn’t a concern in terms of layout because floats were not originally intended to create columns, which is how we now use them in contemporary CSS design. Originally, floating was simply meant to provide a means to have text flow around an element to the right, to the left, or to clear both right and left. Who remembers this syntax?

<img src="images/myCoolPicture.gif" width="200" height="100" align="right" hspace="10" vspace="10" alt="picture of ME!">

You know, I actually got a little nauseated typing that, as it seems so clunky in retrospect. Yet this is the heart of floating, not creating columns within a layout. So, we have to deal with the legacy behaviour as we’ve morphed floats from their original use into creating columns. Floats are not in the “normal flow” (the way text content flows in the document when no floats or positioning are applied) – everything has to flow around the float – an “island in the middle of the stream” as my colleague Kevin Lawver likes to say. This is why clearing is hard.

The best way, in my opinion, is to use the overflow: auto approach. This works brilliantly, with a few caveats:

• A width or height value might be necessary for browser compatibility
• If content goes beyond a specified width, the browser may show scrollbars

So test, test, test! Another argument can be made that the technique of creating a class .clearfix {clear: both;} applied to a <br> element (NOT a <div>) is not outside the realm of reason, because this technique is based on the original float model, where a break with a clear of “all” is how we managed clearing in the past. However, most designers and developers prefer avoiding anything that seems presentational and opt for CSS solutions, of which overflow: auto is considered most appropriate in contemporary standards-based design.

3. The !importance of being earnest

Perhaps the most misunderstood bit of CSS syntax is the “Bang Important” keyword. I’m still asking at the W3C who was responsible for the insanity that !important has brought us, but no one wants to ‘fess up, probably fearing for their well-being.

There are two serious errors that were made surrounding !important that have resulted in widespread lack of understanding and misuse of both the term and the keyword itself.

1. CSS 1.0 states “Sort by origin: the author's style sheets override the reader's style sheet which override the UA's default values.” This, to me, seems backwards, as reader (aka user) style sheets are mostly meant for accessibility, and my own logic says that a user style sheet should by default override the author’s sheet! So !important provides a means for those creating user style sheets to ensure the override. As such, I worry about use of !important in your author styles. If everything is important, nothing is important! So my advice is avoid !important in all deployed style sheets. It’s very useful in author style sheets when you’re debugging, particularly in cases of specificity problems. However, I suggest repairing the specificity issue, and not using !important as the stop-gap.
2. It might just seem to be an annoyance that the “bang” itself represents NOT to many programmers, who first look at !important and think “not important” rather than “really, really, really important” which is what !important actually means, at least in CSS. Not so much a small annoyance when you’re trying to educate a programmer who has held the idea that “!” = “not” in their head for 20 years.

At this point, !important is CSS’s bastard child, and no matter our feelings about how it came to be or what it looks like, it’s part of the family now and we need to understand how to cope.

4. Relative Trouble

You know we all have relative problems. But CSS positioning as it is currently implemented is as confounding and weird as float problems. Semantic ped-antics have been shouting about clean markup for years, for good reason. Why then do we have to use extra <divs> and muck about with relative positioning in order to create fairly simple layouts?

I blame the entire issue on naming. Relative? TO WHAT? Not many of us were clear that meant “an element remaining in the normal flow positioned in relation to a positioned ancestor or the document’s root element.” I often ask the CSS Working Group “Who on earth thought it was a good idea to use the word ‘relative’ to mean that?” Blank faces. I could go look it up in the mail archives but I figure why ruin the mystery? Instead, it provides us with something else to bitch about and keeps us writer and educator types employed.

The hard, cold truth is that CSS has no surefire method for layout, and we’ve kludged together the technology to make it do what we need it to do, disregarding what an element was originally meant to do. That is downright hackish, but until there are other solutions, we do what we must, which means the occasional extra div or relative positioning and element without offsets in order to create containers for floats-as-columns, which are also hackish.

Fortunately, multicol, the Flexible Box Model (flexbox), Template Layout Module, Grids, Paged Media, GCPM and the very exciting CSS3 regions are moving forward both in the Working Group and implementations, so we should begin to see some major changes in the next few years about how we go about laying out our designs.

5. A Font of Folly

Oh, we are all so very happy that @font-face is here, alive and well and giving us great opportunity to improve the literal face of web typography. It’s taken years to get us this far with fonts, in part due to licensing issues for embedded fonts in browsers, and only now are we seeing fonts really take off on the web. This is especially true with the growth of open source fonts and tools such as Typekit. However, certain problems still exist with fonts, even with the advances made in the past few years.

1. Internationalization (i18n) concerns such as vertical text layout are still in early proposal stages. This means that for those of us using horizontal text, we have some control. Languages that have vertical text, however, such as Japanese (which uses both horizontal and vertical text layout), do not enjoy the advantages we have with English and other horizontal-only languages.
2. Fine control remains elusive – kerning, character spacing – controlling these aspects are both difficult to specify for numerous reasons. This is frustrating to designers who love typography and want to have that finer control.

Certainly, we’ve come a long way, considering embedded fonts was proposed in the mid-90s, and work for finer controls in the specifications marches on.

6. Of Central Intelligence

Math, calculations, regular expressions. In order to centralise style and be able to apply it in a variety of ways, developers have long been clamoring for these features despite dramatic disagreement with certain members of the CSS Working Group.

This has caused developers to do what they often do best: Solve the problems themselves. This is laudable in theory, practical in a flawed environment and can cause irreparable rents in the Web’s fabric. As a result, we end up with JavaScript polyfills, CSS and JavaScript frameworks, and techniques such as OOCSS, SaSS and SCSS.

Surely such frameworks and techniques have brought us new knowledge, and empower us to do work today. But taken in the greater view of an Open Web, consistency is imperative for true interoperability. The specs are where these issues are best resolved for long-term sustenance and evolution on a stable Open Web platform. Ah, what dreams may come!

Fortunately, the CSS Working Group is growing and changing and we now are seeing CSS beginning to offer such features. While generally speaking implementors dislike RegEx because it's complicated to engineer. Fear not! You will be getting more calculation features and a bit of RegEx here and there in CSS3.

7. Ancestral Selection

I was originally going to leave this out for another article, but I feared your wrath! One of the most asked questions for those of us teaching and advocating CSS, this issue is a frustrating one, so I had to cover it at least in brief.

Just as we can’t choose our ancestors in real life, we can’t select elements from a descendent and travel up the tree in HTML. Other technologies, such as xPath, provide a way to do this, so it's not an impossibility to eventually imagine such a feature.

Bottom line? It’s an extremely difficult problem to specify and implement. Many devs have asked for it, but I doubt this is a feature we’ll be seeing anytime soon in CSS itself. I’ll be taking a longer look at this issue, with insight direct from browser developers, in a future article.

Only Seven?

Okay, so you know as well as I do that these tales of CSS woe are only a mere sampling of the things we want. But rest assured, there’s a lot of cool stuff going on with CSS. We see better and faster implementations, more community involvement in the W3C process and less drama between competitors when it comes to standards implementation. We’re leaving the dramas of our teenaged past behind. I hope we’re all ready for a new generation of sagas and scandals to come!