Should the W3C and WHATWG Die?

In case you missed it, on January 7 a developer named Dmitrii Dimandt wrote quite a scathing rant (strong language, beware) against the W3C and WHATWG, the web platform standards bodies.

I rarely, if ever, publicize links to content that contains language or other questionable material. But in this case, I have to admit, it almost feels like Dimitrii was just saying what many of us have been thinking all along.

The fact that the simplest tasks in layouts are often so complicated in CSS frustrates everyone. It shouldn’t be this way, and Dimitrii just let it all out.

Fortunately, cooler heads prevailed and a few calmer responses have been posted, one by Dimitrii himself. Here are all three relevant posts:

Here’s a quote from Dimitrii’s last post:

“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.”

I have to admit, I’ve had the same thoughts many times when reading the specs. So all I can say is, Dimitrii, you’re not alone. But I doubt the solution is as simple as starting over.

Note: This was originally included in this week’s SitePoint newsletter, so we thought it would be a good topic to open up to the forums. What does everyone think? Would there be any benefit to essentially “starting over” when it comes to web standards and the web platform?


The alternative is a jumbled mess where every single browser does its own thing - a return to the bad old days of Netscape 4 and IE4

document.all DOM and document.layers DOM isnstead of one that works across all different browsers.

JSS stylesheets and other variants that are completely different depending on which browser you are using.

It would be a matter of picking which browser you wanted your pages to work with and forgetting about all the other browsers (or developing the same pages over again for each browser).

The standards that those organisations have produced may not be the nicest alternative but at least all browsers implement the same mess rather than each implementing their own completely different mess.

Anyway, an attempt was made to start over with designing HTML - it was called XHTML 2.0 and had lots of streamlining of tags compared to the existing ones - eg. tags with the level being determined by the nesting rather than a number in the tag name and being able to make anything a link by including an href attribute in any tag - so that the <a> tag no longer existed. That effort was eventually abandoned because too many pages have been written following the current messy standard and most people don’t want change.

That people don’t want change can also be seen from how popular but completely unnecessary tags that were declared to be obsolete in XHTML 1.0 have been reintroduced into XHTML 5 even though the better replacements now work properly across all browsers.

1 Like

I can get things vertically aligned in CSS using 3 lines of CSS. Really complicated, right?

Sounds like part of his issues is his lack of fully understanding CSS. I honestly can’t think of much of what is broken about CSS (or that I’d change; more on that later in a below paragraph.)

He complains that the vertical align property should be used for this and he doesn’t/can’t accept the fact that it’s not for every element type.

As far as this quote

Can you name/find a single person on this Earth who would need *-reverse directions? 

Sure, I’ll be that person. I’m sure that eventually, I might need it. I bet doing this was pretty simple, why not throw it in?

He complains about CSS but I don’t think it’s justified. I admit that the specification is not exactly my cup of tea, but starting completely over shouldn’t be even on the table. The suggestions he gave on how to progress further from this…I like them, but what exactly would he change about the current CSS? I ask this because I really have no quarrels about how CSS is implemented. It would have been nice to have stuff like float:bottom or something else, perhaps percentage heights that don’t need an explicit parent height, but cmon, this is really harsh. The W3C has come a long way with CSS and I’m really proud of their work. Look at all the cool stuff we can do!

I don’t mind that the W3C people may not have done web development in a while. I like the work they are doing.

. Look at each and every steaming pile of horse manure that they produce: all this bloat, all these insane attributes and measurements stem from the fact that someone somewhere produced an insanely convoluted theoretial example of a non-existent problem and produced a solution to it.

So he hates the fact that there isn’t a one-size-fits-all approach to web development? What a joke.

1 Like

I’d think they wouldn’t have done much web development at all - they are too busy creating web browsers to have time to actually write much code to run in the browsers they are creating.

What most people overlook is that the standards define what the browsers need to support - not what you should be using in your web pages.

1 Like

I was just going off the above poster (or the article, I forget.) I’d rather judge them by their work; which I have NO problems with. I think they are doing a good job; as good as one can do with their line of work.

Thanks for the clarification.

Maybe he’d prefer the simpler times when there were only monochrome monitors?

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

This is hilarious, especially since I know this problem has existed for a long time. I could pull up code right now from 2002 that sought to fix the no CSS variable or Mixin problems. The verbosity is something else that is mind boggling why CSS has not implemented.

.class1 { color: red }
.class1 > span.blueit { color: blue }

instead of just

.class1 {
    color: red;
    > span.blueit { 
         color: blue 

When you start getting into the several hundred lines of CSS, that verbosity makes becomes daunting and does nothing but lead to hundreds of extra unneeded classes which becomes confusing.

You can implement a hack to align things vertically in CSS. You cannot align them natively, which is what the author was referring to. If you’ve ever seen code from the Netscape or IE4/5 days, they are nothing but hacks. The entire idea of aligning a page with tables is one of them. Vertically aligning things today in CSS is no different. Same thing with margin:0 auto.

I don’t know about that. Do you mean with “display: table” and such? Keep in mind that he’s not talking about just basic vertical alignment in a known height container, and with a fixed height element. We’re talking about vertical alignment in the unknown. That is, we don’t know the height of the container and we don’t know the height of the element. I think tables is the only way to get that working, but it still has its drawbacks. And all other solutions are either hacks or don’t work cross-browser. Or else they don’t encourage page flow (e.g. using absolute positioning).


Pretty sure that table cells can be whatever height I want (fluid) and it’ll still center. I’m not sure why you think table cells can’t vertical align in any height dynamically?

So yes, this is vertical alignment “in the unknown.”

1 Like

No, I wasn’t saying that you can’t do that. I was saying that that is the only way. And when elements aren’t naturally tables, people tend to shy away from converting them to tables.

So just to reiterate: Yes, you can do it with table layout, but it then has the drawbacks associated with tables (for example, the container element isn’t “block” anymore and so you have to apply “width: 100%” do it, if I remember correctly).

1 Like

What’s wrong with using display table route for vertical alignment? The only reason not to use the HTML version is semantics, but there is NOTHING wrong about using the CSS version. I don’t see what’s wrong about using CSS in this mannor. @PaulOB , I imagine, would agree (believe he has the same view as me on this IIRC.)

The width comment you made about tables, there are many ways to get around that, not just setting the width to be 100%. Although that’s not an issue big enough to make me not use it.

As long as it has the proper parents. Do you give it a proper table-row and table parent every time you use table-cell as described by the w3c specification? Because if you don’t, there is nothing saying that browsers have to display this the way you want it to.

And if you do give it the proper parents, why not just make a <table> in the first place?

Like I said earlier, hacks. If it’s not defined specifically for this use in some specification somewhere that keeps everyone in technology playing on the same field, it’s a hack. Plain and simple. So if Chrome 40 says it wants to display a <div style="display:table-cell"> as display:block, it’s free to do so and you’re the one who’s wrong for trying to do it another way.

That’s for all of the specification. Luckily, all browsers know what you want in regards to only “needing” table/table-cell (provide me an example that contradicts me.)

As said earlier, the specification is only a recommendation; it’s not law.

Right, that precisely why IE6 sucks so much. It did many things against specification.

Early IE went rogue from the specification (IIRC, there are a business reason behind it or something; trying to set the standard?) but since then, they’ve been on the right track.

Bit of a moot point at this point in the web development timeline since it’s been about 4 years or so. Maybe 5 since that’s been relevant.

Yes. Going against the specification is why it’s so hard to properly support. Using a lone table-cell is against specification and browsers in the future decide to not support it, which they are free to do, then you’re SoL if that’s what you’ve been doing.

One good thing about CSS, is that once something is supported and the functionality is in place, it never changes (can’t think of anything that has.)

The functionality is now in place and works perfectly everywhere.

So I’m confident in never needing to ever change my code. No point for browsers to change it; nothing is broken. Not worth their time.

It is frustrating that layout is still so awkward in CSS, but I don’t envy the task of spec writing. Indeed, with so many voices and issues to deal with, I’m amazed anything gets done at all. A graphic designer friend of mine is continually amazed at how clunky CSS layout is compared with something like InDesign … but web layout is so much more complicated, because there are so many more variables.

I’ve not really heard an alternative approach that seems viable so far. A rant is fun and all, but I don’t really see a viable alternative being proposed. A small group of people who dictate terms? I kind of thought that’s effectively what the WHATWG was anyway, and look how happy people are with that … Can you imagine all the flack a small team would get over what they had produced without consultation? Seems better to me to have all the discussions before the final product is laid out, as messy as they are.

CCSS? GSS? Oh my, they look impressive, but looking at that stuff (for me at least) is like trying to imagine the outer limit of the universe: in the end, your mind panics and you just want to embrace something simple, familiar and comprehensible—like simple, dear old CSS. :slight_smile:

@louislazaris I love the fact that newsletter intros are appearing as posts we can comment on! I’m often keen to reply to those. :stuck_out_tongue:


You’re missing the point. The author’s point is that there is no w3c specification for things like this. You’re doing something against specification because people figured out that spec was stupid and saying there is nothing wrong with the specification, then claiming he doesn’t understand CSS.

This isn’t the only case of this against specification, but still works. They are riddled throughout both HTML and CSS much of what you think of as “knowledge of CSS” is simply learning ways to do things that you need to do because the specifications don’t allow for it. Which is what the author’s first words were referencing:

Web-developers have the worst ever Stockholm syndrome ever in the history of the world ever.

And yes, things do get deprecated and marked for removal. HTML styling tags, like <center> and <font> are some of the recent ones, here are the rest. I believe the only one to actually be removed has been <blink>, because it was put in because they were drunk (literally).

No point for browsers to change it; nothing is broken.

A lot is broken. That’s why the smart browser developers don’t pay strict attention to the standard like they should. Back to the first words of the article again:

Web-developers have the worst ever Stockholm syndrome ever in the history of the world ever.

What’s broken about using display table/table cell? Every code sampel I’ve ever tried recognizes it just fine. Care to show me a jsfiddle or codepen?

It’s not feasible for the specification to go over every little detail. Browsers worked it out. Browsers are now uniform on it. Thus nothing in the future is broken.

Werent CENTER and FONT made before CSS was even made? Yeah they would eventually have to be deprecated and hopefully eventually removed (if HTML emails ever get their a$$ in gear.)