Another look at HTML 5

It has become evident to me that some of my previous comments about HTML 5 and what is going on in the HTML Working Group are the result of misunderstanding and overreacting on my part. I no longer think things are quite as bad. I still believe there are some problems that need to be solved though, so I’m going to try once more to explain my feelings and suggest a few things that I think would improve the situation going forward.

My personal reason for writing web related articles and tutorials is that I am really passionate about doing what I can to make the Web a better place that everybody can use. That thinking can be applied to many aspects of web design and development, but since this is about HTML 5 I’ll be focusing on creating markup in this article.

I want to improve the Web

I really want the Web to work better, for more people, than it does today. In order to make the Web a better, more accessible, user-friendly, and interoperable place, I believe that developers, designers, CMS vendors, and authoring tool vendors all need to be educated. We all need to adopt best practices in our work, and encourage others to do so as well. Writing tutorials is one way of doing that, but I don’t think it is enough.

Tutorials, blog posts, and books only reach those who find and read them. Unfortunately that means most people who work with the Web read little, if any, material that helps them improve their knowledge of HTML. I think that is quite obvious when you look at the current state of the Web.

So, while tutorials and guides do help, they only help those who want to be helped and know that they need help. They do not help people who want to do things right but are unaware that they are using HTML incorrectly. If they or their clients knew they were doing things wrong, many of those people would learn how to do things right. At least that’s what I, perhaps naively, want to believe.

Backwards compatibility and error handling

And that leads me to HTML 5, backwards compatibility, and standardised error handling. Backwards compatibility in browsers I don’t really have a problem with. I realise that it is necessary, though I don’t quite understand why browsers can’t treat new content (content that somehow claims to be HTML 5) in a different way than they treat current content. I am told that it is too expensive for browser vendors to do so, which sounds odd to me. But I am not a software engineer, so what do I know. They are probably right about that.

Error handling then. Yes, error handling is definitely necessary. People will always make mistakes, and standardised error handling is great for interoperability. But here is where my opinion differs from that of most browser vendors (and many others). I really am naive enough to think that browsers somehow making the user aware of errors in the markup will eventually lead to an improvement (and no, I do not believe that the W3C can force browser vendors to display error messages). Let me try to explain why.

  • Users will have one more way of judging the quality of the site they are visiting. They can already judge a site’s apparent quality by graphic design, content, and ease of use. I think they should also be able to easily judge the technical quality of a site. “But users don’t care about the code!”, you say. No, of course they don’t. That isn’t the point. The point is making them aware that they are using a site that is well crafted (or not, in most cases), and to make them start questioning why some sites have errors and others don’t.
  • All developers, not just the educated ones, will be able to get immediate feedback when they are using non-conforming (HTML 5-speak for invalid) markup. I believe that a decent number of developers will want to fix that, which probably requires them learning what they are doing wrong and how to do it correctly. A counter-argument to this is that developers should install browser extensions that provide this functionality. But most don’t do that, and never will.

I am not saying that browsers should stop rendering when they encounter an error. Nor should they display a modal alert or open a window that displays the erroneous markup. An inconspicuous icon of some kind, perhaps in the browser status bar, would be enough. Two different examples of how that can be done are provided by the HTML Validator extension for Firefox and the iCab browser. My point is that it doesn’t have to be obtrusive. It shouldn’t be. If the user or developer wants more info, they can click the icon.

Some say that any browser vendor that implements something like that would lose market share. I simply cannot understand why they would, but if someone can prove that is what would happen, please do.

Leave most cowpaths unpaved

There are a number of proposed design principles for the HTML Working Group. Most of them make perfect sense, but I think a potentially dangerous principle is “Pave the cowpaths”, which says:

When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new.

Depending on how you interpret that, it can lead to insanity such as the following:

  • Most authors use nested tables and spacer GIFs to control layout, so let’s make that the preferred layout method.
  • Using the same id value more than once on the same page is very common, so it should be allowed.
  • Nesting block level elements like h1 and p inside inline elements such as a and span is popular, so let’s allow that.

Luckily neither of those cowpaths have been paved in the HTML 5 specification, and as far as I understand it they won’t will be. However the explanation of this design principle needs work to avoid misunderstanding.

For the record, I do believe that if upon investigation a widespread practice is found to make more sense than what is currently in the spec, it should probably be adopted.

The HTML 5 Specification

Some of my previous worries and complaints are no doubt caused by me misreading the HTML 5 specification. My only excuse is that I find it very, very difficult to read since information that is only intended for browser developers is mixed with information that is important to authors (designers, developers, writers, CMS developers, etc.).

Having spent hours reading and re-reading the HTML 5 Working Draft, I now see that, except for it being hard to read for a web author, it really is a good start. I don’t necessarily agree with everything. There are some elements and attributes that I don’t quite see the point of, as well as some that I find missing. But overall I think the gist of the spec is fine. Basically, the information in it just needs to be presented in a better way.

Here are some suggestions that I think would make the HTML 5 specification easier to read and more useful to authors:

  • Do not mix user agent requirements and parsing instructions with author requirements. For authors to find the spec useful the parts that are relevant to them have to be cleanly separated, preferably into a separate document, even if it means more work for the editors. I know there are people who will be happy to help if it really proves to be too much for the two HTML WG editors to handle.
  • Include use cases and best practice examples for every element and attribute.
  • For elements and attributes whose misuse is widespread, provide examples and explain why authors must not use them that way.
  • Link less. Some sections are so cluttered with links that they are almost unreadable.
  • Provide lists of elements and attributes the way the HTML 4 spec does (elements, attributes).

The attitude problem

Specifications and design principles aside, I think a more disturbing issue is the really poor attitude some members of the HTML Working Group have. I’m not going to quote anyone or name any names, but it is something I felt from the moment I joined the working group mailing list.

Sometimes it is just between the lines, sometimes it is clearly expressed in writing. But the dismissive and condescending attitude towards accessibility and semantics advocates is quite tangible, and is what made me frustrated enough to write Help keep accessibility and semantics in HTML before making sure I had all the facts sorted out.

In my opinion this is the main problem with the HTML WG right now.

Looking forward

More than once I’ve been close to leaving the group out of frustration, but reconsidered. I still don’t know if it will be worth my time to stick around. I don’t even know yet if I will stick around, or for how long.

I’ll definitely stay for a few weeks to see what happens now that the WHAT WG’s HTML 5 Working Draft has been accepted as the document that the W3C HTML Working Group will use as a starting point, with Ian Hickson and David Hyatt as editors.

After that, I don’t know.

Posted on May 14, 2007 in (X)HTML, HTML 5, Web Standards

Comments

  1. May 14, 2007 by Arnaud

    Re error handling: Internet Explorer has been handling javascript errors by displaying an icon in the status bar for years. It annoys the hell out of me when I see that webmasters can leave such errors. So you’re right: yes, it is a good way to show errors, and no it doesn’t prevent browsers to lose market shares.

  2. May 14, 2007 by David

    I know people personally that ignore IE’s status bar icons because they feel the site works well enough as it is. I want to strangle them! I do not think adding an icon will help that much because it does not change the mindset that if the browser displays crap soup correctly they are not willing to fix something, that to them, is not broken. Does that make sense?

    Also - Why are we not pushing for better “editors” that are more helpful in understand what the designer MEANS to do. I realize there are a few people designing WYSIWYM editors as we speak. Those that rely on an editor to help them design a page are for the most part the culprits of invalid code.

  3. I agree totally with Arnaud here. It could be said it is one of the things that MS actually got right!

    I do love the FireFox extension, even more so because it does exactly as you say Roger.

    Many browsers have error reporting functionality built into them one way or another, so why not just unify the interface for them? Menus and icons are placed similarly in different applications in order to make them easier to use, so why not do the same for error reporting in browsers?

  4. Great, good to hear that it’s not nearly as bad as you though! I appreciate the time you’ve taken being involved in this process, your blog posts so far and others to come will be very useful for giving people an insight into the development of HTML5 as it moves ahead.

    Cheers!

  5. May 14, 2007 by Justin

    CSS has defined parsing rules, and when rules or declarations are dropped due to syntax problems, they’ll show up in the Firefox “Error Console.” It would certainly make sense if this were extended to accommodate similar-in-spirit HTML parser messages.

  6. Good article. I completely agree with you on the fact that blogs and tutorials only help improve the web in a limited way. I think there’s a great demand for resources that will help beginning web developers. Resources that highlight the importance of semantic markup. Prevention is better than cure, right?

    When it comes to the specification, I think the WHATWG does focus too much on backwards compatibility. I’m definitely not against it, but I think it has influenced their decisions in a way it is detrimental to the quality of the language.

  7. I have been similarly concerned (which was the main reason for me to join the WHATWG with your encouragement). One fine morning I realised, that the patient demonstration of benefits won’t get us to the bright world of valid, semantic HTML. People see their spacer.gif-based “layouts” bring cash since mid-1990s. Why bother? It works - don’t touch it.

    I am sure, that clean, reasonable, correct HTML can be ensured only by force (think human law enforcement). Either HTML parsers refuse to render invalid code, or let’s conform and pave even the most absurd cowpaths. Alternatively, we can kidnap babies before they learn to speak, and condition them in the underground web designer camps.

  8. More than once I’ve been close to leaving the group out of frustration, but reconsidered

    I got frustrated at many points, as well. But then I realized there are hundreds of “invited experts” that aren’t experts at all. They argue for bad changes and stupid ideas. There are also browser vendors with less of a commitment to certain principles than we wish. However, there are important people that have been around since before HTML 3.2 that ARE dedicated and are more respected than the “invited experts” and browser vendors. Their voices speak loudly. Those people won’t let us down.

    HTML 4 and XHTML are both very nice specifications and, if used well, are capable of being accessible, well written, etc. Many of the same people that made those specs a success are working on HTML 5. So, to some degree, we need to put some faith in that. I’ve not been playing an active role in the list lately, but I know that, even without the extra voice of advocacy for accessibility and “best practices”, we’re going to end up with a good specification. If we don’t, HTML 5 will end up like XHTML 2: no one will use it. We’ll still have HTML 4 and XHTML like we always have (assuming Don’t Break The Web is still a design goal).

  9. May 14, 2007 by Tom L

    I have been waiting for this follow-up from the previous post anxiously. Someone finally spoke out against the practices of what I consider an intelligent but elitist group at the W3C.

    I cringe at the site of most use of HTML I see on a day to day basis. Though, I do make quite a good living sweeping up the messes of the uneducated and naive developer.

    I too have a passion for using HTML, CSS, ect… in an orderly, easily readable and semantic way.

    There can be no legitimate excuse for designers and developers to say that they haven’t been introduced to semantics and best practices when there is SOO much out there.

    Go to Amazon and type in the subject you are interested in( eg. Javascript, CSS) and then sort by popularity. Read reviews on blogs. These are just a few ways to find a reliable source of information.

    If you do find the information and aren’t interested in reading it then you are in the wrong field. If you have ESPN as your start page and not even a hint of a web developers blog as a bookmark then start your new career as a low-budget local high-school sports team web master.

  10. Roger, not only is it great to see that you can come back and set us straqight where perhaps you were wrong but also that you strive for best practice and are prepared to stick your neck out for the cause. I totally agree with your commetns and personally think the group needs a more forward thinking attitude rather than the somewhat retrograde one which you describe. I implore you to stick with the group. If not you, then who? With no one there to fight the good fight, we’re all doomed. We’re behind you mate.

  11. dismissive and condescending attitude towards accessibility and semantics advocates is quite tangible

    That’s perhaps the most disturbing thing about the whole situation. For a the working group to be dismissive towards semantics and accessibility is unforgivable. It’s like saying “we don’t really want to work on HTML”.

    I think the whole industry is rife with this attitude at the moment. I know I’m sick of getting comments which translate to “stop raining on the AJAX parade with your accessibility crap!”

  12. I have not seen any dismissive attitude towards semantics or accessibility when the semantics serve markup consumer use cases or when the accessibility features are associated with practical use cases and those use cases are not better served by other means.

    I guess my previous paragraph is seen as a manifestation of the alleged bad attitude, but we really shouldn’t be including features based on ‘nice to have’ theorizing or based on axioms like the more semantics the better.

    Some of the people who seem to have the worst attitudes are keen to improve accessibility but not by separate afterthought annotations but by defining processing models that satisficing results could be achieved as an automatic size effect of visual-oriented structured authoring without a separate accessibility annotation step.

  13. The idea of including a status bar icon that indicates whether a page is “conforming” or not hits the nail right on the head. Users DO judge the quality of a site by many metrics and I think that method of error handling is fantastic way to help nudge designers and developers who don’t know any better in the right direction. Not only is it a simple, non-intrusive form of feedback for the user, but it seems like the type of thing that wouldn’t be overly difficult or expensive for browser vendors to implement. I hope the idea is being given some real consideration by the working group.

  14. May 15, 2007 by icaaq

    Provide lists of elements and attributes the way the HTML 4 spec does (elements, attributes).

    Maybe not fully updated but most of the elements should be there, and it’s not presented like the html 4 spec. but it’s always a start :)

    http://simon.html5.org/html5-elements

  15. The first step to behavior modification is awareness. Placing a markup validity icon on the browser generates awareness in the site’s creator, the site’s client, and the site’s visitors. A markup validity icon on the browser has no harmful effects and can only help the web. I support this suggestion one hundred percent.

  16. Here are three public-html messages regarding markup validation within user agents. In this case the focus happens to be on IE but any UA is fair game.

    Alas, one potential gotcha could end up being inconsistent validation across UAs (Validator Wars, a.k.a. “Oh no, not again!”).

  17. May 15, 2007 by Scott Wehrenberg

    While I definitely hope that the WG can help expand standards, and interoperability, I see pushing semantic markup onto HTML as pretty much lost cause. How much semantics can we really hope to derive from a footer, nav or section element? It might help google ignore a few portions of a page better, but I don’t see any of the changes revealing vast amounts of meaning in a document.

    What I really wish would happen is that we would move to XML. Rather than going through a WG who dictates what each element should mean, anyone can simply create an XML schema, and your document can simply tell the world that you’re using that schema.

    I think HTML WG should stick to helping define element for functionality that the browsers should incorporate. Video and audio elements, new form controls, those make sense to me. Debating how to use elements that don’t really add much semantic value to a page doesn’t.

  18. Arnaud says

    It annoys the hell out of me when I see that webmasters can leave such errors.

    Do you get a JS error on google’s homepage? I do. Will it “annoy the hell out of me”? No, but it will make me wonder what kind of malicious ACTIVEX control they are trying to use that caused the error (as I assume the error is caused by me turning ActiveX off whereas most people don’t and therefore don’t get the error).

    Firefox doesn’t display JS errors though, does it? Now that does annoy the hell out of me.

  19. I’ve had people call me saying they had a error on their computer, which turned out to be a js-error in IE. These error messages aren’t for the average user.

    Maybe you should only show error alerts when files are local (file:/// or localhost/127.0.0.1), which is kind of an indication that you’re dealing with a webdeveloper.

  20. May 16, 2007 by Facundo

    Maybe someone can explain this to me. A programmer won’t release a software if the compiler or interpreter trhows errors, a writer won’t release an article if the spellcheck says there are errors, a designer won’t send a work out to print if it has some kind of error, so why webdevelopers can say a webpage is done if it has errors, and why those errors are suppose to be hidden from the user by the browser? why do the browsers have to forgive developer’s errors? Honestly, I’d like to know why are webdevelopers (I’m one too) allowed to work this way? Wouldn’t be easier for everyone if an error was an error and not some obscure glitch caused by the browser attempt to recover a bad coded page?

  21. May 16, 2007 by Roger Johansson (Author comment)

    gerben:

    Maybe you should only show error alerts when files are local (file:/// or localhost/127.0.0.1), which is kind of an indication that you’re dealing with a webdeveloper.

    I don’t know about everybody else, but I very rarely develop that way. I almost always use a dev site on a real (well, IIS, so not really real) web server.

    Facundo:

    why do the browsers have to forgive developer’s errors? Honestly, I’d like to know why are webdevelopers (I’m one too) allowed to work this way

    Because in the beginning, people couldn’t be bothered to learn HTML, so browsers had to try to parse their half-arsed mess anyway. And over time, thousands upon thousands of sloppy developers became dependent on browsers to cover up for their ignorance, and now we can’t take it away or they, their clients, and their sites’ visitors will go sulk in a corner.

  22. A big problem I see with the html wg is that they don’t think about the future enough. From what I’ve observed, the spec is being created to solve current problems in html. What if the way websites look and function is completely different in 5 years? Will the spec be able to accommodate?

  23. I rather like the way Opera 9 deals with XHTML pages - those presented as XML. If a page is non-conforming, a friendly message appears explaining why the requested page is not showing, and you are invited to use a link to display it as HTML instead.

  24. It’s unfortunate that the W3C’s constitution means that participants in the group are given the title of “Invited Expert”, rather than something like “Voluntary Participant” (as much as I like being officially an Expert ;-) One can’t help but wonder how many people have joined merely to have a fancy title with which to impress clueless clients or employers.

    Robert’s comment about the lack of expertise shown by some members of the group is spot on. I strongly suspect, in fact, that at least some of these are the very people who have been churning out tag soup since the 1990s; they have managed to make themselves believe that getting away with rank incompetence for eight or more years entitles them to expert status.

    Hopefully the excitement will wear off soon and this dead wood will fall by the wayside (apologies for the mixed metaphors). Ultimately this will be a long-term effort, and those lacking any real understanding or, dare I say, idealism will lose interest and drift off after the next trendy meme that seems to offer the possibility of achieving a spurious status without the need for knowledge or effort.

  25. by defining processing models that satisficing results could be achieved as an automatic size effect of visual-oriented structured authoring without a separate accessibility annotation step…

    Eh?! S’il vous plaît, I hope you’re not in charge of editing any specs.

    Link less. Some sections are so cluttered with links that they are almost unreadable.

    Totally agree there, Roger. I can say that about a lot of documents. Keep it linear and make use of reference lists as needed. All that hypertext, cross-reference, snipe hunting is for the snipes, not for people who want to learn in a straightforward manner.

  26. Hi,

    sorry but my english is not so goo. What does it mean: HTML instead ?

    I hope that anyone can help me?

    thank you

  27. …by defining processing models that satisficing results could be achieved as an automatic size effect of visual-oriented structured authoring without a separate accessibility annotation step…

    That should have read side effect.

    Eh?! S’il vous plaît, I hope you’re not in charge of editing any specs.

    The goal is to make the Web more accessible. If the Web can be made more accessible while requiring less effort from Web authors, surely that’s a good thing.

    If processing models are defined in such a way that in the common case accessibility follows automatically from the semantics of elements, surely we get better accessibility overall than in a case where the author has to annotate everything a second time with role=”” or whatever even for the common cases, because most authors won’t take the time to make a separate annotation pass.

  28. Well it’s nice to read your thoughts again Roger. I’m going not to agree to only one thought - about mixing browser specific directives with web developer information. Actualy I think it’s a good practice to see how the browser will handle all thease things. Especialy when it comes to errors - If I make some error in my markup at least I’ll be informed how the browser (should) handle such mistake. Atleast I hope all browsers will support HTML 5 someday (hopefully soon). And also I’m looking forward to see XML version of HTML 5 - I’m kinda obsessed whit all this XML technology :)

  29. May 25, 2007 by Roger Johansson (Author comment)

    Henri:

    If the Web can be made more accessible while requiring less effort from Web authors, surely that’s a good thing.

    Yes. But in some cases making the Web accessible will mean requiring some effort and some knowledge from Web authors. Should those features be removed just because the uneducated people posing as Web professionals won’t use them? No thanks, there is enough pandering to bad practices as it is.

    gusc:

    Actualy I think it’s a good practice to see how the browser will handle all thease things. Especialy when it comes to errors - If I make some error in my markup at least I’ll be informed how the browser (should) handle such mistake.

    I see your point, but that is exactly the scenario I do not want - authors relying on standardised error handling instead of on writing their markup according to the specification.

  30. authors relying on standardised error handling instead of on writing their markup according to the specification

    Well if you think that authors WILL make mistakes and rely on error handling then I agree - not a good thing, but good thing is always to know how browser handles all those things (not only errors) - for now in HTML 4.1 (and XHTML 1.0) - we must test this out on every browser to see the real result. Anyway it realy could be a good idea to show a little icon of HTML/CSS/JS error in statusbar - only thing that is missing, are authors who are willing to learn from thease errors.

  31. @Arnaud I think I remember the status bar not being shown by default in IE.

    I don’t think the browsers NEED to have html error reporting built in. It would be nice tho. We just need to get the message out there about the tools that find errors. Everyone knows they MUST have Flash installed. I don’t see why we can’t make it common knowledge that web developers MUST have firebug installed (if they know what’s good for them).

    I remember when I was in highschool making 3 or 4 page sites with dancing babies everywhere…I didn’t know, I didn’t care, “internet is the blue E”..etc. I had no right back then to call myself a web professional/expert.

    I don’t care how elitist this sounds. We need to band together and form some sort of organization of actual professional web designers.

    I also think it’s time we let go of that old “HTML is for Everybody” idea. Lets look at present day facts. Going forward the vast vast majority of new content will be created by average joes using some sort of CMS (blogger, myspace, etc). The tiny fraction of tags they’ll be allowed to use should have not big impact on future HTML specs.

    The rest of us will be the people making these systems. Anyone new to html should be prepared to learn it or just go use a CMS.

  32. Your articles are always interesting and to the point as well Mr. Johanson. This one is great as well. I only wished more people in our profession were taking action and educate theirselves more. Cheers, Stergios from Greece.

  33. Developers are always concerned about learning new buzzwords. Most of them see HTML as nothing more than paragraphs, divs, headings, tables, hyper links and forms. People don’t want to spend time learning HTML and standards compliant markup. This is mainly because they are not aware that there is more to HTML than just simple things they do on a regular basis.

    I really gone through these stages, when I was working for a corporate company as a developer for an internal project, I used to open body tag twice, thrice in a page. It all happened because we were never taught HTML in our training. Then I slowly started digging over net and suddenly came to know there is something called web standards. Started reading through blogs written by experts like you and got passionated towards web standards. Now I am totally obsessed with web standards and I strive to enhance my knowledge.

    Showing the errors for bad markup will be a good idea to educate non tech users of the web. In my view, a better way would be to put a button which will take the user to a validation service informing the user about the quality of the markup/technologies. Instead of showing the validation errors on the status bar, taking him to a page where he can see a detailed analysis, mostly in non technical terms will be a good thing to do. I don’t think that by doing this the browser will lose its market share. It will be an added advantage for the normal user to see the site’s technical expertise.

    finally I love your blog Roger. Apart from leaning, it has also helped me a lot to find few other interesting blogs even. Thanks for your articles and book reviews.

    Wish you good luck for your stay at HTML WG.

  34. July 4, 2007 by alex.r.

    A programmer won’t release a software if the compiler or interpreter trhows errors, a writer won’t release an article if the spellcheck says there are errors, a designer won’t send a work out to print if it has some kind of error, so why webdevelopers can say a webpage is done if it has errors, and why those errors are suppose to be hidden from the user by the browser?

    Err… humm… because web authors aren’t necessarily developers? And because that is a good thing? The thing that made the web what it is today.

    Those asking for a user interface to give the validation status of a page… For people authoring web pages, sure, why not? But for the general public? No way.

    For them it adds absolutely zero information (there’s an error in this HTML? What’s the impact? Nothing? What can I do about it? Nothing? Why should I care? What’s HTML anyway?) It only adds to the cognitive load of the UI without providing any benefit for them.

    Also, an error in one version of the spec. may be a perfectly valid piece of code in the next version. Relying on error handling to introduce a new feature that degrades gracefully is very common when this error handling is completely specified. In that case, viewing the page with a slightly outdated browser will give false information.

  35. Brilliant article and very informative. I look forward to some of the changes and they may remove previous problems but as many people believe they will no doubt leave room for a new misuse or error.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.