W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2007

[whatwg] several messages about HTML5

From: James Graham <jg307@cam.ac.uk>
Date: Tue, 20 Feb 2007 23:17:58 +0000
Message-ID: <45DB81A6.5090601@cam.ac.uk>
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

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:32 UTC