[Skip to the Main Content]

Error Handling in Browsers make Web Standards Difficult

Lately, I have been monkeying with HTML error-handling by browsers. It’s very interesting. My simple conclusion: valid code is important to authors whereas code that does not pass validation is not important to browsers.

Web Standards! or, Die!

No, not really.

Magical and miraculous things occur when web developers develop with XHTML. And, significant benefits are obtained when meeting well-formedness requirements. Or, when validation’s achieved. Those arguments are illusory.

XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition), 1. What is XHTML? offers,

XHTML documents can be written to operate as well or better [Elementary emphasis] than they did before in existing HTML 4-conforming user agents as well as in new, XHTML 1.0 conforming user agents.”

The W3C states that XHTML is better. Therefore, it must be. However, Though, “new, XHTML 1.0 conforming user agents” are scarce.

Further, 3.2. User Agent Conformance states,

  1. “In order to be consistent with the XML 1.0 Recommendation [XML], the user agent must parse and evaluate an XHTML document for well-formedness [Elementary emphasis]. If the user agent claims to be a validating user agent, it must also validate documents against their referenced DTDs according to [XML].”

That particular sentence is accurate. User agents do evaluate XHTML documents for well-formedness. Still. User agents parse and evaluate all document types: ill-formed documents, well-formed documents and “tag soup” documents. Every document gets parsed and evaluated. How else would they be able to be displayed. However, User Agent Conformance does not address what should occur when well-formedness errors are found.

Further still, we have as example of document well-formedness that user agents must evaluate 4. Differences with HTML 4, 4.3. For non-empty elements, end tags are required which states,

“All elements other than those declared in the DTD as EMPTY must [Elementary emphasis.] have an end tag.”

All well-formedness requirements are necessary for the preparation of future document, e.g., web page, migration to XML (as envisioned by W3C). One must remember that XHTML was invented as the transitioning markup language for web developers before they “enter the XML world with all of its attendant benefits.”

I doubt I shall transition into XML but I do believe in well-formed (X)HTML documents. I do not perceive the benefits of well-formedness as XML-related but Web Standards-related. All requirements in Differences with HTML 4 and HTML Compatibility Guidelines should be met by authors.

The W3C states XHTML is better; all XHTML documents must be well-formed; and, user agents must parse and evaluate for document well-formedness. That’s all well and good but no beneficial results will be seen for those efforts when ill-formed (X)HTML documents are rendered by browsers (or, User Agents) (of which the previous article illustrated). All of the magical and miraculous things implied by the W3C are naught: user agents need only parse and evaluate.

I’ll show you.

Anne van Kesteren generously allowed me the use of one of his pages in my effort to provide a real-world illustration of what browsers do with well-formedness as regards error-handling. Anne’s site is well-formed "Tag-Soupless" HTML. [Note: It validates.] On this particular page, I’ve replaced the HTML Document Type Declaration with <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">; and, I’ve excised functioning elements. Those are the only revisions made.

The facsimile looks like this.

If you compare the actual page with the facsimile page, they are identical. User agents parsed and evaluated the HTML-version and rendered the page as Anne intended. User agents parsed and evaluated the XHTML-version for well-formedness and acted appropriately: they've gone error-handling. The Document Type Declaration (with its URI and its definition) didn’t perform magical things: the DocType triggered standards-compliant mode and the definition triggered CSS interpretation as expected. User agents went SGML, or Standard Generalized Markup Language, error-handling as triggered by the Content-Type, i.e., <meta http-equiv="Content-Type" content="text/html">. Graceful error handling. [Note: HTML is one way of defining and interpreting elements according to SGML rules.] And, Yes. If the Content-Type had been application/xhtml+xml, draconian (or, Fatal Error) error-handling would have occurred.

Fatal Error

“[Definition: An error which a conforming XML processor must detect and report to the application. After encountering a fatal error, the processor may continue processing the data to search for further errors and may report such errors to the application. In order to support correction of errors, the processor may make unprocessed data from the document (with intermingled character data and markup) available to the application. Once a fatal error is detected, however, the processor must not continue normal processing (i.e., it must not continue to pass character data and information about the document’s logical structure to the application in the normal way).]”

It’s paradoxical, isn’t it. Authors (or, web developers) are required to meet well-formedness requirements but browers needn’t bother.

<font> is a deprecated presentational element in XHTML 1.0 but browsers parse it. Further, <canvas> is supported by several browsers even as the HTML5 specification remains in draft form.


The arguments about whether one should use HTML 4.01 or XHTML 1.0 are philosophical. The arguments about meeting well-formedness requirements are philosophical. They are philosophical because browser manufacturers make them so. Current error-handling relegates any practical benefit illusory.

Most browsers enable graceful error-handling for faulty (X)HTML pages; draconian methods for XML pages. I do not want draconian methods employed by browsers nor do I want graceful methods. There is a third method of error-handling: Cascading Style Sheet (CSS) errors. CSS syntax written erroneously is ignored, e.g., p { font: oblique; }. I am certain even that method of error handling would break most non-compliant sites.

I believe in web standards. I practice web standards; I advocate web standards; I curmudgeon others in adopting web standards. And, that includes well-formedness.

Sean Fraser posted this on April 15, 2007 10:00 AM.

  • Add to Technorati Favorites
  • de.licio.us: http://www.elementary-group-standards.com/web-standards/web-standards-and-error-handling.html
  • furl: http://www.elementary-group-standards.com/web-standards/web-standards-and-error-handling.html
  • reddit: http://www.elementary-group-standards.com/web-standards/web-standards-and-error-handling.html


James Cassell wrote this at April 20, 2007 05:21 PM

The original page and the modified version do in fact look different. Your modified version looks broken in my browser (Opera 9.1)

Comment Author Gravatar
Sean Fraser wrote this at April 20, 2007 06:46 PM

James: Thank you for finding that! It is neither Opera nor any other User Agent display. It was my error: faulty CSS modification tested locally. It's been fixed. The page blue background image of the navigation is where it should be.

Error-handling remains.

Comment Here

Reply guidelines: Basic HTML (a href, p, code, blockquote, dl, dt, dd, ul, ol, li, cite and q) are allowed. Line breaks and paragraphs are automated.

Inappropriate, unwarranted or self-aggrandizemented comments may suffer redaction. Or, deletion.

[Note: A gravatar, or globally recognized avatar, is that small image in the comments. Gravatar sets-up them.]

The Elementary Standards: A Compendium of Web Standards, CSS, Linguistics and Search Engine Optimization methodology Copyright ©2005-2007 Sean Fraser. All work is published under a Creative Commons License. All Rights Reserved.

Palm trees on a grassy field in Hawai’i

Main Content Returns thus