I am an experienced web-developer (11 years and counting) and I have been keeping an eye on some aspects of HTML5 developments. However, I still find myself confused about some aspects of HTML5 and I’d like to ask you all about it if that was OK with you
<canvas>
Any interesting use of the <canvas> element requires the use of javascript that only ships with HTML5 compliant browsers - right? But it’s the context of that javascript that throws me. Javascript isn’t markup, so what’s it doing being part of a markup spec? Or is it just part of a new JS engine that supports specific manipulation of the <canvas> element, and only ships with HTML5-enabled browsers? (There’s a subtle, yet important distinction don’t you think?)
Incremental Approach?
It seems as if one can take an “incremental” approach to early-ish HTML5 adoption on small sites, blogs etc by simply restricting one’s-self to using markup such as <header>, <article>, <section>, <nav> etc -within an HTML5 doctype, styling with CSS and leaving it at that. Is this a correct assumption?
3rd Party Plugins
This is perhaps a debate on semantics more than anything else, but it does seem to me that some commentary on the web would have me believe that new video and audio technology such as WebM and its ilk are themselves part of the HTML5 spec.
Would it not be less confusing if folks stuck to the fact that no, it’s an HTML5-enabled browser that supports WebM and its ilk and HTML5 is only a markup language? Or, as I suspect, am I only getting half the picture? (See it is confusing aye!?)
I feel as though I’m halfway there, but I also feel as though there is more to the HTML5 changeover than there was to the HTML4.01 -> XHTML1 changeover - if you know what I mean?
If anyone can enlighten me on any one of these points, I’d be much obliged
The entire problem with incompatibilities of Internet Explorer was caused by Microsoft implementing a draft version of CSS 2 into IIE5 and too many people writing real web pages using it rather than just experimenting with it to see how it worked. The final standard was different which led to all the problems.
Now browsers are implementing early draft versions of HTML 5 for people to experiment with. If too many real web sites get built using these early drafts then the same problems will be repeated when the final standard turns out to be completely different.
Also with approx 95%+ of the web having not finished upgrading from HTML 3.2 to HTML 4 yet there isn’t really a huge rush to get HTML 5 finished.
A lot of what is currently proposed in HTML 5 is only needed as workarounds for IE6 and so those parts of HTML 5 will be completely redundant once IE6 is dead.
It is an underestimate based on a large number of web pages that I have looked at. Very few of the pages I see use an HTML 4 strict doctype or XHTML 1.0 strict doctype and not all of those actually validate as such.
An HTML 4 transitional doctype of course indicates that the page is still using HTML 3.2 and that the owner is supposedly still in the process of transitioning from HTML 3.2 to HTML 4 as the transitional doctype accepts HTML 3.2 tags as valid as well as the HTML 4 ones.
As only web pages that have an HTML 4 strict doctype and actually validate to that doctype are actually using HTML 4 the actual number of sites where HTML 4 is used is probably a lot lower but I haven’t examined a big enough sample to be able to say that the 0.5% of sites I have seen that use HTML 4 are not actually representative of a much higher percentage of overall sites that use HTML 4 although I doubt that the real figure is likely to be much higher than 2 or 3% at most.
In previous iterations of the HTML specs the focus for me felt much more on the markup side. This time around, though, the working draft also provides much more with regards to interaction and API access. This is necessary since the spec is much more targeted at web applications instead of document representation.
So: yes, the changeover from x to HTML5 is quite big but no one forces you to use everything The whole load is just interesting if you’re really working on web applications instead of document-centric sites, IMO.
