{"id":125,"date":"2006-10-29T18:38:42","date_gmt":"2006-10-29T18:38:42","guid":{"rendered":"http:\/\/lachy.id.au\/log\/2006\/10\/fixing-html"},"modified":"2006-11-22T05:34:51","modified_gmt":"2006-11-22T05:34:51","slug":"fixing-html","status":"publish","type":"post","link":"https:\/\/lachy.id.au\/log\/2006\/10\/fixing-html","title":{"rendered":"Fixing HTML"},"content":{"rendered":"

Earlier today, Joe\r\n\t\tClark responded<\/a> to Tim Berners-Lee\u2019s announcement of the W3C\u2019s\r\n\t\tnew plan for HTML<\/a>. Joe has argued that fixing HTML is not\r\n\t\tas important as accessibility, and that the WCAG working\r\n\t\tgroup is in much more serious trouble than the HTML working group. For this,\r\n\t\the seems to be criticizing the W3C\u2019s decision.<\/p>\r\n

He has also criticised the WHATWG and their work on HTML 5, claiming that\r\n\tthey\u2019re making the same mistakes as the W3C, and raised several issues and suggestions\r\n\tfor improving HTML.<\/p>\r\n\r\n

Working Groups<\/h3>\r\n

I\u2019m not disputing his claims about the problems with the WCAG working group\r\n\tor the WCAG 2.0 guidelines. In fact, I agree with him in that regard. But\r\n\tto imply that that the W3C doesn\u2019t need to do anything about (X)HTML or the\r\n\tHTML working group is misguided. Something desperately needs to be done with\r\n\teach of the HTML, XForms and WCAG working groups; they\u2019re all in serious trouble\r\n\tand their problems need to be fixed.<\/p>\r\n

The W3C\u2019s decision to deal with the HTML working group is at least a step\r\n\tin the right direction. Whether the chosen path is right or wrong is\r\n\tyet to be seen and I\u2019m trying to reserve judgment until more information\r\n\tis available. But I promise, as soon as\r\n\tthe\r\n\tinformation I\u2019ve asked for<\/a> becomes\r\n\tavailable, I\u2019ll review it thoroughly.<\/p>\r\n\r\n

The Problems with HTML<\/h3>\r\n
\r\n\t

HTML is a topic of interest. But it isn\u2019t an outright fiasco. HTML, in large\r\n\t\tpart, works fine right now.<\/p>\r\n<\/blockquote>\r\n

It is true that HTML 4.01 itself isn\u2019t a total fiasco. In many ways, it works.\r\n\tWe\u2019ve been using it for years without too many problems and will continue to\r\n\tdo so for many years to come. However, there are many problems and limitations\r\n\twith it that need to be addressed.<\/p>\r\n

There are also many problems with the W3C\u2019s HTML working group, who have been\r\n\tignoring the needs of real world developers and pushing ahead with a\r\n\tlanguage that is doomed to failure<\/a>.\r\n\tThey\u2019ve not only completely ignored\r\n\tbackwards compatibility issues, but have failed to adequately address many\r\n\tother issues that have been raised.<\/p>\r\n

For instance, they\r\n\t\tdon\u2019t consider error handling to be important for interoperability<\/a>. \r\n\tThey\u2019ve made vague statements about how they don\u2019t need to define error handling,\r\n\thow browsers should just refuse to handle erroneous content, and they don\u2019t\r\n\tcare if different browsers handle it differently.<\/p>\r\n\r\n

The Process<\/h3>\r\n
\r\n\t

\u2026which means that, with the W3C\u2019s glacial processes, we\u2019ll have a spec document\r\n\t\tto look at in 2010 and actual browser support in 2012. <\/p>\r\n<\/blockquote>\r\n\r\n

Yes, it is true that specs do take a long time to write and a long time to\r\n\timplement, but there are reasons for that. The process involves many steps,\r\n\tdesigned to help ensure the quality of the final specification. But, due to\r\n\tthe process, actual browser implementation must occur before<\/em> the spec\r\n\tcan be finished, not years afterwards.<\/p>\r\n\r\n

Criticisms of the WHATWG and HTML 5<\/h3>\r\n
\r\n\t

My concern is that WHAT WG is doing exactly what the W3C did. Due in no small\r\n\t\tpart to WHAT WG\u2019s leadership by a strict standardista with an interest in video\r\n\t\tgames, \u201cHTML5\u201d replicates HTML\u2019s obsession\r\n\t\twith computer-science and math elements<\/a>.<\/p>\r\n\t