Google has given Microsoft a virtual bear hug, lauding the Redmond software giant for finally joining the push for a new-age HTML. In early August, Internet Explorer product manager Adrian Bateman suddenly appeared on a World Wide Web Consortium (W3C) mailing list dedicated to the still-gestating HTML 5 standard, and this simple …
Write once, run anywhere indeed? Schmidt ignores the lessons of history.
Well,. this is marketing bullshit, not a serious analysis, but damn! Is that guy full of it! We've had Java, we've had AJAX, we've had The Last One, none of them actually did that and this won't either. It's a bunch of handy extensions to our already-existing infrastructure, not a complete category shift.
And I for one am not impressed by the notion of "plugin-free" video. Wow, so you've gone and compiled a statically-linked plugin directly into the browser, that's so amazing. Not. All it really means is that now we'll have to have full browser updates whenever a bug is found in either browser OR media player component, instead of being able to update them separately like we can now. Yeah, real smart move there Einstein.
However, as a hacker, I am looking forward to playing with the new client-side database and cross-document messaging features. I feel sure that these will help me overcome the problems that HTML4 causes me with cross-domain security issues, by allowing many ways for my malicious data to spread beyond its supposed limits inside the browser architecture, and thereore I feel confident it will help me leverage the power of my existing clients ... blah blah blah enabling creative synergy ... blah blah blah win blah blah cloud blah paradigm shift blah blah blah counterpoint the surrealism of the underlying metaphor blah blah blah LOLROFL UR SO PWNT!
Or in other words, this is all a big plateful of nothing special, with a marketing side-order of steaming great heap and a fail-lose-pwn salad to go with it.
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.
Of course, if one were to be cynical
one could posit the suggestion that MS has only started collaborating in order to steer HTML5 in directions it considers advantageous...
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.
RE: Funnily enough...
Dude, your comment is 279 words longer than the article! I'd like to congratulate you on getting the longest relevant comment posted on El Reg (that I know of anyway!)
Also, I agree!
AC wrote: "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."
Yeah, maybe you can get rid of "img" as well while you're at it and introduce <div class="image">.
If you've got something to say, tell your boss and make sure the guys defining the spec know about it. If you're not prepared to do that (or if your idea is shot down in flames) then you'll know you're a retard.
@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.
Re: Funnily enough...
Agree with the verbose AC! The HTML5 stuff advocacy ("Well-formed XML is, like, too difficult, man!") is like advocacy for a child handing in some half-hearted scrawl as homework and demanding that they get an A+ just to reward them for not giving the excuse about the dog eating it. Add to it the usual standards front-running (the spec author worked for Opera for a bit, then Google) and the daily dosage of shiny ("We need to bypass the whole thing and blit to the browser window!"), and it's a step down from HTML as we know it.
As far as the video stuff is concerned, Microsoft, Nokia and Apple will still drag their feet over genuinely open standards, hoping to spike the whole thing with patents (while claiming that the patent landscape is "uncertain", having cultivated that very landscape themselves), and Google will presumably continue to undermine the licensing of libraries like ffmpeg in spirit, if not actually violating such licensing outright, by distributing such code under non-transferable patent licences.
Re: Funnily enough:
Sorry bud, gonna have to knock XHTML off that little pedastal you've built for it. Don't get me wrong HTML 5 *IS* attrocious but XHTML is far worse. This post is gonna be pretty bitchy - this is therapy for the many hours of pain inflicted on me by XHTML.
My main gripe is in your assertion of XHTML being better because it parses using XML - which it is to be fair. The problem is that XHTML gets parsed with XML in THEORY but seldom does in practice. For most browsers, XHTML only gets parsed as such when the file is sent from the webserver with an application/xml+html mime type. What actually happens in most web browsers is the XHTML page gets paged as HTML with the error correction fixing the /> end tags.
"Oh well, minor inconvienience..." thinks our hypothetical webdeveloper, "I'll just change Apache's config files to send the correct mime type. Better test if everything still works right."
Only there are a few problems; everything gets parsed differently and the site breaks horribly - this is inconvienient but fixable. However the elephant in the room is that MS IE 6 can't actually parse XHTML with the correct mime type and just displays a blank white page. Oh dear...
Before anyone pipes up saying "well just drop IE 6 support", let me point out that most sites can't afford to lose 15% of customers - and this isn't just "website breaks a bit" either, IE 6 users simply won't be able to view your site.
Of course, that's just the big practical hurdle, there's the irksome problem of using the language properly too. Here's a few examples:
The reason for the hideous escape code is that in XHTML script and style tags get defined as #PCDATA blocks rather than #CDATA blocks, so the HTML comments <!-- really ARE comment tags and don't get ignored by the parser.
Also, ever tried saving an XHTML file that's been served properly? Try opening it afterwards. One of two things happens, depending on the file extension, either: the file gets parsed as HTML or the file gets parsed as XML (meaning it looks like a big list of coloured tags). Really portable that.
While we're on the subject of portability, let's briefly discuss the notion of being able to pass your XHTML to other programs and grab data out of it using an XML parser. This is actually a really cool idea, there's just one problem; we've been able to do this with regular HTML using an SGML parser for the past decade!
So the one really good thing XHTML has going for it is that we can embed other XML based languages in it, such as SVG. Which is actually really cool, I'll admit. Only downside is that literally one browser has an embedded SVG parser. Oh there are plugins available for the others - they all just don't play nice together. Arses.
The fact is that almost everyone whinging about how HTML 5 is a massive step backwards have never ever used XHTML, they just wrote HTML 4 markup with lower case tags and /> tag endings. Yes XHTML *COULD* be friggin awesome, but it is riddled with implementation problems amongst the various browser vendors (I'm look at you in particular Microsoft).
As for XHTML 2... some things should not be spoken of. Let's just summarise it as "Not backwards compatible with XHTML 1/HTML 4" and leave it at that.
Somebody should point out to Eric Schmidt
That the word 'win' is a verb, not a noun, and then shoot him for using the word 'paradigm' wiothout a hint of irony.
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, 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.
"But there's still the rather thorny matter of which compression technology those tags will use."
What thorny matter? Most PCs will already have a slew of CODECs sitting on them, usable by *any* software which does the appropriate API call (personally, I use CCCP - between FFMPEG and the stand-alones, I can watch just about anything in most players.)
So what's so effing hard about making a video tag which specifies the encode, and having the browser look for the appropriate CODEC *just* *like* *other* *players*? (ditto with the audio end, TYVM)
The last thing I want is yet another 5Mb of code bundled into my browser just in case I want to watch videos embedded in a web-page. What's the point of having spent all this time developing the concept of SHL/DLLs if you're simply going to compile the whole thing together anyway?
Leave the decoding to the CODECs and work on the GUI, you idiots.
- Infosec geniuses hack a Canon PRINTER and install DOOM
- Feature Be your own Big Brother: Monitoring your manor, the easy way
- Boffins say they've got Lithium batteries the wrong way around
- In a spin: Samsung accuses LG exec of washing machine SABOTAGE
- Phones 4u slips into administration after EE cuts ties with Brit mobe retailer