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
