HTML 5 working draft defines a parsing algorithm which is robust enough that it will not break for the most common types of errors. Many computing engineers and Web designers think that this feature encourages bad quality for documents. Point taken. But let’s look a bit further at what proposes HTML 5 in terms of input and output.
I do mistakes very often. English is not my mother tongue. I try to fix spelling mistakes as much as possible. Still, my English grammar is still behind. Oh, not looking for any excuses, I do mistakes in French too. But I’m glad that our brains have a very robust parsing mechanism which helps us to recover from broken sentences (bad spelling and clumsy grammar). Just imagine for the experiment, that your brain was not able to parse any sentences that would not be grammatically correct. How many sentences in our daily conversation are 100% correct? Not that much.
At W3C, we take meetings minutes (a lot) of discussions happening over a phone. During these teleconferences, there are people from different nationalities, different accents, different levels of English and on top of that in different time zones (fatigue). Still the scribe (minute taker) writes down, most of the time, correct English sentences after parsing them. The scribe creates a serialization of what he heard, but modifies it to be correct.
An HTML 5 Tidy library could do the same thing. It could parse a broken document and create a DOM following the HTML 5 parsing algorithm. Then it could serialize it (writes it down) following the HTML 5 content model. That would create a conformant HTML 5 document.
This is an important part of the process. What you hear is not what you write. You are stricter, once you have recovered the meaning. The same way what the HTML 5 Tidy library has parsed is not what it will serialize. Let’s take a practical example with the infamous
<!DOCTYPE html> <html> <title>a broken document</title> <center><p>I want to be in the center of the page.</p></center> </html>
The innerHTML view (using HTML 5 Live DOM viewer) is:
<!DOCTYPE HTML> <html> <head> <title>a broken document</title> </head> <body> <center><p>I want to be in the center of the page.</p></center> </body> </html>
But the document will be invalid and the message given by the experimental HTML 5 validator instance will be
Validation Output: 1 Error # Error Line 4, Column 7: The center element is obsolete..
Why? Because nowhere in the content model of HTML 5, the center element is defined. You can’t write an HTML 5 conformant document containing the
center element. An HTML 5 Tidy library would emit only elements which are compatible with the HTML 5 content model. In this case that could be
<!DOCTYPE HTML> <html> <head> <title>a broken document</title> </head> <body> <p>I want to be in the center of the page.</p> </body> </html>
Some people will argue that everyone will want different rules. Indeed that is possible. Some will want to have double quotes around attributes, some single quotes. And if we take into account the set of documents which have complex mixed markup, it will indeed create a lot of headaches. But it’s why I think it would be interesting to define a set of basic rules for emitting HTML 5 after it has been parsed.
Some might propose solutions of the following type for the
<!DOCTYPE HTML> <html> <head> <title>a broken document</title> </head> <body> <p style="text-align:center;"> I want to be in the center of the page. </p> </body> </html>
Daniel Glazman proposed recently something quite similar for HTML attributes, inline style or style rules.
Are there any engineers which would be ready to take the challenges of designing an HTML 5 Tidy Library (and the canonic rules to fix the output) using the content model of HTML 5? I showed recently that there will be less document validating with the HTML 5 doctype than with their current doctype. Henri Sivonen rightly commented that HTML 5 content model was stricter than previous versions of HTML. This will not leverage the adoption of conformant HTML 5.
An HTML 5 Tidy Library (even not perfect) would help people to move forward. If there are no benefits, people will continue to use HTML 4.01 and/or XHTML 1.0 because, in the end it doesn’t matter,
- it will still be parsed correctly by browsers.
- Authors can use the existing XHTML books out there, rely on their years of experience of the language and business practices,
- and, last but not least, they will benefit of the tools which fix their invalid content.