[whatwg] HTML syntax: comments before doctype and doctypesniffing
spartanicus.3 at ntlworld.ie
Sun Dec 3 16:57:17 PST 2006
"Simon Pieters" <zcorpan at hotmail.com> wrote:
>>I'm assuming that this comment merely documents IE's current behaviour.
>>Please ignore my other comment if I'm wrong.
>A comment before the doctype has equal status as lack of doctype or an
>incorrect doctype. Hence, conformance checkers will flag such documents as
>non-conforming, and the syntax section should only allow things that will
>pass conformance checking.
OK, I noticed that myself whilst experimenting with Henri's validator
recently. If the current HTML5 draft is contradictory in the parsing vs
syntax section then that could make arguments to allow it irrelevant.
>>There are valid reasons to kick IE into quirks mode whilst triggering
>>"standards mode" in other browsers.
>What are those reasons?
I could be way off base here, but I expected future HTML5 compliant
browsers not to change the doctype sniffing mechanisms/rules that are
currently used, since as far as I understand the HTML5 <!DOCTYPE html>
currently already triggers standards mode in current browsers.
If that assumption is true then allowing SGML comments to precede the
doctype could result in better compatibility of such future HTML5
compliant browsers with existing web content authored to trigger quirks
mode in IE.
Some examples of why triggering IE's quirks mode could be useful to
IE6 in "standards mode" introduces new bugs compared to IE5.5.
Since IE6 in quirks mode does a pretty good job of emulating the 5.5
bugs, an author may prefer to deal with one set of IE bugs and
associated workarounds and hacks. I have authored sites with the aim of
keeping them compatible with IE5.5 without resorting to IE5.5 vs IE6
distinguishing hacks such as the Tantek hack. Kicking IE6 into quirks
mode was the easier option.
I orphaned off a number of sites some time ago, this was before the IE7
betas emerged. In the hope of standing a better chance of getting those
sites to render in a future IE7 I gambled that MS might restrict for
example support for the child selector to "standards mode". These sites
extensively used the child selector hack to apply fallback CSS for IE
and advanced CSS for proper browsers, advanced CSS that by that time I
knew IE7 was unlikely to support (like generated content or CSS tables).
(email whitelist in use, non list-server mail will not be seen)
More information about the whatwg