[whatwg] a few comments to Webforms 2.0 Call For Comments
mpt at myrealbox.com
Sat Jul 31 20:10:46 PDT 2004
On 31 Jul, 2004, at 11:58 PM, Henri Sivonen wrote:
> First of all, the solution needs to apply to XHTML as well as HTML. If
> we still assume XML is to be taken seriously (and not as tag soup),
> doctype sniffing on the XML side is totally, utterly bogus.
That's a presumptive definition of "seriously". In the long run, it
*may* be the case that treating XHTML as tag soup is the only "serious"
way of doing it. (I know that's a heated debate that doesn't belong on
this list, but it's probably heated because the answer's not yet
obvious enough for "seriously" to mean anything.)
> The reason why it is bogus is that including a DTD by reference and
> pasting it inline are supposed to be equivalent for validating XML
> processor and in the latter case you don't see a public identifier for
> the DTD. Hence, using the public identifier for any purpose other than
> locating the DTD is just plain wrong. Of course, sane real-world XHTML
> user agents use non-validating XML processors which makes the
> inclusion of the doctype declaration rather pointless.
So do any real-world XHTML UAs handle a DTD pasted inline, or is this
just a theoretical argument?
> Now, similar argumentation does not work on the HTML side if we agree
> not to pretend that real SGML is being processed. Doctype sniffing is
> a tag soup solution to a tag soup problem.
That's an extrapolation from a single data point. The only use of
doctype sniffing *so far* has been to handle quirky style/layout
expectations of old pages (and in the case of table style inheritance,
they wouldn't even need to be tag-soup pages). In the long run, doctype
sniffing may become a general-purpose method of changing *any*
undesired behavior (whether de-facto or de-jure) of old syntax in new
> Still, doctype sniffing is already confusing and convoluted enough for
> casual authors. (See http://iki.fi/hsivonen/doctype.html for subtle
> differences between user agents.) I think perturbing it further is a
> bad idea.
Sure, but it may be unavoidable, just like it is with natural
languages. (Try running "The Canterbury Tales" through a Modern English
spellchecker or grammar checker, for example.)
> Besides, you can't force the existing installed base of browsers to do
> new tricks with doctypes which would mean different defaulting.
Which is probably why Matthew Raymond's proposal doesn't require the
existing installed base of browsers to change anything.
More information about the whatwg