summaryrefslogtreecommitdiff
path: root/old/published/Webmonkey/Monkey_Bites/2007/03.26.07/Thu/xhtml5.txt
blob: 685980810e38f3b90ff796bfee3df8f8feff7f34 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Earlier today I ran across an [interview with Ian Hickson][1], former Opera developer, now at Google, about the future of X/HTML 5.0. Hickson is the editor the X/HTML 5 spec which is not to be confused with XHTML 2, the successor to XHTML 1.0.

Hickson has some interesting comments and outlines some of the goals for the development of X/HTML 5. Hickson also mentions a study he worked on at Google that sampled of several billion web documents and found that more that 78 percent of them had HTML errors. 

"And those are only core syntax errors -- (the survey) didn't count misuse of HTML, like putting a p element inside an ol element," he adds.

But in spite of that, Hickman recognizes that it was not good code that sped the growth of the web. He argues that it was browsers ability to handle errors and fail silently that makes the web both full sloppy coding and happy users.

>Having draconian error handling -- the term we use for just not allowing errors instead of having silent error recovery like HTML does -- is not the only solution for getting consistent behavior between browsers. The approach that we have taken with HTML 5 is to define what any document means, even if it is invalid -- down to the last detail, so that every browser will handle every document in an equivalent way, whether the document is conformant or not. (It's the same technique CSS uses.)

One of the unfortunate things happening right now is the splitting of  X/HTML 5 and XHTML 2, the last thing the web needs is two totally separate specs. In fact that's one of the main things that Hickman things is wrong with the web.

He argues that for the sake of our future generations, we should document exactly how to process today's documents, otherwise they might well have no idea how to write a browser. Strange though it may seem there is very little information out there about how HTML is supposed to be rendered. 

Most of the documentation and tutorials you'll see are how to make HTML look certain ways within different browsers. According to Hickman even the browser manufacturers often resort of reverse engineering each other code to discover how to handle certain complex situations.

>Once I got into actually documenting HTML for the future, I came to see that the effort could also have more immediate benefits, for example today's browser vendors would be able to use one spec instead of reverse engineering each other; and we could add new features for authors.

It'll be years before X/HTML has much impact on the average designers life, although the recently released Yahoo Pipes does use <code>canvas</code> feature of HTML 5, still X/HTML is being developed as an open project. If you'd like to learn more, check out the [Web Hypertext Application Technology WG][2] -- WHAT Work Group.

[1]: http://xhtml.com/en/future/conversation-with-x-html-5-team/ "Conversation With X/HTML 5 Team"
[2]: http://www.whatwg.org/ "Web Hypertext Application Technology"

[photo credit][3]

[3]: http://www.flickr.com/photos/daniello/422213306/ "html tattoo"