This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
<!--comments before--><!DOCTYPE html> should be forbidden, because a) it triggers quirksmode in IE6, IE7, IE8 and IE9; b) "HTML5 compliant quirksmode" isn't needed & is against HTML5's spirit Valid HTML5 shouldn't trigger quirks in mayour browsers! c) it is a gotcha to authors; Confusion isn't hard to locate.[1][2] Even a check of the 10 first pages on Philip Taylor's no-quirks list revealed that one of them <!---> before DOCTYPE; [3] d) there is an alternative: <!---> *after* the DOCTYPE; e) it is a hindrance to Polyglot Markup; * <!---> before DOCTYPE is OK in 'application/xhtml+xml', ( as long as it follows *after* a possible XML declaration) ; * Thus e.g. IE9 in 'application/xhtml+xml' mode gets no problems. * But the same page in text/html mode will cause IE quirks; f) it promotes proprietary syntax; Proprietary code such as <!--[if !IE]><![endif]--> <!DOCTYPE html> and <!---><!DOCTYPE html> <meta http-equiv="X-UA-COMPATIBLE" content="IE=Edge" /> is the only way to have <!---> before DOCTYPE w/o getting IE quirks POSSIBLE COUNTER ARGUMENTS: * Claim: "There is a need to trigger quirks mode in IE6 an donly in IE6!" Whether there is such a need, is a question in itself. But, for now, assuming there is such a need, then: ANSWER 1: To forbid comments before the DOCTYPE does not hinder authors from still using them. It just won't validate anymore. HTML5 defines no-quirks as the default mode. There are many syntaxes that are forbidden in HTML5, but which still triggers *no-quirks* (a.k.a. standards) mode in HTML5 parsers. (For example, the XML declaration doesn't trigger quirks mode in a valid HTML5 parser.) Forbidding comments before the DOCTYPE will be no different. ANSWER 2: For XHTML pages, there is one, common answer to that problem: use the XML declaration before the DOCTYPE. (For examples of that kind of advice, see http://www.gunlaug.no/contents/wd_additions_16.html and http://www.456bereastreet.com/archive/200904/using_an_xml_declaration_triggers_quirks_mode_in_ie_6/ ) This will trigger quirks-mode in IE6, but not in IE7, IE8 or IE9. (But note that even if XML declaration was permitted, it would still have to be forbidden to use comments *between* the XML declaration and the DOCTYPE, as this causes quirks-mode in IE7, IE8 and IE9.) ANSWER 3: Authors will develop other methods for triggering quirks-mode in IE6. HTML5 should nevertheless not promote quirks-mode. References: [1] http://stackoverflow.com/questions/941100/can-html-comments-appear-before-the-doctype-declaration [2] http://stackoverflow.com/questions/2770392/html-doctype-setting-ie-quirks-mode [3] http://philip.html5.org/data/doctypes.html#HTML5_non-quirks
An advantage which a forbidding of comments before the DOCTYPE provides, is that it would largely kill off X-UA-COMPATIBLE meta elements from having any effect in legal HTML5 syntax. BECAUSE: <!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=8" /><![endif]--> must appear *before* the DOCTYPE in order to affect the parsing mode. Only if used "naked" (that is: outside condional comments) does it work *after* the DOCTYPE. THUS for example this: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=8" /><![endif]--> causees quirks-mode even in IE8. (And IE9 assumingly works the same.) WHERAS this: <!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=8" /><![endif]--> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> causes standards-mode in IE8, despite the transitional DOCTYPE. This would be an advantage, because X-UA-COMAPTIBLE is only proprietary syntax and, in general a PIA and a complication for web authors. (If authors doesn't care about HTML5 validity anyway, then they are of course free to use X-UA-Compatible.)
Henri, any opinion on this?
That it triggers quirks mode in IE is a bug in IE per HTML and I have not seen them raise an issue about this yet.
(In reply to comment #3) > That it triggers quirks mode in IE is a bug in IE per HTML and I have not seen > them raise an issue about this yet. I note that you fall into a "between us vendors" paradigm. That <?xml version="1.0" ?> triggers quirks ine IE6, is also a bug: it is not founded on whether HTML4, XHTML1 or HTML5. But I have heard about no other justification - in public-html - for the prohibition than the IE6-bug. (I have, also, not heard that Microsoft wanted the XML declaration forbidden.) As for comments before DOCTYPE, then I will also point to HTML5's section on "Restrictions on content models and on attribute values" as the ultimate justification. http://dev.w3.org/html5/spec/introduction#restrictions-on-content-models-and-on-attribute-values That sections categorizes HTML5's restrictions into, amongst others, the following types of errors that seems relevant for evaluating whether comments before <!DOCTYPE html> should be permitted: * "Errors that involve peculiarities of the parser" [in truth, it is meant peculiarities in the HTML5 parser and not IE6, but some of those peculiarities stems from IE.] * "Errors that would likely result in scripts failing in hard-to-debug ways" [ fits well! ] * "Errors that waste authoring time" [ fits well! ] * "Errors that involve areas that affect authors migrating to and from XHTML" [ fits well! ] * "Errors that indicate a mis-use of other specifications" [conditional comments & x-ua-compatible is misue of proprietary syntax]
Seems like a no-brainer to prohibit this, given that it has no realistic benefit but will destroy your site in IE.
(In reply to comment #2) > Henri, any opinion on this? I could live with comments before doctype being a conformance error. (I'd be scared about actually changing mode selection though. I'd prefer IE getting fixed eventually.)
(In reply to comment #6) > (In reply to comment #2) > > Henri, any opinion on this? > > I could live with comments before doctype being a conformance error. (I'd be > scared about actually changing mode selection though. I'd prefer IE getting > fixed eventually.) The only news in IE9beta is quirksmode in 'application/xhtml+xml'! So for example if you place this in the <head> element, then it triggers quirksmode even in 'application/xhtml+xml': <meta http-equiv="X-UA-Compatible" content="IE=5"/> As does the following variants (perhaps the DOCTYPE is "invisible" to IE in 'application/xhtml+xml'?): <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE9" /> <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" /> <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" /> Whereas these does seemingly not trigger quirksmode (don't know what other effects it has): <meta http-equiv="X-UA-Compatible" content="IE=9" /> <meta http-equiv="X-UA-Compatible" content="IE=8" /> <meta http-equiv="X-UA-Compatible" content="IE=7" /> It seems that, in 'application/xhtml+xml', then <!--[if ie]> <meta http-equiv="X-UA-Compatible" content="IE=5" /> <![endif]--> before the DOCTYPE or between DOCTYPE and <html xmlns="http://www.w3.org/1999/xhtml" >, does not have any effect.
(In reply to comment #1) > An advantage which a forbidding of comments before the DOCTYPE provides, is > that it would largely kill off X-UA-COMPATIBLE meta elements from having any > effect in legal HTML5 syntax. I think you've got a misconception. The meta switch in IE does not need any Conditional Comments. I haven't actually seen this constellation of code before. So it could still influence most valid HTML documents. The X-UA-Compatible header is also used to activate the Chrome Frame, I don't know how that works if the switch was inside CCs. (In reply to comment #3) > That it triggers quirks mode in IE is a bug in IE per HTML and I have not seen > them raise an issue about this yet. Well, before HTML5 there was no definition, how can you blame Microsoft? Anyway, many people reported this before. I personally reported it relatively early in the IE9 development cycle, see (if you got an Connect account): https://connect.microsoft.com/IE/feedback/details/560821/ It's marked Won't Fix for IE9. (In reply to comment #6) > I could live with comments before doctype being a conformance error. (I'd be > scared about actually changing mode selection though. I'd prefer IE getting > fixed eventually.) The market share of IE is no longer 90%, so it should be considered that there is no such issue in Firefox, Opera or Safari/Chrome when a desicion is made. When the chips are down, simply include it in Acid 4. That helped with other issues before (text/plain). (In reply to comment #7) > The only news in IE9beta is quirksmode in 'application/xhtml+xml'! FYI, the Release Candidate of Internet Explorer 9 has been released. In IE9 RC, neither meta element nor HTTP headers can switch X(HT)ML documents into quirks mode. Only HTML documents created through XSLT are rendered in quirks mode if they do not contain a doctype (like in WebKit). In Firefox and Opera even those documents are rendered in no-quirks mode.
(In reply to comment #8) > (In reply to comment #1) > > An advantage which a forbidding of comments before the DOCTYPE provides, is > > that it would largely kill off X-UA-COMPATIBLE meta elements from having any > > effect in legal HTML5 syntax. > > I think you've got a misconception. The meta switch in IE does not need any > Conditional Comments. I said spoke about "legal HTML5 syntax". The meta X-UA-COMPATIBLE element is makes your document non-conforming to HTML5. Thus, in order to be conforming to the HTML5 syntax rules, it is necessary to wrap the X-UA-Compatible META element inside a conditional comment which you place before the DOCTYPE. To wrap the X-UA-COMPATIBLE inside a conditional comment inside <head> makes no sense: it doesn't work.
(In reply to comment #8) *** > (In reply to comment #7) > > The only news in IE9beta is quirksmode in 'application/xhtml+xml'! > > FYI, the Release Candidate of Internet Explorer 9 has been released. OK. I was simply using Adobe BrowserLab, and thought it was updated. But it probably isn't. > In IE9 RC, neither meta element nor HTTP headers can switch X(HT)ML documents > into quirks mode. OK. That was good to hear!
(In reply to comment #9) > Thus, in order to be conforming to the HTML5 syntax rules, it is necessary to > wrap the X-UA-Compatible META element inside a conditional comment which you > place before the DOCTYPE. Ah, I see, thanks. I even think I understand the reason behind. Though one could always use the HTTP header instead (for text/html). Just like Link.
(In reply to comment #8) >(In reply to comment #6) >The market share of IE is no longer 90%, so it should be considered that there >is no such issue in Firefox, Opera or Safari/Chrome when a desicion is made. Following that logic, there is even less reason to make the XML declaration non-conforming. (Bug 12073) >When the chips are down, simply include it in Acid 4. That helped with other >issues before (text/plain). It will anyhow affect legacy browsers, including IE9. ACID4 can check for correct behaviour even if <!----><!DOCTYPE html> becomes non-conforming.
(In reply to comment #12) > Following that logic, there is even less reason to make the XML declaration > non-conforming. (Bug 12073) Indeed. I don't see a reason to make it non-conforming at all. It's nothing more than yet another talisman like xmlns. Conformance checkers should probably inform about the talisman status though. > It will anyhow affect legacy browsers, including IE9. Let's face it: A lot of things defined by HTML5 affect any browsers from legacy to current generation. We're in the middle of defining the standard. You just have to break some things, else you'd either end up defining every quirk of every browser or forbidding every feature that has a buggy implementation in the wild.
(In reply to comment #13) > (In reply to comment #12) > > It will anyhow affect legacy browsers, including IE9. > > Let's face it: [...] forbidding every feature that has a buggy implementation in > the wild. * I'm familiar with "in the wild" about documents, but not about UAs * It is core to HTML5's design to not trigger quirks mode. * What do you mean by "feature" in this case? "<!---><!DOCTYPE html>" is not a feature! Feature: It is not "<!---><!DOCTYPE html>" in particular, but HTML comments in general, that has a buggy (read: proprietary) implementation in Internet Explorer. But HTML5 does still not forbid the comments feature ... ! IE's buggy/proprietary comments feature implementation is otherwise well documented and explaned - including by Microsoft themselves: "Everyone" knows about conditional comments, and the implementation is quite logical and simple to understand. But, in case of "<!---><!DOCTYPE html>" as well as "<!--[if ie]><![endif]--><!DOCTYPE html>", then IE's comments implementation has the unexpected and *undocumented* (undocumented by Microsoft) sideeffect [*] that it triggers quirks mode. That it can be avoided via "<!--[if !ie]><![endif]--><!DOCTYPE html>" as well as "<!--[if ie]><meta http-equiv="X-UA-Compatible" content="IE=Edge"><![endif]--><!DOCTYPE html>", only makes it even more confusing. But worse: it forces authors to use proprietary syntax in order to achive what HTML5 should be providing out of the box! And even worse: unless it is made non-conforming, it is also impossible to catch these parsing mode affecting sideffects in conformance checkers. It is not theoretical spec purity that favours forbidding comments before DOCTYPE. It is predictabilitiy for authors. That said: to forbid comments before the DOCTYPE, in many ways looks very natural: it means that conforming HTML gets a more "streamlined" look. Are there not any other arguments in favour of comments before DOCTYPE than spec purity? [*] sideffect: It has been pointed out that comments are partly stylable in IE.
(In reply to comment #14) > [] sideffect: It has been pointed out that comments are partly stylable in IE. Out of curiosity, could you provide a little more information? How would that work?
(In reply to comment #15) > (In reply to comment #14) > > [] sideffect: It has been pointed out that comments are partly stylable in IE. > > Out of curiosity, could you provide a little more information? How would that > work? OK. Let me dig up this old IE hack, then: http://www.malform.no/testing/iecomments/
As a secondary argument, one can also look at how Microsoft's proprietary conditional comments and x-ua-compatible directive (which also Google Chrome uses) are affected by comments before the DOCTYPE. And one will then find that: * conditional comments before DOCTYPE messes up IE's version vector system * x-ua-compatible can break when there is a comment before DOCTYPE Example 1: "normal" use of x-ua-compatible <!DOCTYPE html><html><head> <meta content="IE=7" http-equiv="x-ua-compatible" /><title></title></head><body> <![if ie 7]>IE7<![endif]><![if ie 8]>IE8<![endif]><![if ie 9]>IE9<![endif]></body></html> In above document, the X-UA-COMPATIBLE meta element is, as expected, inside the head element. Thus version vectors work as designed by Microsoft: both IE8 and IE9 will report that they are IE7. Example 2: messed up by conditioanl comments. <!--[if gt IE 7]><meta content="IE=7" http-equiv="x-ua-compatible" /><![endif]--> <!DOCTYPE html><html><head><title></title></head><body> <![if ie 7]>IE7<![endif]><![if ie 8]>IE8<![endif]><![if ie 9]>IE9<![endif]></html> In above document, IE8 and IE9 will change to IE7 modus. But despite changing modus, IE8 will identify tiself as IE8 and IE9 will identify itself as IE9. (This has something to do with the fact that the META element is moved inside the head element in the DOM.) Example 3: x-ua-compatible breaks because of comment <!----> <!DOCTYPE html><html><head> <meta content="IE=EmulateIE7" http-equiv="x-ua-compatible" /><title></title></head><body> <![if ie 7]>IE7<![endif]><![if ie 8]>IE8<![endif]><![if ie 9]>IE9<![endif]></html> The values 'EmulateIE7', 'EmulateIE8' and 'EmulateIE9' will tell, according to Microsoft, "Internet Explorer to use the <!DOCTYPE> directive to determine how to render content". Thus, authors should therefore expect that the above document would render in standards mode, due to the fact that it uses a standards triggering DOCTYPE. However, because of that comment before the DOCTYPE, the X-UA-COMPATIBLE directive actually fails to live up to its expectation. And the author furhter more gets confused.
(In reply to comment #14) > * I'm familiar with "in the wild" about documents, but not about UAs An UA is in the wild if it has been released to the public. > * It is core to HTML5's design to not trigger quirks mode. Comments do not contradict this core. One implementeation does, unfortunately. > * What do you mean by "feature" in this case? > "<!---><!DOCTYPE html>" is not a feature! Comments are a feature. > Feature: It is not "<!---><!DOCTYPE html>" in particular, but HTML > comments in general, that has a buggy (read: proprietary) implementation in > Internet Explorer. But HTML5 does still not forbid the comments feature ... ! I think that'd be the next step if we start to forbid comments in certain places. > But, in case of "<!---><!DOCTYPE html>" as well as "<!--[if > ie]><![endif]--><!DOCTYPE html>", then IE's comments implementation has the > unexpected and *undocumented* (undocumented by Microsoft) sideeffect [*] that > it triggers quirks mode. This bug is there, but it probably won't be there forever. > [*] sideffect: It has been pointed out that comments are partly stylable in IE. In quirks mode and standards mode up to IE7, but not IE8 nor IE9. This issue is not related to comments only, but to other "invisible" elements as well, e.g. noscript if scrits are enabled, input@type=hidden Other browsers also have bugs in their quirks mode that are partially undocumented. Besides, even if this case was forbidden, there'd still be an issue in IE that had to be fixed. > That it can be avoided via "<!--[if !ie]><![endif]--><!DOCTYPE html>" as > well as "<!--[if ie]><meta http-equiv="X-UA-Compatible" > content="IE=Edge"><![endif]--><!DOCTYPE html>", only makes it even more > confusing. But worse: it forces authors to use proprietary syntax in order to > achive what HTML5 should be providing out of the box! And even worse: unless > it is made non-conforming, it is also impossible to catch these parsing mode > affecting sideffects in conformance checkers. Assume IE didn't have this bug. Would you still want to forbid Comments before the doctype because the meta switch could be used there? HTML5 provides no-quirks mode out of the box, IE doesn't yet. Of course you're completely right when noting that an unwanted mode switch could be detected if comments were forbidden before the doctype. > It is not theoretical spec purity that favours forbidding comments before > DOCTYPE. It is predictabilitiy for authors. That said: to forbid comments > before the DOCTYPE, in many ways looks very natural: it means that conforming > HTML gets a more "streamlined" look. I'm afraid that there will be more and more cases where things like comments may look "out of place" and get forbidden to ensure a streamlined look.
(In reply to comment #18) > (In reply to comment #14) > This bug is there, but it probably won't be there forever. Above you said: "It's marked Won't Fix for IE9." > > [*] sideffect: It has been pointed out that comments are partly stylable in IE. > > In quirks mode and standards mode up to IE7, but not IE8 nor IE9. > > This issue is not related to comments only, but to other "invisible" elements > as well, e.g. noscript if scrits are enabled, input@type=hidden If IE looks at comments the same way it looks at <noscript>, then it is easy to see why <!----><!DOCTYPE html> brings even IE8/9 into quirks mode. (That <!----> is unstylable in IE8/9, might simply be due to a CSS implementation change rather than to a parsing change.) > Other browsers also have bugs in their quirks mode that are partially > undocumented. Other browsers are actually pretty complete in their quirks mode *trigger* documentation. Whereas the IE meta switch documentation is incomplete when it states that: [*] "Emulate IE[789] mode tells Internet Explorer to use the <!DOCTYPE> directive to determine how to render content". It should have added: "as long as there is no comment before the DOCTYPE". [*] http://msdn.microsoft.com/library/cc288325(v=vs.85).aspx#DCModes > Besides, even if this case was forbidden, there'd still be an > issue in IE that had to be fixed. Indeed: Forbidding <!---><!DOCTYPE wouldn't bless IE's behaviour. > Assume IE didn't have this bug. Would you still want to forbid Comments before > the doctype because the meta switch could be used there? Hypothetical! With many if's. Such as: if <!----><!DOCTYPE html> didn't trigger quirks mode, would the meta switch still have existed/been relevant? A more realistic question: would I have filed this bug even if IE8 and IE9 did not support the X-UA-COMPATIBLE switch? Of course I would. A question for you: Does the X-UA-COMPATIBLE meta switch mean that there is less reason to consider whether <!----><!DOCTYPE html> should be forbidden? > > It is not theoretical spec purity that favours forbidding comments before > > DOCTYPE. It is predictabilitiy for authors. That said: to forbid comments > > before the DOCTYPE, in many ways looks very natural: it means that conforming > > HTML gets a more "streamlined" look. > > I'm afraid that there will be more and more cases where things like comments > may look "out of place" and get forbidden to ensure a streamlined look. Through the concept "restrictions on the content model", HTML5 is able to discern between things that are forbidden for practical reasons and other kinds of forbiddance. Thus, if the practical reason for forbidding <!----><!DOCTYPE html> would disappear, then e.g. HTML6, could lift the ban.
(In reply to comment #19) > Above you said: "It's marked Won't Fix for IE9." That's no contradiction. The development is simply not analogous. > Other browsers are actually pretty complete in their quirks mode *trigger* > documentation. If you count bug reports, yes. In that case, IEs trigger documentation is also pretty complete. > Hypothetical! With many if's. Such as: if <!----><!DOCTYPE html> didn't > trigger quirks mode, would the meta switch still have existed/been relevant? Definite yes. There is no relation of the two problems (except the noted side effects). The meta switch is the author level tool Microsoft created so websites can opt in to any mode IE defines. In my opinion that switch should've been made available only to intranet users. But oh well, now we have to live with it in the wild. > A more realistic question: would I have filed this bug even if IE8 and IE9 did > not support the X-UA-COMPATIBLE switch? Of course I would. In that case you may want to file a bug that forbids XML declaration and doctype to be written spearately using document.write [1] Though, the fix will be shipped before HTML5 becomes a REC, which could or could not be tru for Microsoft's browser as well. > A question for you: Does the X-UA-COMPATIBLE meta switch mean that there is > less reason to consider whether <!----><!DOCTYPE html> should be forbidden? No, but in my opinion it does't mean that there is more reason to consider it either. > Through the concept "restrictions on the content model", HTML5 is able to > discern between things that are forbidden for practical reasons and other > kindsof forbiddance. Thus, if the practical reason for forbidding > <!----><!DOCTYPE html> would disappear, then e.g. HTML6, could lift the ban. I see, that makes sense. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=268442
(In reply to comment #20) > (In reply to comment #19) > > Hypothetical! With many if's. Such as: if <!----><!DOCTYPE html> didn't > > trigger quirks mode, would the meta switch still have existed/been relevant? > > Definite yes. There is no relation of the two problems (except the noted side > effects). The meta switch is the author level tool Microsoft created so > websites can opt in to any mode IE defines. Apart from desire to "be valid", one usecase that "X-UA-COMPATIBLE inside a conditional comment before the DOCTYPE" could support would be the - hypothetical - need to trigger different modes in different versions of IE. For example ... <!--[if ie]> <![if IE 7]><!--quirks--><![endif]> <![if IE 9]> <meta content="IE=8" http-equiv="x-ua-compatible"/> <![endif]> <![if IE 8]> <meta content="IE=7" http-equiv="x-ua-compatible"/> <![endif]> <![endif]--> <!DOCTYPE html> (I don't know if it has negative side effects - e.g. on the page load. Or whether there are other ways to achieve the same thing, for example via HTTP.) In contrast, the most *typical* use of X-UA-COMPATIBLE would probably be the opposite: rather that differentiation, make all versions of IE behave as IE7, for instance. That said: a content-model-restriction in HTML5 wouldn't hinder you from, validly, using this trick in HTML4 and XHTML1. > > Through the concept "restrictions on the content model", HTML5 is able to > > discern between things that are forbidden for practical reasons and other > > kindsof forbiddance. Thus, if the practical reason for forbidding > > <!----><!DOCTYPE html> would disappear, then e.g. HTML6, could lift the ban. > > I see, that makes sense. It is great if we are nearing the same standpoint!
(In reply to comment #21) > In contrast, the most *typical* use of X-UA-COMPATIBLE would probably be the > opposite: rather that differentiation, make all versions of IE behave as IE7, > for instance. In my experience that's the typical use case, yes. > That said: a content-model-restriction in HTML5 wouldn't hinder you from, > validly, using this trick in HTML4 and XHTML1. I want to use HTML5 and be valid. I also want my website to work across browsers, though. So I think that people will more likely ignore the restriction HTML5 puts on meta elements than using an Conditional Comment with a meta element before the doctype.
Any conditional comment before the DOCTYPE (regardless of its content) and (at least in IE8) any regular comment as well, will cause IE8 and (E9 to report "wrong" user agent. In other words, if you browse the following document with IE8: <!--[if ie]><![endif]--> <!DOCTYPE html> <meta http-equiv="x-ua-compatible" content="IE=7"> <!--[if ie 8>IE8<![endif]--><!--[if ie 7>IE7<![endif]--> Then IE8 - as well as IE9 - will report itself as IE8 and IE9 and not as IE7 - as the author intended. (The parser will still immitate IE7, but it will not report itself as being IE7.) In IE8's case, then even a normal coment seem to have the same effect: <!----> <!DOCTYPE html> <meta http-equiv="x-ua-compatible" content="IE=7"> <!--[if ie 8>IE8<![endif]--><!--[if ie 7>IE7<![endif]-->
This would be easy enough to do; add a "parse error" to the "comment" entry of "the initial insertion mode", and remove "comments" from the syntax of a document before the doctype. The main argument in favour of this change is weird parsing behaviour in old legacy UAs. I'm not sure that's a very compelling argument. The other arguments presented above are even less compelling. On the other hand, there really aren't any good arguments to allow comments there at all. So the question really is whether the minor additional implementation burden on existing parser implementations that do syntax validation is worth it.
(In reply to comment #24) > So the question really is whether the minor additional implementation > burden on existing parser implementations that do syntax validation is worth it. Instead of an error message, how about simply issueing some kind of warning in validators, so that: [*] ]] authors who are validating their documents are less likely to waste time with this kind of mistake [[ [*] http://dev.w3.org/html5/spec/introduction#restrictions-on-content-models-and-on-attribute-values
*** Bug 12648 has been marked as a duplicate of this bug. ***
(In reply to comment #25) > > Instead of an error message, how about simply issueing some kind of warning in > validators Conformance checkers are allowed to give any warnings they like. Nothing is stopping them. That they haven't is almost an argument against doing this, as it indicates that it is not an important problem in their eyes.
Not a very strong argument, since as far as I know, there's exactly one HTML5 validator and it mostly just does what the spec says. The idea of a real validator ecosystem where multiple validators will compete on utility for authors is a nice theory, but it hasn't actually worked out. Having the spec require warnings seems like the appropriate way to handle these things for the foreseeable futures. Particularly since it requires errors or warnings in so many cases already for things that just might confuse authors or cause subtle problems.
(In reply to comment #27) > Conformance checkers are allowed to give any warnings they like. Nothing is > stopping them. You almost suggest it yourself: how about adding in the spec that conformance checkers are **recommended to warn** against comments before the DOCTYPE? Then we leave it to what they are free to do - nothing is stopping them from not warning, if they don't want to.
(In reply to comment #28) > Not a very strong argument, since as far as I know, there's exactly one HTML5 > validator [...] +1 With HTML5, the purpose of the DOCTYPE is changing. Left is only the DOCTYPE's mode effects. Before HTML5, however, the mode effect was just a side effect. This can be seen from the fact that the quirks-mode variant (that is: the one without URI) of the HTML4 transitional DOCTYPE, validates, without any warning whatsoever, in the W3 Validator. So, we really cannot make anything from the fact that HTML4 and XHTML1.x validators (the W3 validator is the dominating one) did not warn against comments before the DOCTYPE as the DOCTYPE itself could trigger quirks mode - and still validate.
I'll get a warning added. BTW, if the validator doesn't do something, you shouldn't assume that Mike or I have thought about it deeply and knowingly decided not to do anything.
(In reply to comment #31) > I'll get a warning added. Validator.nu currently states: ]] Warning: Comments seen before doctype. Internet Explorer will go into the quirks mode. [[ However, the above warning is not 100% correct, as it dpeneds on the format of the comment whether it brings IE in quirks-mode or not. See: http://bugzilla.validator.nu/show_bug.cgi?id=836 With regard to what HTML5 should say:: if comments before the DOCTYPE were illegal, then validators could present a more unambigious error message. But on the other side: it might be better if authors familiarize themselves with the IE problems.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: There are pages with comments at the top before a DOCTYPE and fixing that doesn't seem like a particularly high priority that we should call authors out on. It's not a strong argument, but the arguments in the other direction seem even less compelling.
mass-moved component to LC1
OK. The issue have been duly considered. I accept the won't fix and close it.