- From: James Graham <jg307@cam.ac.uk>
- Date: Tue, 20 Feb 2007 23:17:58 +0000
Vlad Alexander (xhtml.com) wrote: > 4. One of the biggest problems with HTML is that content authors can > get away with writing "tag soup". As a result, most content authors > don't feel the need to write markup to specification. When markup is > not written to specification, CSS may not get applied correctly, > JavaScript may not execute and some user-agents may not be able to > process content as the author intended. Why not put an end to "tag > soup" by requiring user-agents to only accept markup written to > specification? Because there's a logical gap in the argument that requiring XML-style fatal error handling will cause documents to become well formed. That hole is simply the assumption that authors would choose to use such a document format when competing formats with graceful error handling are available. Witness the fact that despite the supposed benefits of XML the number of websites that are ever fed through a XML parser is miniscule; the vast majority of "XHTML" sites on the web would not actually work if the error handling requirement was based on doctype rather than MIME type. I suggest that if authors of these sites actually had to consistently produce well formed (not even valid!) content, they would quickly return to HTML -- otherwise why are they not reaping the "benefits" of XML by sending application/xhtml+xml to browsers which support it? Indeed I believe that it is _only_ because of the lax error handling that the web has caught on to the extent that it has; the people with interesting content are often not those with a fanatical devotion to computer language syntax. Even in cases where the content really is well formed XML the client is entirely the wrong place to enforce validity -- it means that a tiny mistake causes suffering for the person least able to deal with the problem -- the end user. Needless to say this is terrible UI and thus widespread implementation of fatal error handling is, at best, a metastable situation -- as soon as one UA decides they can gain some advantage by including error handling, everyone else has to follow suit. This has happened with many "XML" based feed formats, for example. Compared with these issues, the problems with tag soup that you bring up are much less substantial. Even with identical parsers in all browsers differences between UA's CSS and DOM implementations will still cause rendering and scripting differences and thus authors will still need to ensure that the content works acceptably across a range of browsers. No doubt using a conformance checker to locate syntax errors (which is, of course, the correct place to perform such a check -- where the problem can be fixed) will still be an important part of this debugging process. By offering a well-defined algorithm for handling syntax errors, HTML5 offers a future with significantly less ambiguity in the behavior of browsers when they encounter poor markup, thus bringing the benefits that consistency offers without the user hostile and, I believe, unworkable, XML approach of taking home the ball and refusing to play. > 6. The font element is a terrible construct, primarily because > content creators using authoring tools use the font element instead > of semantic markup. People also use <div> and <span> instead of semantic markup. Semantically <font> is no worse than <span style="">. Neither are ideal but the experience of WYSIWYG editor implementors is that it is impossible to design a WYSIWYG editor that produces good semantic markup all the time and is usable by the kind of person who wants to use a WYSIWYG editor. This is an example of "practicality beats purity" a tenant of the Python programming language which I believe also applies to much HTML5 work (perhaps others would disagree; obviously I only speak for myself). > 10. In the minds of most people. HTML is dead and X/HTML 5 is > perceived as an attempt to resurrect it. Do you have some statistics on that? It's certainly not what I perceive (I do believe that many people use "XHTML" in a cargo-cultish way because they have been told it is "better" but without understanding why). Furthermore, the reformation of the html working group at W3C suggests they don't believe html is dead. In the absence of supporting evidence, may I suggest your statement could be interpreted as trolling, which I assume was not intended. > Given this perception, how > can you succeed in marketing HTML to consumers (those who build Web > sites)? By providing features they want to use. This is already happening -- see, for example, the use of <canvas> in several places, the fact that Opera supports Web Forms 2 (amongst other parts of HTML5), the fact that Firefox now has support for the offline storage (again, amonst other parts of the spec) and so on. -- "The universe doesn't care what you believe. The wonderful thing about science is that it doesn't ask for your faith, it just asks for your eyes" --- http://xkcd.com/c154.html
Received on Tuesday, 20 February 2007 15:17:58 UTC