HTML 5
2007-08-09
Lyle's brief remark on this article on the plans for a successor to HTML 4 has me thinking. The comment I was leaving was getting very long, hence a trackback.
Although the language looks like it could be good, various things about it (and especially about the article) worry me a little. Reviving HTML4 rather than forking XHTML could make the languages entirely incompatible, especially if designers take the article author's view that 'features' like unclosed tags are benefits. It's good that the W3C got 'many of the same members' for its own WG and good that 'the two efforts will likely be merged' (I'd love a better source for that, of course) but even so, the language plans to exclude the benefits that XHTML brings and is unlikely to be at all compatible with it.
How is it useful that a frozen web designer from 1999 can recognise it? If he's worth reviving then he can switch to XHTML in a couple of hours, and from there he can look into getting anything else he needs from the extensibility. Perhaps he isn't that good, but there's a reason most web designers aren't trying to get back to 1999.
XHTML+CSS is very powerful. Even without leaving the regular XHTML namespace you can divide your document into whatever sections you need and attach particular formats to different kinds of items. Most of the features listed in the article are effectively shortcuts to that kind of behaviour, but adding them to the mark-up is a slippery slope.
Sure, section is more convenient than div id="section_01", but do I really need a new tag for it? dialogue is a neat idea, but is it really going to be more powerful than dl class="dialogue"? Even if the browser representations of the dialogue are consistent, sooner or later I'm going to want to override them. Are they going to add the xyz tag: I need that at least as much as I use figure.
Sure, it'll be easier to learn. It'll encourage people to divide their pages into obvious header, footer, nav and so on, but people who don't care about such things still won't use them. No doubt they will make good use of the backward support for sloppy tagging, which will hurt them if they ever need any other structural language. It'll be easy to lay out whichever things the language designers decide to help you with, but take care not to need anything else.
I really hope my gripe is with the article, rather than the language. I'm sure lots of interesting things will come out of it when the specification is released: a properly supported datagrid would be great, for example. HTML 5 will probably find a lot of supporters, but I have a sneaking suspicion that I won't be among them: if it isn't suitably interchangeable with XHTML I'll probably be hidden away somewhere for a while playing with XSLT or something to steal the bits I like.
Although the language looks like it could be good, various things about it (and especially about the article) worry me a little. Reviving HTML4 rather than forking XHTML could make the languages entirely incompatible, especially if designers take the article author's view that 'features' like unclosed tags are benefits. It's good that the W3C got 'many of the same members' for its own WG and good that 'the two efforts will likely be merged' (I'd love a better source for that, of course) but even so, the language plans to exclude the benefits that XHTML brings and is unlikely to be at all compatible with it.
How is it useful that a frozen web designer from 1999 can recognise it? If he's worth reviving then he can switch to XHTML in a couple of hours, and from there he can look into getting anything else he needs from the extensibility. Perhaps he isn't that good, but there's a reason most web designers aren't trying to get back to 1999.
XHTML+CSS is very powerful. Even without leaving the regular XHTML namespace you can divide your document into whatever sections you need and attach particular formats to different kinds of items. Most of the features listed in the article are effectively shortcuts to that kind of behaviour, but adding them to the mark-up is a slippery slope.
Sure, section is more convenient than div id="section_01", but do I really need a new tag for it? dialogue is a neat idea, but is it really going to be more powerful than dl class="dialogue"? Even if the browser representations of the dialogue are consistent, sooner or later I'm going to want to override them. Are they going to add the xyz tag: I need that at least as much as I use figure.
Sure, it'll be easier to learn. It'll encourage people to divide their pages into obvious header, footer, nav and so on, but people who don't care about such things still won't use them. No doubt they will make good use of the backward support for sloppy tagging, which will hurt them if they ever need any other structural language. It'll be easy to lay out whichever things the language designers decide to help you with, but take care not to need anything else.
I really hope my gripe is with the article, rather than the language. I'm sure lots of interesting things will come out of it when the specification is released: a properly supported datagrid would be great, for example. HTML 5 will probably find a lot of supporters, but I have a sneaking suspicion that I won't be among them: if it isn't suitably interchangeable with XHTML I'll probably be hidden away somewhere for a while playing with XSLT or something to steal the bits I like.
Comments