Is HTML 5 a slippery slope?

If the response I have received since posting Help keep accessibility and semantics in HTML is anything to go by, I am far from the only one who is worried about the future of HTML.

Some disagree with my statements in that article and say that we have nothing to worry about. I am sincerely hoping that I am proved wrong and that the next version of HTML really is a step forward for all people who use or work with the Web. Time will tell, I guess.

That said, I have to agree with Tommy Olsson when he talks about HTML 5 possibly being a slippery slope in Forward Towards the Past.

I realise that standardised error handling in HTML is a good thing for browser vendors. But I doubt it will do anything to encourage web developers to produce better (as in cleaner, more accessible, easier to maintain) markup. In fact, it may have the opposite effect.

Again, time will tell, but I don’t feel too good about it.

Posted on May 10, 2007 in HTML 5, Quicklinks, Web Standards

Comments

  1. Tommy’s article is very interesting. There should surely be more of open debate in the web community about all of this discussion of HTML5. It did appear as though it was going to move things along quickly and deal with issues the W3C were slow to do themselves. However, it’s appearing as though it is running into problems just like WCAG2 spec.

    Like Tommy says in his article though this is based on little specific personal knowledge but mainly on the posts and comments by people like yourself Roger.

  2. May 10, 2007 by Justin

    How is standardized error handling any worse than standardized rendering?

    (By “standardized rendering,” I refer mostly to the CSS specification and how user-agents should display a given DOM with style information.)

    The fact of the matter is there are (and will always be) web “developers” who code towards a given visual result — no more, no less. Semantics, accessibility, and structure do not enter into their minds.

    One of the major benefits of standards-based rendering of HTML is that if the aforementioned web developer only codes for one browser, at least all other browsers will display it similarly. They’ll be coding against (if not using) the same standards as everyone else.

    Currently that’s simply not the reality of today’s web. People code pages to look right in IE, usually in quirks mode. But if all browsers followed the same standards-based rendering rules, Joe Developer’s incompetence wouldn’t ruin the visitor’s experience.

    So let’s extend that same logic to the actual parsing of the HTML, the building of the page’s DOM. Browser A and browser B might render the same DOM the same way, but what good is that if they generate different DOMs from the same source? One of the advantages of having standards for rendering falls apart.

    CSS syntax has standardized error handling. Malformed rules, missing semicolons, unknown properties all result in partial data loss — not full-fledged meltdowns. But people still validate their CSS. Perhaps not as religiously as their HTML, but it is only presentation.

    Standardized parsing is at least as important as standardized rendering. The latter is only made more useful by the former.

  3. Wow, Autistic Cuckoo is posting again! Thanks for the heads up Roger.

    I’ve been participating in the HTMLWG list for only one day, but I can certainly understand even in such a short time why you are concerned. The HTMLWG definately feels like it’s messy, and some of the discussions are frightening for what they are suggesting.

  4. May 10, 2007 by Matthew Smith

    I think the only real danger is that HTML reverts back to its origins as a document markup language, and web applications are built using more robust platforms like Flex and Silverlight. If this occurs, current versions of HTML are suitable. However, for HTML/CSS/JS to be relevant in the web application space, significant and regular updates focused in this area will be necessary.

  5. You’re mixing your problems. Error handling and semantics are separate issues.

  6. May 10, 2007 by Roger Johansson (Author comment)

    Justin:

    How is standardized error handling any worse than standardized rendering?

    It isn’t, in theory. In practice it may lead to even more sloppy developers getting things too right to bother learning how to really do things right.

    Jeff:

    Error handling and semantics are separate issues.

    Of course they are. Where did I say they are related? After re-reading my post I realise that it is a little unclear that I am referring to Tommy’s article. Maybe that is what made you think I am mixing them up?

  7. As I said in my article/rant, I don’t know much about the details of the WHATWG’s work. I just picked up some vibes from the comments on Roger’s article, that made me nervous. It appears to me that the WG’s goals for HTML5 are very different from what I’d like to see as a continued development of the most important standard on the web.

    Please don’t take it as gospel. I said I’m ignorant and that most of it was based on hearsay.

    Consider the article as my personal views on the dangers of redefining semantics of existing element types, rather than some sort of attack on HTML5 or the WG.

  8. May 11, 2007 by Roger Johansson (Author comment)

    Tommy: I basically only know what has been discussed on the HTML WG mailing list, so the same goes for me when it comes to the details of the HTML 5 spec. I’m still waiting for it to be released in a format that is useful not only for browser vendors.

    Technical issues aside, the way the needs of quality-minded web developers are ignored and the lack of respect for those of us who have not been part of the WHAT WG is enough to make me very worried.

  9. I still don’t see the point of HTML 5.

    Why not XHTML 1.2?

    As a programmer, parsing HTML is a royal pain. Parsing XHTML is much less of a pain because you can use a plethora of XML parsers. If there are errors, you get a well-defined set of parsing and semantic errors while walking through the document. In HTML, you interpret the errors and make best guesses as you go along.

    That’s tag soup, and it’s a step backwards.

    “More realistic” XHTML (forget this XHTML 2.0 / XForms nonsense) is more important than HTML 5, IMHO, if that makes any sense.

    The (X)HTML documents on the Web will always be semantically horrific. By backing enhancements to the stricter XHTML 1.x track, however, we make semantic markup easier while keeping the Web accessible to the average Joes.

    To me, HTML 5 is a retaliation against XHTML 2.0 and XForms and W3C’s general academic navel-gazing. Of course XHTML 2.0 and XForms are completely insane for the general Web. But we should still be supporting a stricter, consistently parse-able markup like an XHTML 1.2. I don’t see why HTML 5 needs to be so backwards compatible—HTML 4 will be with us until the end of time. Can’t we deal with dual legacy HTML and new XML parsers? By implementing new features in the XHTML tracks, we encourage structurally valid documents, which is a pretty big step.

  10. The thing I have learnt in my limited protected experience so far, is that everyone thinks he knows everything and is an expert in the realm of web design.

    This causes a situation that power of a position means you have more say than someone who knows ‘best practices’. I think one of the best solutions would be to make web design a ‘real job’ and give it real ‘status’ were to do it, you need qualifications etc.

    btw I do realise that last bit wont make people happy but thats ok :D

  11. I personally think there’s a lot of fluff around the WG at the moment. As far as I can see the only real decision (on the spec itself) which has been made is to adopt the WHATWG spec as a starting point - and I think this is a very good decision.

    I thought you’re last post was a bit dramatic to be honest Roger. No one’s arguing “against the value of semantics”, they just have a different perspective on some of those issues - and frankly they’ve opened my eyes to what those issues are. It’s simply not as clear-cut as some standardistas will have you believe.

    I ultimately think there are the right people in the WG to make it a success with WHATWG’s HTML 5 as a starting point.

  12. @Nick: XHTML is not really suitable for web pages. Yes, it is much easier to write an XML parser than an HTML parser. I’ve done both. But that is not the primary concern for the web. Any browser vendor can hire a few competent programmers who can write a good HTML parser for them.

    The problem is: the authors. Those millions of people who want to publish information on the web. The vast majority of them aren’t techie nerds and don’t want to learn to write code (even if it’s just markup). They will make mistakes, because they are human. Even us techie nerds make mistakes. (At least I do.)

    XML has draconian error handling, which is excellent in itself and one of the reasons why XML parsers can be faster and simpler than HTML parsers. But that’s not what you need for web content. A single unescaped ampersand in a link shouldn’t case a Yellow Screen of Death when someone tries to publish a page for their local ornithology club.

    Until we have easy-to-use authoring tools that will guarantee well-formed markup, the markup language must be as forgiving as possible.

  13. May 11, 2007 by Les

    this is but one issue in what will become a whole host of issues in regards to html5 is the feeling i have.

    i’m a big fan of web standards and what it stands for but ever since i got wind of this html5 i was sick all over the place; here we are trying our best to develop to web standards, get the message out there as to why it’s a good thing, an essential thing to the internet as a whole… and along comes something that isn’t a standard, that isn’t something from the w3c, to add confusion to the uneducated, and gives something to those who if they could, threaten the standards we cherish so much.

    nah… we don’t need html5, nor those that would represent it; we can (clearly) do without all that muck, thank you very much.

  14. I guess I will hope and pray… and wait. If HTML 5 brings back blink, for example, that will be a real kick in the teeth to those of us promoting semantic markup and standards. I don’t know much about it now, only what I’ve been reading (which is a bit disheartening so far), so I can only hope at this point.

  15. The apparent direction of late (into decent among the standards) is an iced waterslide.

    Having stable, reliably, useful web standards is such an important thing, and the current state of things isn’t looking promising, the W3C could do a lot more to stabalise the situation. They seem so out of touch with the present state of how HTML is used, or how developers want to use it, but I suppose that’s to be expected after having the HTML WG decomissioned for several years.

    I think it’ll be quite devestating if HTML 5 takes the web back to anything resembling it’s less refined beginnings.

  16. I’m not sure why you think the HTML5 specification is only for browser vendors. It is not. It clearly says so if you read the introduction.

  17. May 12, 2007 by Roger Johansson (Author comment)

    Anne: Yes, I am aware of that, sorry for being unclear. What I mean is the way the specification is written, which currently, in my opinion, makes it not very usable for web developers.

    I’ve just spent several hours reading the spec and feel that a lot could be done to make it easier to grasp. I actually find the HTML 4.01 spec easy to read in comparison. But I suppose (hope) that will be improved over time.

  18. I think it would be better if you make concrete suggestions where you would like things to be improved or clarified. Maybe also mention what you think the HTML4 specification does better, et cetera. Hoping it will get improved probably won’t make it so (unfortunately).

  19. May 13, 2007 by Roger Johansson (Author comment)

    Concrete suggestions have already been made on the public-html mailing list, but I’ll write something about it.

  20. Oh, ok. Pointers appreciated! I haven’t really been able to read every e-mail there :-)

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

    Hehe, no kidding ;-).

    Check the Rethinking HTML 5 thread started on May 1. It is mostly about separating author and UA requirements. I’m writing an article that contains a few more suggestions now.

  22. I realise that standardised error handling in HTML is a good thing for browser vendors.

    More importantly, it is a good thing for the users of browsers.

    But I doubt it will do anything to encourage web developers to produce better (as in cleaner, more accessible, easier to maintain) markup.

    HTML5 does not prevent authors from producing clean and easy to maintain markup. However, it is very hard to make people produce clean and easy to maintain code without them wanting to do it. Standardistas seem to be shocked that the WHATWG folks acknowledge that there is and will be unclean stuff out there.

    If standardistas want other authors to produce clean and easy to maintain code, the stardardistas should advertise the cost saving of having clean code instead of asking spec writers to pretend that everyone produces clean code. Pretending that the non-standardista way of working doesn’t exist isn’t useful to users of the Web.

    Quoting Chris Lilley on W3C’s changed stance on HTML: “99.99999% of the Web was invalid HTML. W3C pretended that didn’t exist. This isn’t a workable solution.” http://www.w3.org/2007/Talks/Banff-WWW2007-HTMLReloaded/index.html#(3)

    Like Tommy says in his article though this is based on little specific personal knowledge but mainly on the posts and comments by people like yourself Roger.

    I encourage interested parties to read the spec draft.

    I think the only real danger is that HTML reverts back to its origins as a document markup language, and web applications are built using more robust platforms like Flex and Silverlight.

    Indeed. If the HTML WG turns its back on pragmatism, single-vendor technologies benefit and the vendor-independent Web suffers.

    In practice it may lead to even more sloppy developers getting things too right to bother learning how to really do things right.

    Does that offend you emotionally now that you have made the effort to learn what’s “right” or is there a practical problem with more people getting things almost right?

    Consider the article as my personal views on the dangers of redefining semantics of existing element types, rather than some sort of attack on HTML5 or the WG.

    The thing is that the de jure definitions of semantics are less important for what markup consumers can do with markup than the ways markup is used in practice. If consumers want to consumer real Web content, that is.

    This works both ways: Hixie is relatively powerless to redefine semantics in ways that conflict with actual usage, so the danger of redefining semantics is mostly exaggerated. On the other hand, those who disagree with Hixie’s definitions are also relatively powerless to change actual usage even if they got their language in the spec.

    As a programmer, parsing HTML is a royal pain.

    This will be addressed by off-the-shelf HTML5 parsers, which you will be able to use roughly in the same way you’d use an XML parser on XHTML.

    Yes, it is much easier to write an XML parser than an HTML parser. I’ve done both.

    Did your XML parser support the DTD stuff? Did you benchmark them? Was either one notable faster? :-)

    I think it’ll be quite devestating if HTML 5 takes the web back to anything resembling it’s less refined beginnings.

    It is much less about taking Web back somewhere than facing the reality that the Web is already there. And pretending that it isn’t there really isn’t the way to move it forward.

  23. May 13, 2007 by Roger Johansson (Author comment)

    There is no need for the sarcasm, Henri. I doubt anyone pretends that the Web as it is today doesn’t exist. Or did you have any specific, concrete examples of that in mind?

    However, it is very hard to make people produce clean and easy to maintain code without them wanting to do it.

    Exactly. So we need to make them want to do that.

    Does that offend you emotionally now that you have made the effort to learn what’s “right” or is there a practical problem with more people getting things almost right?

    No. Does it offend you emotionally that some people aren’t content with giving up and leaving the Web a stinking mess?

  24. Did your XML parser support the DTD stuff? Did you benchmark them? Was either one notable faster? :-)

    No, the XML parser was for a specialised purpose and didn’t have to handle an internal subset. I’ve written a DTD parser, though, and it’s not that hard. Besides, a non-validating XML parser doesn’t have to do very much with an internal subset, does it? Just remember entity declarations.

    I didn’t do any benchmarking, but I doubt that there will be any measurable difference for reasonably sized files. The parsing speed aspect is greatly exaggerated, I think. I meant that an HTML parser is more complex to write than a non-validating XML parser.

  25. There is no need for the sarcasm, Henri. I doubt anyone pretends that the Web as it is today doesn’t exist.

    No sarcasm intended.

    Or did you have any specific, concrete examples of that in mind?

    Suggestions of Draconian error handling for HTML5, for one. Insisting that <em> and <i> aren’t practically synonymous as far as what markup consumers can infer from them, for another.

    Exactly. So we need to make them want to do that.

    But why?

    Do you want to help other Web developers work better for their sake? If so, I suggest advertising the long-term cost savings of your way of working instead of making your way look better in comparison by using the spec to undermine their way of working.

    Do you want them to produce better stuff for your sake so that when you inherit a project, it is maintainable? Well, tough luck. I sympathize, but I think using the spec as a tool here is the wrong way to go about it.

    Do you want them to produce better stuff for the sake of Web users? Well, we’ve seen that writing specs to say what we’d like the Web to be like isn’t going to fix it, so trying to make the best sense of what we’ve given out there is a more sensible approach to helping users.

    Does it offend you emotionally that some people aren’t content with giving up and leaving the Web a stinking mess?

    No. However, defining HTML pretending that it is much less of a mess than it is has already been tried and it didn’t make the Web comply. (It did make a small part of the Web comply, but a much bigger part didn’t and the bigger part matters a lot.)

    I don’t want to give up and leave the Web to single-vendor solutions, though. And single-vendor solutions will be more of a threat if multi-vendor solutions are dysfunctional.

    (P.S. your comment form does not round trip the entity for less than properly.)

  26. May 14, 2007 by Roger Johansson (Author comment)

    Ok, you win.

  27. May 14, 2007 by Roger Johansson (Author comment)

    You still win, but I thought about this some more while driving to work.

    No sarcasm intended.

    Good. Your tone could easily be interpreted as sarcastic.

    Suggestions of Draconian error handling for HTML5, for one.

    Ok. Agreed, that isn’t practical, and I am not suggesting that. But I really don’t think those suggesting that pretend people will never make mistakes, and I haven’t seen anyone suggest that draconian error handling should be used for pre-HTML 5 content.

    Insisting that < em > and < i > aren’t practically synonymous as far as what markup consumers can infer from them, for another.

    But are they really? I admit there is no huge difference due to widespread misuse, but there is a difference. I’m not going to enter that specific debate though.

    Do you want to help other Web developers work better for their sake?

    Yes. And for the sake of their coworkers, and for the sake of the entire Web industry.

    I suggest advertising the long-term cost savings of your way of working instead of making your way look better in comparison by using the spec to undermine their way of working.

    Yes, that is what I do. I see following the spec as an important part of quality assurance though.

    Do you want them to produce better stuff for your sake so that when you inherit a project, it is maintainable?

    That would be great, yes.

    I think using the spec as a tool here is the wrong way to go about it.

    Why?

    Well, we’ve seen that writing specs to say what we’d like the Web to be like isn’t going to fix it, so trying to make the best sense of what we’ve given out there is a more sensible approach to helping users.

    In my opinion the problem isn’t primarily the spec, it is lack of education.

    I don’t want to give up and leave the Web to single-vendor solutions, though.

    At least we agree on something :-). Preventing single-vendor solutions from taking over is very important, and certainly should help overcome any differences in opinion on other matters.

    P.S. your comment form does not round trip the entity for less than properly.

    Yes, I am aware of that. Unfortunately I don’t know how to fix it.

  28. Ok. Agreed, that isn’t practical, and I am not suggesting that.

    Cool.

    But I really don’t think those suggesting that pretend people will never make mistakes,

    They are suggesting, though, that HTML5 processing be less robust than existing text/html processing when people do make mistakes. Built-in brittleness would make adopting HTML5 more risky than sticking to old HTML. Positioning a new offering to be less robust than the offering you intend to replace just makes no market sense.

    and I haven’t seen anyone suggest that draconian error handling should be used for pre-HTML 5 content.

    Right. However, those who suggest that old HTML processing and HTML5 processing be separate code paths are fundamentally missing the most important selling point of HTML5 parsing that makes it attractive to implementors (other than Microsoft).

    I’m not going to enter that specific debate though.

    OK.

    Do you want to help other Web developers work better for their sake?

    Yes. And for the sake of their coworkers, and for the sake of the entire Web industry.

    OK. Showing them concrete benefits of your better way of working is a carrot, which is good. Marking their stuff non-conforming is less likely to work as a stick as they could ignore all aspects of conformance checking if they don’t find a tight notion of conformance beneficial to them.

    I suggest advertising the long-term cost savings of your way of working instead of making your way look better in comparison by using the spec to undermine their way of working.

    Yes, that is what I do. I see following the spec as an important part of quality assurance though.

    I take it implicitly that you’d like the document conformance requirements in the spec reflect your notion of quality. Otherwise, your reasoning would be circular as we are debating what the spec should be like.

    In general, if there’s a sloppy way of doing something and a non-sloppy way to achieve the exact same thing, proclaiming that the sloppy way is non-conforming workable. This is the case for e.g. closing elements in the wrong order: There’s no benefit to be had from misnesting markup.

    However, it is a bad idea to proclaim an existing feature non-conforming if the foreseeable consequences would be worse than keeping the slightly bad existing feature. For example, when HTML 4.01 Strict outlawed target=”, some authors who wanted the valid bagde but still insisted on opening windows in response to link click moved on to more complex and harder to detect ways of achieving the results they wanted. (Another example of this is Flash Satay, which reportedly works worse with actual AT implementations than the “invalid” way of embedding Flash that Adobe’s tools use by default. Yet another is that some designers are taught to avoid tables as an absolute and work around this requirement by producing less fluid and more device-dependent CSS positioning-based layouts.)

    Also, if there’s an interoperably implemented feature that a critical mass of authors want to use, marking it non-confoming because you or I find it a bad practice would be a bad strategy because it would dilute the percieved severity of non-conformance. For example, I find the style=” attribute bad for centralized CSS styling and strongly dislike it when Nvu or NeoOffice/OOo adds a style=” attribute that I haven’t specifically requested. Still, I am strongly opposed to making style=” non-conforming as doing so would not eradicate people’s perceived need for the use case. They’d just ignore conformance altogether or come up with more crufty workarounds. (I do want to offer optional conformance checker warnings about style=” attributes to authors who wish to detect and zap style=”, though. However, too much configurability is a slippery slope UI-wise, so in general, I think we should aim for a one size fits all notion of conformance.)

    Basically, if you leave the notion of conformance sufficiently loose, you may be able to raise the quality of a large number of pages to that level. But if you make conformance too tight, overall you achieve less quality as more authors just won’t bother.

    Do you want them to produce better stuff for your sake so that when you inherit a project, it is maintainable?

    That would be great, yes.

    I agree. I just don’t know any workable shortcuts. (Shortcuts as in working around other Web authors lacking the will to adopt practices that lead to more maintainable work product.)

    I think using the spec as a tool here is the wrong way to go about it.

    Why?

    Leaving descriptions of how to deal with real content out of UA conformance requirements would just serve to keep the barrier to UA competetion high.

    As for making document conformance radically tighter than what would “work” as per UA conformance, it would only serve to undermine the notion of conformance altogether or would encourage people to come up with undetectable ways of achieving “bad” behaviors.

    Well, we’ve seen that writing specs to say what we’d like the Web to be like isn’t going to fix it, so trying to make the best sense of what we’ve given out there is a more sensible approach to helping users.

    In my opinion the problem isn’t primarily the spec, it is lack of education.

    The concerns you are voicing seem to be feelings about the spec and the process, though. The spec needs to cover stuff that a tutorial wouldn’t cover, so the spec won’t the foremost piece of education material.

    In addition, when making the “we need more education” argument, one needs to consider the cost of education and the achievable benefit. For example, I think education to eradicate the “misuse” of < em > vs. < i > fails a cost–benefit analysis spectacularly.

  29. May 15, 2007 by chris Jangelov

    The price of education is an interesting thing after we’ve left school. Who is to pay?

    I am not a programmer. I buy coding for web sites. I’ve got two problems:

    1. The coders are very good at their work. So good that they are fully occupied. And there is a lot of knowledge to keep up with for them. ASP, .NET, php5, SQL, you name it. Good coding knowledge. But when it comes to the presentation, the UI, there isn”t really time and money to keep up the pace. I have found myself informing, if not teaching, coders about this new thing called css, a smart thing that makes it unnecessary to create “printer friendly pages” that I have to pay. And a whole new site for handhelds, and… So I think that it is symptomatic that the discussion about “em” and “i” is futilized when we’re talking about excellent programmers that also try to act as professionals in the presentation (html/xhtml) layer. So I end up paying for the web site, for the hand held site, for unnecessary expensive coding when we do redesigns, and so on.

    2. Graphic designers have come from a print tradition. They are good at that and that’s why we turned to them also for the on-line publications. As we all know it is not exactly the same skills that apply in these channels. So mistakes are made, designs are rejected, reworked…and I am paying the bill because they did not educate themselves in the new media. Time? Money? Not realizing the need for it? Well, we are all new to the Internet but somehow I, as a customer, is left in the role to inform everyone about the need for education in this brave new world and then pay for it (by financing all bad design propositions.)

    In my view i consider it sloppy work to have to change 50 “i”:s and good work when we can fix it whith one “em”.

    It is the visitors choice to visit us with a computer (with different sceen resolutions), a smart phone, a Blackberry, a text reader.. well, you name it. There is more often than not no such thing as a web site people order - we order on-line communication.

    In my view the separation af form from content is an absolute must for me to recieve what I order, and to only pay once for that order.

    So I don’t understand the protection of the right for some people not to be educated in their profession when they charge for their work.

    But, then again, I’m only a pawn in the game. (and pawns do the paying) :-)

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.