#chris-eppstein

position:unique

Standardizing Incompatibilities

Yesterday’s minutes of the W3C’s CSS Working Group revealed that the
Mozilla team is seriously considering adding support for some -webkit
prefixed properties. Make no mistake about it, this represents a real failing
of the CSSWG to officially standardize these vendor CSS properties before they
become widely adopted by developers. Let us also agree on this fact: the net
effect of vendor prefixes on the web has been very good for the web. Giving
browser vendors the space to experiment and get developer feedback during the
development process has benefited both developers and users alike.

I’m sure there will be a lot of discussion about what a better approach for
browsers vendors might be. Versioned prefixes? New @-rules? Whatever they come
up with I’m sure it will be fine, until it falls apart in some unforeseeable
way and we get to play this game again.

Much Ado about Nothing

If you are a Compass user, all these prefixes are dead to you. You don’t need
to know or care about them. Your stylesheets are insulated from what largely
amounts to an implementation detail. Compass maintains the browser vendor
support matrix and gives you a single, well-documented API. And when that API
changes, Compass deprecates it and provides you with helpful warnings so that
you can update your stylesheets accordingly.

Do you remember back when webkit’s gradient syntax was horrible and firefox’s
gradient syntax won? I do because I remember hating the webkit syntax and
trying to make it better in the API that compass provided.

However, there is only so much a Stylesheet Preprocessor can do on this front
by relying solely on progressive enhancement, but when you combine it with
Modernizr you start to get a feeling of what could be possible…

jQuery Saves Us from the DOM

I’m sure there are some downright horrible incompatibilities in the DOM. I’m
not 100% sure because it’s been a very long time since I used the DOM directly.
jQuery, MooTools, Prototype and the like can all provide me with a single API
that adapts to the browser. On top of these tools, entire ecosystems are
thriving and making javascript web development pretty easy for new developers
and experts alike. As a result, our webpages are snappier and our user
experiences are richer.

But what made jQuery possible? As Molly E. Holzschlag points out
it was two things:

Browsers try to standardize the DOM. In most cases they succeed.

Javascript is standardized.

10 years ago, when the DOM was in shambles, scripting was too. There was no
standard programming language for the web and as a result, there could be no
jQuery. So if you love jQuery, you have to admit that establishing Standards
and aiming for Standard-compliant browsers is good for the web.

Recently, browser vendors have been cranking out tons of new DOM APIs for
HTML5. But it is DOM abstraction libraries that are giving them the cover to
make mistakes, learn, and eventually converge on a standard API. Fortunately
for the HTML Working Group, Javascript is Turing
Complete and comes with
enough introspective ability to adapt to the browsers. Unfortunately, this is
not the case for CSS.

CSSWG, Save Us from CSS

The CSS Working Group needs to stop rearranging deck chairs for a while and
plug the giant holes first.

Never in the history of software development have developers had to support so
many runtime environments with so little language support. We are currently
supporting almost 50 browser versions spanning 10 years of releases. We are
supporting screen sizes from small handhelds to giant desktops. We are
supporting high-latency, low bandwidth mobile experiences and broadband. And we
do this with selectors, property/value pairs, and a host of parsing tricks and
hacks. That a website looks even remotely fine in any significant subset of
these combinations is a testament to the hard work and diligence of web
developers – not standards committees.

We need a language for expressing design abstractions. Two and a half years
ago, I wrote about Why Stylesheet Abstraction Matters and
gave life to the CSS Preprocessor movement. It is time for the expressive power
of Sass to come to browsers themselves.

Don’t get me wrong, preprocessing is and will forever remain an essential
approach to stylesheet development. There are a boatload of things that Compass
does (like sprite assembly and url munging) that simply wouldn’t be viable
within a browser. Not to mention, pre-compiling any new syntax will be
required to provide “graceful degradation” for legacy browsers.

But what is good for developers is also good for vendors. The CSS WG needs to
embrace the differences that make each browser unique and to give those
browsers the freedom to converge their implementations over time or to even
agree to disagree. This can be done while simultaneously giving them cover by
enabling CSS abstraction libraries through new syntax and language feature and
standardizing the language and a set of core APIs to provide introspection
of browser abilities.

It is time for native feature detection,
it is time for mixins and selector inheritance, it is time for variables, it is
time for user-defined functions, it is time for better syntax. Actually, I take
that back. It’s way past time. Developers have been demanding variables for
their CSS for a decade and that CSS doesn’t have this feature yet is an
absolute embarrassment.

It is time for the CSS WG to acknowledge its failures and to address the issues
fundamental to CSS’s overly-simplistic syntax that has stunted web development
for over a decade now. By trying to make CSS “Simple” through simple sytax, the
working group has instead achieved incomprehensible property spaghetti. It is
time for a division of labor. Give new syntactic sugar and browser awareness
to the very best developers among us. Those developers can work together to
make beginner-friendly APIs for CSS like jQuery has done for the DOM.

Stylesheet abstraction has gone mainstream and it’s time for CSS to embrace this
new direction and use it to everyone’s advantage. If the CSSWG will commit
to this direction, I will do everything in my power to support your efforts and
make the end result a Stylesheet language that people love.

About Me

I am an open source hacker and stylesheet architect at LinkedIn.
I live in San Jose, California with my wife and daughter.

Open Source

I'm the creator of Compass, a stylesheet authoring framework
and I'm on the core team of
Sass — the stylesheet syntax upon which Compass is built.
I maintain about a dozen less well known ruby libraries and rails plugins on
github,
and am an active contributor of patches to the many open source projects that I use.