Browsers vs Standards: Fight!

Ladies and Gentlemen! For tonight’s fight, in the blue corner, weighing in at two and a half billion users, Wooorldwiiide Weeeebbb BROWSERS!!!! And in the Red corner, weighing in at hundreds of corporations, institutions and individuals, Oooficiaaall Weeeebbb STANDARDS!!!

Browsers versus Standards may sound a bit weird, but if you are a web developer like me you may have had the feeling too sometimes that some standards as described by the organizations governing them actually seem to be hurting your attempts to write cross-browser compatible web pages. For example:

Phasing out basic elements such as b, i and u and leaving the iframe element out of the strict doctype.
Deprecating text/javascript as a mime type for Javascript code.
Limiting the use of text/html for xhtml to xhtml 1.0 only.
Trying to replace the img tag with the more generic object tag.

For some years, after finishing HTML 4, W3C has been, in my opinion, straying from ‘the path’ when they ventured into the dark woods of xhtml 1.1 and 2 and it’s many modules. They had made HTML so complex, just trying to figure out what doctype to use for your new HTML template could lead to hours and hours of internet research, leaving you more confused afterwards than you started out.

Just search the web for things like “doctype”, “html strict”, “mime type”, “deprecated html” etc and you’ll soon find lots and lots of questions, answers (often conflicting with one another) and debate about these topics. It all was very unclear. I blame the W3C for pointing the world into the wrong direction when it comes to the future of the web.

You see according to the W3C vision, HTML should have been modular around now. We would be writing our documents in (x)html strict, using just a small set of core elements. When the need would arise for some other elements, we would bolt in an extra module instead of stuffing the core language with tags. However, instead of just defining XHTML 1.0 as the successor to HTML transitional and built extra modules around that to support new technology, a lot of focus was spent on removing stuff instead. You would read on a regular basis about all the stuff you should no longer use and read very little about cool new stuff you could use. Often there weren’t even good alternatives to do the things that the removed elements did, so you were actually asked to do a step back on functionality. Any programmer trying to follow the ‘strict’ path of W3C has had a very hard time. Now this in itself is bad, but even worse is, what did he get in return?

Not very much. Definitely not better cross-browser support. It made that worse in fact. You see, a lot of the features that were ‘forbidden’ in W3C’s view of the future web actually worked pretty well cross-browser. But their alternatives often did not. So you had to choose: Standards or Browsers?

Smaller parsers could be made, so we were promised, enabling web browsers on mobile phones. But when the time came for mobile phone vendors to implement, they chose to support the existing web instead of the future web. And I’m willing to bet that as of today, it’s still easier to support phones with your site targeting legacy html, including all the obsolete tags, than with xhtml 2.

But the future is bright! Fortunately now with HTML 5, a lot of those ideas are actually given up on. We don’t choose a doctype anymore, we just write

<!DOCTYPE html>

And thank god for that. A lot of the effort of HTML 5 was aimed at unification. WhatWG, the people behind it, had recognized that all these versions and doctypes were causing fragmentation, hindering instead of promoting universal browser support. So they just abandoned them. They are not missed, as in practice browsers never used different rendering engines for them anyway. They never really made it past the W3C validator.

HTML 5 also undeprecates some of the aforementioned tags! Instead of insisting these were styling mixed in with markup and thus evil and had to die, they recognized that these styles are commonly associated with some semantic meaning and re-introduced them into the standard.

Now if we can just get IANA to un-deprecate text/javascript and promote it to *the* recommended media type…

What did you do? Did you try to follow W3C or did you just used what worked? Leave a comment with your experiences on this subject, I’d love to know what other people think about this.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s