Rebuilding The Web

Articles, advocacy, discussion and debate about the many problems of the Web and the challenges of rebuilding it.

Why is the HTML specification a failure?

Introduction

The HTML specification is a failure because, of its intended users, practically no one is using it as it was intended to be used. Why? Is HTML too difficult to use correctly? Is the incorrect use of HTML explained by a lack of education? Did W3C mismanage the deployment of HTML? Or is the failure of the HTML specification due to a lack of error feedback?

Background

HTML was designed so that semi-technical people could write HTML using a text editor (i.e.: writing HTML by hand). However, even in the early days of the Web, when HTML was a smaller and simpler specification, even when HTML was written by fairly technical people, it was not written according to the specification. Web browser vendors, with support from W3C, decided that Web browsers should render incorrectly written HTML without any error feedback to the user. Twenty years later, only a very small percentage of Web pages are written to the HTML specification.

Is HTML too difficult to use correctly?

Is there something fundamentally wrong with HTML that could explain why people simply cannot use it correctly? Some parts of HTML can be confusing to new users such as the need to escape certain characters, how to properly write empty elements and boolean attributes, and how to apply element nesting rules. Even if HTML were difficult to author, could this fact alone explain why over 90 percent of the pages on the Web do not conform to the HTML specification?

Is incorrect use of HTML explained by lack of education?

Up to the late 1990's, good HTML education material (guides, references, tutorials, etc.) was hard to come by. If you were a Web developer/designer, you had to use the HTML specification document, which was written for tool vendors. So in the early days of the Web, lack of education could explain some of the incorrect use of HTML.

Yet today there is an abundance of good quality education material, and still the new generation of Web designers/developers are just as ignorant of the correct use of HTML as their predecessors.

Did W3C mismanage the deployment of HTML?

W3C is a standards body that is financially supported by paying members. In exchange for membership fees, W3C provides its members access to private documentation and support on its specifications, and the ability to participate in the development of the specifications. Until recently, W3C was not engaged with Web site creators who represented the majority of the intended users of the HTML specification. Did W3C create a specification for general Web site creators but did not give them the necessary support to use it correctly?

Is the failure of the HTML specification due to a lack of error feedback?

When modern Web browsers encounter a Web page with incorrectly written HTML, they silently try to auto-correct the HTML and render the page, without letting the user know of any errors. Given no error feedback, how are people supposed to know if they are writing HTML to specification?

There are two types of error feedback - active error feedback and passive error feedback. Active error feedback is when a Web browser encounters a Web page with errors and stops rendering the page, notifying the user of the errors and presenting the user with the option of rendering the page by auto-correction. Passive error feedback is when a Web browser encounters a Web page with errors, auto-corrects the errors as best it can, then renders the page with a clearly visible icon or message indicating that the Web page contained errors. Would active or passive error feedback encourage more users to use HTML correctly?

Conclusion

It is important to find out why the HTML specification failed so that past mistakes are not repeated.

Public comments

1. Posted by Mike
on Tuesday 2009-10-27 at 09:00:38 PST

We always do a post mortem after a project at work so I wonder if w3c does them on their specs? It'd be interesting to know if they asked the same questions and what they saw as success and failure of HTML?

2. Posted by Michael
on Tuesday 2009-10-27 at 15:11:20 PST

I was at a venue where one of the w3c guys was talking about the HTML 5 specs and likening the browser error handling to modern society and petty theft - that modern society generally handles them all in the same way -- depending on the severity of the crime.

I spoke to him after the presentation and disagreed that this analogy was accurate stating that criminals are punished, not handled, and I thought that the handling of errors in HTML 5 should be likened to that of XML - If there's an error in the code, then don't display it. (i.e. punish the website author who committed the crime, not the by-standers or victims (web clients)).

However, as a colleague pointed out, HTML is a markup language that is not a strict definition of exactly how the code should exist but, more importantly, a template of how 'correct code' should exist. Once HTML 5 comes out the belief is that "Every browser will render errors the same way", in a vain attempt to eliminate browser quirks and ensure that things "operate the same way".

Honestly, however, why ensure errors are rendered the same way when you can just say "don't render the errors" (fail "gracefully" like XML) and then spend all W3C's money trying to ensure browsers handle CSS the same way.

Or have an active campaign to have IE9, Opera and Firefox all switch to and develop WebKit. Would make website developer's lives a lot easier.

3. Posted by Vlad Alexander
on Tuesday 2009-10-27 at 19:42:50 PST

Michael wrote "I was at a venue where one of the w3c guys was talking about the HTML 5 specs and likening the browser error handling to modern society and petty theft"

First, I have not heard the comparison of error handling to petty theft before, and still I do not understand this comparison. Second, I always try to see both sides of an issue. But I simply fail to understand the mindset of those who are against error feedback. Can anyone make a clearer case against active or passive error feedback in the browser?

4. Posted by Johnny
on Thursday 2009-10-29 at 08:26:26 PST

"practically no one is using it as it was intended to be used"

Why do you equate that to meaning that the spec is a failure?
I would have argued that the primary purpose of the spec is to provide something usable, which they have clearly succeeded at.

5. Posted by Vlad Alexander
on Thursday 2009-10-29 at 09:34:33 PST

I wrote: "practically no one is using it as it was intended to be used"

Johnny wrote: "Why do you equate that to meaning that the spec is a failure?"

Wikipedia defines specification as: "A specification is an explicit set of requirements to be satisfied by a material, product, or service. Should a material, product or service fail to meet one or more of the applicable specifications, it may be referred to as being out of specification". The application of HTML on the Web is clearly "out of specification" and therefore HTML is failure as a "specification".

Johnny wrote: "I would have argued that the primary purpose of the spec is to provide something usable, which they have clearly succeeded at."

One could argue that the primary purpose of an organization, such as W3C, is to provide something usable and W3C did just that. But the primary purpose of a specification is different.

6. Posted by Unibands
on Friday 2009-10-30 at 03:52:10 PST

It's a nice feeling to be an idealist and hope that future browsers render HTML5 with errors, but that simply will not happen (especially active errors), and certainly not now the web is so popular with business, where money is to be made.

Can you honestly imagine a browser vendor taking this step? With regard to a front-end user, they would simply believe the browser they were using was faulty and NOT the website itself. And to be honest, they wouldn't care who was to blame, they want to see a working (or semi-working) website and get what they need. The specifics of why a page would error to an average person would not be a legitimate argument or justification for rendering a page completely useless.

No browser vendor would be successful penalising web authors for incorrect markup. Their market share would soon deplete as users become more frustrated with seeing these errors. In addition, you would also be punishing authors of the past and a whole wealth of content on the Internet simply to make youself feel better about markup that's just a little bit tidier.

I love web standards, I do, but HTML is not a programming language. It doesn't have conitional logic, does not loop and iterate, does not calculate figures. It's a language that defines the structure of content and that is it. So you shouldn't treat it like a pgramming langauge.

In fact, I would go so far as to say that HTML's lack of error support is a key factor to the web's success.

7. Posted by Vlad Alexander
on Friday 2009-10-30 at 10:44:10 PST

Unibands wrote "...you would also be punishing authors of the past..."

Nobody is advocating error feedback for existing content. The advocates of error feedback are talking about future content written to a future spec such as HTML5.

Unibands wrote: "So you shouldn't treat it [HTML] like a pgramming langauge"

Okay. HTML should be treated just like other data format files such as Word, Zip, XML, etc. If you corrupt one of these files (ie: not write it to specification), the application trying to open this file will fail.

Unibands wrote: "I would go so far as to say that HTML's lack of error support is a key factor to the web's success."

I will respond to this in the next post.

8. Posted by David Hucklesby
on Saturday 2009-10-31 at 10:29:09 PST

Hmm. Perhaps we should be teaching XHTML as XML? Problematical with lack of IE support, I know, but simply naming a document with, say, an extension of ".xhtml" for real browsers, and ".html" for IE, students would quickly learn the rules. Even some hosts will serve files with the correct MIME type according to the filename suffix...

9. Posted by David S
on Thursday 2009-11-05 at 16:46:34 PST

I also cannot imagine a browser maker being able to "stay in business" if they started showing error icons or something similar whenever pages came up "bad." Although you are quite correct that other corrupted data formats pretty much nuke their related application.

What I would like to see is a browser that has a default "user" mode that operates as browsers now operate AND ALSO has a "developer" mode that could be toggled by folks making sites to assist them in fixing up their code to spec.

It's hard for me to know whether the w3c spec is a failure or not...certainly as a "simple" markup language it has enabled a whole new era of publishing. However, I do think you are on to something, because any spec that is so seldomly used well, or properly, must have something wrong with it. Seems to me a "successful" spec would be written in such a manner as to not only encourage proper use, but also in a manner that would gently "nudge" users into using it properly (even if they were not so disposed to do so on their own).

This seems a bit like a chicken and egg dilemma to me...

In my heart of hearts, though...if life were as I wished it to be...browsers wouldn't work when the code was improperly used. If this really were the case, we'd all be surprised how fast everyone learned to use HTML correctly.

10. Posted by Vlad Alexander
on Thursday 2009-11-05 at 19:44:23 PST

David S wrote "What I would like to see is a browser that has ... a 'developer' mode that could be toggled by folks making sites to assist them in fixing up their code to spec."

That would be a step in the right direction.

David S wrote "I also cannot imagine a browser maker being able to 'stay in business' if they started showing error icons or something similar whenever pages came up 'bad'".

Internet Explorer does this for JavaScript errors as shown in the screen shot below.

Screen shot of a 16 by 16 pixel icon displayed in Internet Explorer status bar when a page contains JavaScript errors.

Could a 16x16 pixel icon drive a browser vendor out of business?

11. Posted by David S
on Saturday 2009-11-07 at 08:08:24 PST

@Vlad:

Good point -- a subtle marker (e.g., 16x16 pixel icon) doesn't seem to be a big deal at all. I was envisioning a larger alert message, because I think -- right or wrong -- that many web building people would ignore a small subtle marker just as the general population (as you point out) seems able to ignore it. You've convinced me, though...

Back to whether the HTML spec is a failure...I wonder whether specs like HTML should, in the future, be less description of a system of "code" and maybe more of a "how-to" document that explicitly lays out not the whys and wherefores so much as "this is what you should do." Perhaps by providing a document that spells out simply and clearly HOW to write good code, the W3C (as well as other organizations) could actually have a more successful and far-reaching impact on how web pages/web apps actually appear in the wild, because people developing those sites and apps could actually UNDERSTAND what to do...not just try to wade through an interminable spec that "nobody" understands and still end up with what we have now on the web? Just a thought...

Comments are closed for this article.

Main menu

Check out the a11y bugs project that aims to help browser / tool vendors fix accessibility bugs.