The article below was posted on @netmag yesterday.
http://m.netmagazine.com/features/truth-about-structuring-html5-page
I admit that I have no issues with html5 except the newly introduced structure elements.
What are your thoughts on the points and arguments raised in the article?
This author makes some very interesting and quite valid points. Albeit, in a rather ‘brash’ style.
I especially like this observation
But these new structural tags have created a strange, quasi-religious experience where you have to consult the high priests (the HTML5 gurus) for their interpretation of vague religious texts (the HTML5 spec) just to mark up a darn web page.
and this comment
…you have my permission to pop a cap in their ass with a Nerf gun.
It seems, amid the flurry of “keeping up with change”, it is easy to lose sight of the simpler facts; the real intent and purpose of ANY markup. I have read many zealous debates about some of the most [to me] insignificant features of HTML over its entire lifetime.
Overall, the article is well written. He obviously has experience as a debater.
I think the gist of the article is that HTML5 IS NOT just simply HTML4 with DIVs swapped out for new structural equivalents. We really should have picked up on that a long time ago. There was a time, before my time, when people switching from using tables for layout simply replaced TABLEs, TRs, and TDs with DIVs. It seems we might be going through the same growing pains for this new transition.
Yeah, I agree that there is too much confusion around the structure of HTML5 to make it useful. I’m sure a lot of thought went into this, and probably with good intentions, but it still doesn’t convince me. The idea seems to be to improve semantics, but because nothing changes visually on the page anyway, it seems like a lot of fuss for little advantage. And a few new elements like <nav> and <footer> aren’t going to make up for the whole long list of meaningful ways you might want to present content. I would much have preferred to keep the current HTML structure and go more down the route of ARIA attributes. That’s seems a much more intelligent and flexible way to add meaning to markup, and offers so many more possibilities. Those attributes, in large part, could have taken the place of classes and IDs as styling hooks, too. O well …
I also agree with his points about styling HTML5. This is an issue that seems to have been buried in all the hype so far, but it’s a huge issue, IMHO.
Other elements like <audio> and <video> could be of some use, but whether they are really needed is debateable. It would have been possible, perhaps, to use the existing <object> element perhaps with an attribute to distinguish between audio, video, canvas etc? I dunno, but specifying names on elements seems restrictive to me.
The best feature I so far have used from HTML5 is the advanced video embedding function. So it allows to have video in webpage without ang Flash. But you have to deal with many formats of teh same video that you should upload so that each browser displays its proper format.
I enjoyed the article and agree with a lot of things stated although the author obviously went for effect.
I don’t see how we can be expected to use new html5 elements properly when even the html authors have previously created demonstrations that show their usage incorrectly. If it’s that hard to understand then there’s no chance of it being implemented properly in millions of sites. It needed to be more intuitive and obvious from the start. I think eventually it will all come together but will be a few years yet before I start using it - if I ever do (although some clients are now asking me for html5 sites without a clue why or what they are asking for).
I agree with everything that is being said. That is why I have yet to use HTML5 elements like footer, section, article, etc. Well besides the fact that the spec isn’t even standard. I have no problem using more useful things like video but those “extra” little semantic tags not really for me nor do I think they are in the best interest of those for whom I work for.
I take a middle ground on this. I can see why some tags are useful. Specifically : header, footer and nav. I can see how these can benefit search engines, accessibility (for instance being able to tab directly thorough links in <nav> rather than every link on the page, or the opposite such as ignoring <nav> and tabbing through other links).
His main point is valid though: The tags simply aren’t specific enough in their purpose which leads to confusion. It’s very difficult in a non-trivial document to decide whether a div/section/article should be used.
I am not going to register to comment on that article but I had a quick scan and picked up on some other interesting points raised, which most people should already know.
Obviously the article was written to be slightly controversial and draw attention to the book and was partly a marketing gimmick by the author. It’s clear the book isn’t meant to be a tutorial but give a fairly honest if not slightly “opinionated critique on HTML5”. Though it makes a change for the overinflated “fan boy marketing hype” and idiotic false rumours that circulate the web so it was a refreshing change that it dismissed some myths.
That obviously is a fair statement in that HTML 4.01 is normative and functions quite well currently and is broadly supported by all current mainstream browsers and even most legacy browsers.
Obviously introducing new elements and attributes will undoubtedly cause problems and barriers though clearly improvement on forms were required and the web is always morphing.
A little taste of pain
Here are just some of the problems these new structural elements introduce:
Point three is the most interesting though point two obviously is correct in that it does introduce a complicated and unnecessary method of structuring documents. Most authors I have seen try to use it get ‘confuddled’ and do come unstuck. Going back to point three (currently) that is one that everyone should be aware of that most people try to brush under the carpet. Partly a case of legacy browsers though but an actual “real world” issue.
Quiz question: How were these elements added to the HTML5 spec?
[…]
That is more-or-less correct they basically did research and then decided to create some elements from popular class names. Documenting tags that were floating around in the ether that were in common use whether or not they made much semantic sense. The non normative HTML5 basically just took ANY browser proprietary (none official) tag and decided which to implement, and which to not or redefined them. Leading to even more confusion… Plus the draft specification is obviously (descriptive rather than proscriptive) that doesn’t help the typical web author.
Clearly, introducing a whole new way of structuring documents, however poorly communicated, is not “paving the cowpaths”.
I couldn’t agree more. Although Of course I think their original intentions were good but rather rushed.
The only option then is to fall back on class names for headings, but avoiding class names when authoring is the very ‘problem’ the WHATWG were trying to solve.
I agree it sounds ridiculous and it shows some shortcomings. Also I’d suspect generally people would add classes to such elements anyway as they do nowadays so in effect it just adds bloat.
So we don’t need HTML5’s new elements for accessibility. In fact, we should avoid them for the harm they cause another subset of users.
At the moment that is quite true and the authors was correct WAI-ARIA is supported by AT and is NOT a HTML5 technology. Some of the HTML5 requires JS to function so that is also another shortfall/issue or warning sign. Though WAI-ARIA is good you also have to remember many people with disabilities like myself don’t use AT so you should always author semantic markup regardless.
I think overall the article edited [Chapter 3 of The Truth About HTML5] was fairly straight talking and cut out a lot of the rubbish and “propaganda on parade” market spiel you get plastered; everywhere as if HTML5 was a “magic-fix” going to save the world. Plus it’s not just a markup language unlike HTML 4.01.
So Maleika @kohoutek ; have you bought yourself a copy yet for light easy reading or weren’t it deep enough as obviously it was mainly a fun critique? I must admit, I did find it amusing in the article comments that some people were “shocked” with the article as if this was a completely new concept, i.e. that it’s a “ordered mess”.
Robert, I did buy the book but haven’t gotten to reading it yet, unfortunately. I think I’ll do so during the weekend. 
Maleika you’ll have to tell me all about it when you find the time it sounds like a fun book. Paul tell those clients HTML5 is dead and now! HTML5.1 is the new buzzword. Since they don’t know the difference anyway all they need know is both are non normative.
The new HTML5 elements such as <header> and <footer> were hoped to get actual meaning from UserAgents and other software. Today this still hasn’t happened. To a current browser, <header> pretty much == <div>. To an old browser, <header> == unknown element.
I think a lot of developers were hoping to “future-proof” their sites, for that wondrous time when these elements would mean something to software. Kinda like adding vcard stuff to your site in the hopes that a few years from now, the calendar program you use on your machine will get upgraded with the ability to read it …the difference being, vcard actually is used by some programs somewhere (nothing I’ve ever used, but likely Apple stuff of course). Who knows, might happen some day.
However, I suggest using some non-HTML5 features when marking up documents, such as ARIA attributes for blind and sight-impaired users and microdata schemas (when appropriate) for search engine results.
To be very true I didn’t get the article much the only thing that I am impressed with and gave me a reason to know more about it was the ARIA attributes. I would love to know and learn more about this, for sure. Thanks.
Opera’s page is pretty good, written by Gez Lemon: http://dev.opera.com/articles/view/introduction-to-wai-aria/
Marco Zehe’s blog has some good bits on specific ARIA use: http://www.marcozehe.de/tag/aria/
Jason Kiss’ site details ARIA/HTML5 tests he’s done: http://www.accessibleculture.org/tag/wai-aria/