Google bear hugs Microsoft in web standards team tag

Funnily enough...

I've always respected Google and thought they had their head screwed on straight, but they seem to have completely and utterly lost the plot on HTML5.

HTML5 does introduce some good new stuff (like the canvas stuff), but unfortunately in general it's absolutely atrocious, it's a massive step back for serious developers.

HTML is used to define document structure, but now we have content and presentation elements embedded in it- something XHTML was working to do away with. The argument is that by having tags like "header" and "video" we can move a step closer to a semantic web.

Put simply, that is utter fucking bollocks. The issue is you have this problem of arbitrarily defined tags in the spec, that have supposedly been decided based on the most popular classes/ids in existing pages across the web. The problem is, this isn't static- things change, whilst specs can take upto a decade from beginning to end. We've already seen changes in the web that have made the list of pre-defined tags aimed to make things more semantic questionable- where is the "comment" tag for example? What you'll end up with is half your markup as <header>, <video> and the other half as <div class="comment">, this may not seem like a big deal but it is- it removes consistency which is of utmost importance in large scale application development.

But there's a bigger issue, XML syntax enforcement is gone, it's only optional so now you have to have paths to parse both SGML and XML, which is a ball ache if you're trying to keep things lightweight. This coupled with the above pool of divs and normal tags will be a massive headache for page scraping, embedded developers and so on. Of course, this inconsistency = more code = more bugs.

The HTML spec should be lightweight and generic, <div class="whatever"> was fine for all structure based tags, the new approach offers nothing because if <footer> etc. are based on the most commonly used classes then just parse for the classes instead- that way you're not fixing the most common classes, something that changes dynamically overtime, with the spec, which is fixed and slow to change. A much better solution would be a semantic definition language, where you can tie real semantics to id's and classes, just like you can tie presentation to them with CSS. You could go as far as allowing browsers to contact semantic lookup servers to find semantic data for old, unmaintained pages- that's the real way forward if we want a truly semantic web.

HTML5 is awful, it's a mess, it's a horribly unprofessional spec, and it's completely useless to those who matter- enterprise application developers. Sure Joe Average can publish easier with HTML5, but Joe Average isn't using HTML anymore, they're using Facebook, MySpace, Wordpress, Twitter. In other words, they're using the the applications the enterprise application developers build, so cater to them, not the users who don't care anyway.

XHTML2 wasn't a great spec don't get me wrong, but you think it was bad? It was a godsend compared to this horrific childish mess of a spec that is HTML5.

Microsoft's comments pointed out some of this and questioned the arbitrary nature of some of the tags which is good, I find it ironic that it's taken Microsoft to be the company that realises how bad HTML5 is for application design, whilst Google seem to be celebrating the messiness, inconsistency of it.

But finally an important point, whichever is the new web standard is going to underly the web for the next decade or so. HTML5 is not a spec for the future, it's a spec for 90s style development- an unprofessional mish-mash of poorly defined, inconsistent tags. It does things that are big no-no's in building specs, it re-defines existing commonly acknowledged tags like bold, italic, underline, which should realistically be removed as CSS removes the need for them. Instead of removing, HTML5 keeps them in but then changes the meaning of them - what the fuck? who is writing this spec? an uneducated 10 year old? certainly not a worthwhile IT professional. Why would you keep obsolete features, but change the meaning to something poorly defined with the new meaning. HTML5 will hold the web back, the poorly defined nature of many parts of it will maintain the status quo of browser inconsistency and incompatibility. It will make real world application development much harder and more bug prone and at the end of the day, it brings little to the table in return that couldn't otherwise be implemented in a cleaner, better, more sensible spec.

HTML5 takes the rulebook of how to write a good specification and goes against everything in it.

Never bear hug a porcupine.

NT

@ jof

So far Microsoft's comments have been on the ball, pointing out idiocies in the HTML5 spec, so if Microsoft is steering it in directions it considers advantageous then please, let's have some more because apparently Microsoft seem to understand better than anyone else involved in the spec so far what needs to change in it. Google, Apple etc. have been cheering it along with various idiotic decisions kept in.

It's a strange world where we have to rely on Microsoft to try and fix a horrible spec.

@Of course, if one were to be cynical

That's not being cynical, of course that's why MS joined, and there's nothing wrong with that. If that's what they're doing then fair play to them (why do you think the others are there?).

If you were to be cynical you might say that MS has joined the party to disagree a lot and slow the whole thing down so that it's only released when it's already way out of date, all the while pushing it's windows only plugins at people who don't need them.

How times have changed

I find that Adrians feedback really does reflect the diametrically opposed stances in corporate culture between the old guard (MS) and the new (google, apple, et al) with a delicious historical irony.

I'm sure everyone remembers that it used to be MS who broke all the standards for their own nefarious reasons, introducing massive security holes in the process (activex, anyone?)

Googles gang fresh faced, eager little tikes have been enthusiastically bunging "wouldn't it be great if..." ideas into the pot then quickly moving onto the next with barely a second thought.

You only need to scan through the comments though, to see endless references saying 'concerned', 'risk', etc.

This is Adrians team very politely saying "Woah, woah, WOAH! What are you doing?!?! We've only just fixed half of this!"

The first and foremost priority of a new standard should be the complete sandboxing of the browser from the OS, as it's a primary attack surface no matter what browser or OS mix you're using.

Once you've isolated it completely from the OS, THEN you move on to "OK, it's as safe as we can make it, what do we need to put into the standards to make it work as a full blown application"

Now THAT's moving forward

@ Leon

Leon, all those issues you mention are to do with poor browser implementations.

Amusingly, it's the same browser vendors that have pushed the spec the way it is, and this is the crux of the problem. Browser developers may be able to write applications, but they clearly know jack shit about writing web applications.

Allowing browser vendors to run the show with the HTML5 spec is exactly what has gone wrong, I like Firefox, I like Opera, but these guys clearly have no idea what is required for a good HTML specification.

Effectively we're letting browser vendors dictate what shit web application developers have to put up with when instead we should be letting web application developers determine the spec, and it should be up to browser manufacturers to implement it.

Please realise your comments aren't about the XHTML spec, but about how the XHTML spec is handled- the XHTML spec is not the issue.

To cut a long story short- browser vendors are holding the whole fucking web back, and should be shot for their selfishness, incompetence, and general ignorance of what the web needs to take it forward. If web browser vendors were anywhere near competent, the issues you have faced with XHTML would not even exist.

Even XHTML2 not being backwards compatible would be a non-issue, really, when they have an XML parser in place already it's hardly difficult for them to implement the XHTML2 spec but instead they drag their feet over it for years and just don't bother. It could've been a quick, painless transition if there was even a semblance of competence amongst browser vendors- and yes, I mean you Firefox team as much as the IE team, the Chrome team, and the Safari team.

Bah, I still barely use anything but HTML 4.0 (strict) anyway

Thank <random deity> for backward compat, too.