In a way, IE is doing us a favor by not supporting HTML5 until it’s actually ready. The mad rush to implement something that isn’t finished yet will come back to bite us all.
Assuming that steaming pile of dung will EVER be ready, or should even be adopted for use in the first place given the loosening of structural rules, pointless redundant new tags, pointless wrappers masquerading as semantics, further fracturing the already screwed up world of codecs in the name of letting each browser maker pimp their own favorite codec (instead of letting the user decide which one they want and which they don’t), and general pissing on the ashes of all the progress STRICT has given us the past dozen years…
Again, I can’t believe ANYONE is DUMB ENOUGH to WANT to use it!!! The handful of ‘neat’ things it actually offers (the really neat ones having NOTHING to do with markup!) doesn’t make up for the trip in the wayback machine with Mr. Peabody on coding practices. Carefully crafted for the people who until recently vomit up HTML 3.2 and slapped a tranny on it, and today just slap 5 lip-service on it – churning out code WORSE than Frontpage did a decade ago.
Net improvement zero.
Which of course is why they had to put CSS3, CANVAS and the new javascript under it’s banner – NONE of which have anything to do with MARKUP. Remove those, and the Emperor is naked… and not the fun type of naked either.
But of course, it’s “new and shiny” giving book writers excuse to squeeze out another puppy, let professional lecturers fill another hall, and sleazeball scam artists once again practice nube predation using it like another sick buzzword on the people too stupid to know what “web 2.0” REALLY meant.
Lol, DS, as blunt as ever.
Though, I do have to agree with you a lot. I’ve looked over the HTML5 stuff over and over thinking “okay, it’s about time I start using some of this”… and yet I never do. =p
I have been slapping on the HTML5 DOCTYPE (because I love it), but that’s the extend of my HTML5-ing (well, and the use of canvas, but like you said, that’s really more JS). I don’t see much point behind all of the other elements. I mean, I get the point behind some of them, like the section tag, but at the moment, those have no more semantic meaning than div.
But apart from that, HTML5 OK, right? 
I don’t necessarily mind the idea of a “living” standard, which gradually adds features to HTML. When they are fully supported—and if they don’t suck—I might use them. A few little things like the extra form attributes and and maybe associating an image with a caption seem OK to me, but that’s about all at the moment.
I’d really just prefer everything to be done at once, everything supported at once.
If little bits of stuff keeps getting added every month, it’ll be a hassle to keep up with. I really would love HTML5 to become a standard, along with CSS3 (mainly CSS3 being fully supported) but we have a long ways to go :()
But if a feature is finished and ready to go, why not use it? It’s like computers: every year some new feature/technology becomes available. Do you want to wait ten years to get a computer—when all of the great ideas people have now have been mastered an implemented?
The main problem for me is that to be a standard it has to be treated in a similar way across the major browsers or, at the very least it has to have a standard applied to it other than “This is cool and people already do it lots of other ways, we’ve gotta stay fresh”. HTML will never be improved by diversifying how it works and what it does to the point of completely changing or abandoning what it is.
If it’s supported everywhere, then by all means I’ll use it, if it’s needed of course.
The patches of support we have right now, wokring in some but not all, leads me to not even want to mess with it at all, at least not for a while until more support is given.
A few little things like identifying an input as an email field are handy for people using smart phones. That’s about all I’ve tried.
However, actually, the new Javascript APIs such as History and LocalStorage are, in fact, absolutely part of the HTML5 spec.
This being, the WHATWG (and apparently also the W3C) thought it was a mistake that while HTML (and therefore rules about the DOM) were specified, Javascript was left as an afterthought. In HTML5, as they made changes to the DOM, changes to elements attributes, etc (notice the HTML4 spec lists which Javascript methods any given tag MAY have on it?), they realised they needed to include Javascript as a first-class citizen.
In other words, the new Javascript stuff depends entirely on a new DOM, new native methods on tags both old and new, new properties on tags, and new default browser behaviours. Everything else we hear about being all awesome and new is called ecmascript5 and use strict and about a thousand new libraries popping up like molehills every month.
With all that said, I guess I would then have to allow <canvas> in there too. Just as <object> is just a tag who usually just holds some Flash, <canvas> is a place in the DOM where a particular API can be used.
Off Topic:
Someone wrote a “book” on how to make a Web App. It comes with some “examples” (most are not real), one of which is a map app where there were such recommendations as “use HTML5 placeholders to give users information” (instead of labels, and the image shown has zero labels), “hide navigation elements” (this page I must be too stupid to use because I clicked around the pages randomly until I accidentally discovered I was supposed to click on the edges of the book pages) and “use canvas to draw the map”. After this book stated that CSS3 was HTML5, I skimmed further a bit before leaving.
Off Topic:
I think that really comes down to editors just letting authors spout whatever nonsense they wish, without doing any real fact checking, because the book will sell to the uneducated masses that buy into all the hype. That’s why I generally only get computer books from a small handful of publishes that generally know what they are talking about (O’Reily and Sitepoint being two of the biggies). Other than my small group of publishers, I’ll only pick up books by well respected authorities, or ones which I know enough about already that I can fact check it myself. =p
Off Topic:
Completely agree.
Though if I do have free time, I’ll go to the local library and browse through the public collection of HTML/CSS knowledge. It’s quite humorous what you can see in there sometimes :). I’ll have to go back there sometime next week and see if I can find this one book that had a good bit of laughs in it.
How so? “Big deal, they rely on the DOM” has WHAT exactly to do with making markup or the markup language? It’s not like window.history.back and window.history.forward have ANYTHING to do with the markup on the page! Same goes for localStorage – no associated HTML elements, useless without scripting enabled, so how the devil does it have ANYTHING to do with HTML?
Again, see CANVAS – useless without scripting, so why couldn’t it simply have been a SCRIPTING side extension to the DOM only? There’s no reason for it to even have a new tag, and it would be a LOT more useful if we could simply go something like:
<div id="drawSurface">
This section requires Javascript's CANVAS extension
</div>
var target=document.getElementByID(target);
if (canvas.2dContext) var context=target.appendChild(canvas.2dContext);
Which is pretty close to how I’ve been working with CANVAS anyways, since I’ve not been putting the tag in the markup when I use it. It doesn’t need or warrant a tag, it just needs an object on the DOM – and since the DOM pretty much should mean JACK to HTML itself… (being a scripting, CSS, and browser IMPLEMENTATION concept, NOT a HTML one).
Hence why there was no such thing as a “document object model” in HTML until CSS and Scripting entered the scene? You know, the entire reason that until HTML 5 there was ZERO mention of the DOM in the specification since HTML by itself SHOULDN’T NEED one? Nor do browsers if all they do is HTML – it’s just really convenient once you start applying CSS and pretty much needed for scripting… which is why it should be in the SCRIPTING part of the specification as it’s the only thing (other than the browser itself) that “needs” it. It has absolutely nothing to do with “markup” or writing good markup.
Which is why it’s not in the HTML 4.01 spec. There’s no reason for it to be there.
[ot]
Sounds like you get the same reaction to some books I do… which reminds me of Ian’s video for HTML&CSS “the right way” where he talks about going into a bookstore.
Been there…[/ot]
They (WHATWG, and now also W3C) do not limit the HTML spec to “markup” anymore. That’s what changed.
I can only guess… that it had something to do with how Apple implemented their originally proprietary drawing idea? Could ask the canvas guys…
Well, here’s one answer I got:
"Why not an element?
Or, perhaps more usefully, it’s a script-generated <img>. It seems appropriate for it to have a tag just like <img> does."
Which I think is what you’re missing about what I’m saying – as that’s EXACTLY what I’ve been complaining about in regards to it. It’s a STUPID CHANGE for NO good reason. Taking an already needlessly complex “specification” and slapping unrelated crap under it’s banner just makes it so NOBODY can follow or understand markup, much less the other stuff they’ve added to it… at least not by using the specification as your guide.
While I agree mostly DS, I do have to defend them a bit. If they didn’t put it with HTML5, where would they put it? Make another new specification? That’s all we need, more specifications and acronyms to keep track of. =p
In the ECMAScript specificiation where it belongs… and WAS. It’s not making “another new specification” it’s leaving a separate specification where it was, as a separate specification. You want to learn about MARKUP, you go to the HyperText MARKUP Language spec… you want to learn about scripting, you go to the ECMASCRIPT specification, you want to learn about CSS, you go to the Cascading Style Sheet specification.
Slapping them all under HTML just makes it bigger and harder to navigate; and blurs the line between things that are distinct and separate, no matter if they work together. I file this under the stupidity of removing versioning from it – you can tell NOBODY with an engineering background has ANYTHING to do with the WhatWG!
Sure. In the ideal world it would be nice to have everything neatly organized in it’s own little box. Problem is, it just doesn’t work. It’s been almost 15 years since HTML 4 was released. And what has happened since then? Lot’s of diversions into different ways to extend it but no real progress. The ecmascript is great except no one follows it so you need something like jquery for even the most basic stuff. And css for layouts? Custom style sheets for each and every version of every browser. Not real fun to maintain.
It was the above chaos that pretty much caused the formation of whatwg in the first place. Their mission statement is quite clear:
This specification is limited to providing a semantic-level markup language and associated semantic-level scripting APIs for authoring accessible pages on the Web ranging from static documents to dynamic applications.
Best approach? Maybe not. But thanks to these guys, those of us that actually build sites, can now put ‘required’ on our input elements with a reasonable expectation that modern browsers will properly deal with it.
Only took 15 years but I’ll take it.