Ok, W3C and WHATWG, don’t die, but…

Dmitrii
6 min readJan 8, 2015

I’ve received a fair amount of responses to my previous text. Time for a follow up.

ToC

  • What’s up with the rant?
  • Breaking changes are hard
  • Why would browser implementors want to get rid of their current implementations?
  • Hey, this funny guy makes fun of my title
  • Join, review, speak up
  • Questions, do you ask them?

What’s up with the rant?

The most valid complaint is: less rant and rage, more sense. But hey, what’s internet without rants? ;) However, the complaint is oh so true. Less rant in the follow up, I promise.

Oh. I also have much less gripe with WHATWG, than with W3C ☺ HTML5 and even DOM are kinda ok ☺

Breaking changes are hard

Another valid point: it’s very hard to introduce any breaking changes to the web and get people to adopt and to adapt. This fear is especially true for browser implementers, because implementing a breaking change may cast their browser away, to the sideroads. However…

  • Chrome is continuously experimenting with new features: they’ve introduced SPDY, WebP, WebM. SPDY went on to become the foundation of HTTP 2.0 (another rather major change to the web)
  • Microsoft is actually dropping support for old stuff in their new browser. I mean… Microsoft, who are hell-bent on backwards compatibility of everything forever.

So, it’s still risky, but not impossible to introduce major/backwards incompatible/breaking changes to the web… In a gentle way. Keep the old stuff working, actively promote and ecourage the new stuff. Yes, some of the old sites may never die. But don’t forget the 80/20 rule. It might be beneficial to the entire web eventually leave only the absolute minimum support for some old features (hey, remember the <blink> tag?).

It’s not impossible to imagine a backwards incompatible CSS4 with a separate renderer that:

  • cannot be mixed with CSS3 on the same page
  • triggers the new renderer by a mediatype, file extension or a special directive in the file (akin to “use strict” in JS)

So, render old stuff with the old renderer, render the new stuff with the new renderer.

I wouldn’t worry about the standard being picked up, provided it does away with the cruft, bloat, legacy and inconsistencies of the old standard. Even sites with huge user shares eventually drop support for older browsers (see, e.g. Facebook: 1, 2, 3) and pick up new features. Also, nowadays browsers are updated rather quickly.

Also, we are at a weird point in time when browser implementors and vendors more or less agree with each other. Can I Use is a testament to that. There’s actually hardly a specification without wide or upcoming support.

Why would browser implementors want to get rid of their current implementations?

Because they are programmers.

This is not a scientifically backed up argument, but still: no one wants to work on an old, complex (and getting increasingly complex) code. Especially if it’s millions of lines of code. Especially if it’s a system that gets burdened with more and more layers of rules on top of each other (hey, kids, how do you reconcile css3-align with css3-grid-layout in a css3-flexbox in a float in a …). There’s rules in rules on top of rules hampered or overriden by other rules and so on. And it has to be insanely fast. And it has to be correct, for some definition of correct, as there’s no reference implemetation, only tests (which are woefully incomplete and may target outdated versions of HTML: 1, 2).

BTW, the lack of tests is not a jab at their authors. The sheer amount and complexity of the specs make it impossible to create enough tests (css3-align in a css3-grid-layout in a… you get the point). I’m half expecting CSS to finally adopt C++’s approach and add “implementation-dependent” or “undefined” clauses ☺

Hey, this funny guy makes fun of my title

One problem I have with some/many/most of the specs that come out of W3C and WHATWG is that I don’t feel they are made by people who are doing any serious frontend web-development, or at least haven’t done it for a looooong time.

The main reason for thinking so is that it’s very hard to find evidence of any authors doing any of the (let’s call it) modern web-development. Yes, they hold high positions at various companies/groups/universities/committees, they hack specs/work on web standards, they work on browser code. But what of actual frontend web-development?

I mean, have you ever developed a complex and/or beautiful website? There are quite a few of them around: Facebook, Gmail, Asana, Google Docs/iCloud, Medium, CSS Zen Garden, various Tumblr designs, Pinterest, Rdio — you name it.

Because if they’d ever develop such a site, we wouldn’t end up in a situation when a simple menu requires 4-level nesting of <div>’s to display a simple menu even on the web-site dedicated to promoting CSS3:

<div class="main">
<div class="content_holder">
<div class="menu_search">
<div class="menu">
<ul>...

(W3C own site manages to do it with only 3 nested divs. Medium needs 4, and each element is another div. Well, you get the picture)

As an aside: I was told that Facebook is a trivial site to implement in CSS. But have you actually *looked* at what a Facebook page is? There’s multiple layouts, panels, panels within panels, buttons and drop-down menus everywhere, floating content, fixed content, pop-ups, highlights, embedded content, tigers, and lions, and bears, oh my. It’s not trivial.

Another reason I don’t believe they are doing any serious web-development is the time it takes some features to appear (if ever).

Cases that stuck in my mind.

  1. By 2006 CSS had been around for 10 years. DOM and XPath about the same. It turned out that it was easier to implement CSS Selector and XPath lookups in JavaScript than to wait for querySelector to appear and make its way through W3C. And what a surprise, there’s actual evidence that the author of the spec actually was a web-developer (hence the useful spec, I presume).
  2. SASS (2007) and LESS (2009). As of 2015 (almost 20 years after CSS appeared) there’s exactly 0 proposals offering anything remotely similar.
    Edit: there is a spec for css variables, thanks to Tim Severien for pointing this out
  3. css3-marquee is a Candidate Recommendation, way ahead of css3-flexbox (solving the nested divs from above) and grid-layout (basically 100% of css frameworks out there), for example. Or even ahead of css3-align which, apparently, finally lets you vertically align elements.

In an extended Twitter conversation I was told that most of the discussion is driven by the browser implementers. Maybe that’s the reason behind the weird specs, late or non-existent features and the continuing unsuitability of CSS for anything but the most basic layout. People who are good at implementing browser code might not necessarily be good frontend web-developers (or web-developers at all).

Join, review, speak up

It was suggested (and this is also a very valid point) that anyone who has anything to say on the matter, should join the mailing lists, speak up, and review the specs.

However, I must confess: I don’t believe in this approach. The problem with too many people having an input is that:

  • the loudest one wins in the end, and
  • any decisions, designs, and implementations are dragged down by endless discussions (from the admittedly few discussions I’ve seen on W3C’s mailing lists, this is quite often the case)

I would rather like to see a smaller, more focused group of people working to implement a lean and mean standard than a thousand people debating whether a particular fringe/weird case is relevant.

Questions, do you ask them?

Any and all specs by necessity contain only the simplest examples. A single floating div. Four divs in a grid. And so on. The real web is much more complex than that.

I’m not too familiar with W3C’s or WHATWG’s discussions, but I wonder if people ever ask questions beyond simple examples?

  • Hey, here’s a Facebook page. Can you show how I can implement it in it’s entirety using your CSS proposal(s)?
  • Does your solution involve nested <div>’s to represent a menu? Your solution is bad
  • Does your solution involve setting several properties on the container, and on the element, and on the elements contained in the element to make them display properly? Your solution is bad
  • Does your solution involve fiddling with positioning modes, parent’s and child’s sizes, and so on just to set a child’s offset within the parent relative to the parent? Your solution is bad
  • Can your solution involving three different attributes, and a shorthand attribute, and several different measurement units be replaced by a single shorthand rule with a single unit? Your solution is bad, replace it

And so on. Replace Facebook with any website (or even Sencha’s examples), rinse, repeat. Until you get an actual pragmatic solution. Ditch the fringe cases. Ditch the theoretical “I can imagine when x could be useful”. Go for pragmatic.

Also, look at what people are doing to improve CSS (or HTML/DOM for that matter) (jQuery, SASS, LESS, Grid Style Sheets) and go and standardise those. These are the things that people want and need.

--

--