Bug 17722

Summary: HTML5 spec violation: </><!doctype html> or </x><!doctype html> SHOULD NOT imply standards mode
Product: WebKit Reporter: Robert Blaut <webkit>
Component: DOMAssignee: Adam Barth <abarth>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, annevk, commit-queue, eric
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
Patch none

Robert Blaut
Reported 2008-03-08 03:29:39 PST
The code: </><!doctype html> or </x><!doctype html> makes Webkit to render page in standards mode (CSS1Compat). According to HTML5 spec: "Documents must consist of the following parts, in the given order: 1. Optionally, a single U+FEFF BYTE ORDER MARK (BOM) character. 2. Any number of comments and space characters. 3. A DOCTYPE." Only BOM, comments and space characters are allowed before DOCTYPE. Steps to reproduce: 1) Go to a page: http://software.hixie.ch/utilities/js/live-dom-viewer/?%20%3C%2F%3E%3C!doctype%20html%3E%0A and notice "CSS1Compat" in log section. Expected result: BackCompat in log section Current result: CSS1Compat in log section
Attachments
Patch (2.64 KB, patch)
2010-09-13 17:38 PDT, Adam Barth 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Adam Barth
Comment 1 2010-08-05 10:17:43 PDT
The spec mandates that we render this document standards mode. Our current behavior is correct.
Anne van Kesteren
Comment 2 2010-08-05 23:24:12 PDT
As far as I can tell anything but whitespace, comments, and DOCTYPEs throws you out of the "initial" insertion mode and puts the document in standards mode so if this bug still applies with the new parser there is a bug. (And a lack of tests :/)
Anne van Kesteren
Comment 3 2010-08-05 23:24:53 PDT
I meant to say puts the document in quirks mode. Argh.
Adam Barth
Comment 4 2010-08-05 23:33:24 PDT
Ok. I'll take another look.
Adam Barth
Comment 5 2010-09-13 16:59:09 PDT
Looking now.
Adam Barth
Comment 6 2010-09-13 17:32:16 PDT
Looks like our behavior is correct. Adding tests.
Adam Barth
Comment 7 2010-09-13 17:38:03 PDT
Created attachment 67494 [details] Patch
Eric Seidel (no email)
Comment 8 2010-09-13 18:08:12 PDT
Comment on attachment 67494 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=67494&action=prettypatch Better to have it say PASS or FAIL, but this is OK.
Adam Barth
Comment 9 2010-09-14 11:45:28 PDT
PASS/FAIL tests are hard to change latter if we're intentionally changing behavior.
WebKit Commit Bot
Comment 10 2010-09-14 12:24:15 PDT
Comment on attachment 67494 [details] Patch Clearing flags on attachment: 67494 Committed r67484: <http://trac.webkit.org/changeset/67484>
WebKit Commit Bot
Comment 11 2010-09-14 12:24:20 PDT
All reviewed patches have been landed. Closing bug.
Robert Blaut
Comment 12 2010-09-14 22:36:15 PDT
(In reply to comment #6) > Looks like our behavior is correct. Adding tests. Adam, could you explain why the current behavior is correct?
Adam Barth
Comment 13 2010-09-15 00:32:54 PDT
> Adam, could you explain why the current behavior is correct? Sure. </x><!doctype html> This case generates a close tag token for the </x>, which kicks us out of the initial model, so the doctype doesn't trigger standards mode. Hence, quirks. </><!doctype html> or This case doesn't generate any token for </>. It just gets eaten by the tokenizer. That means the first token we see is the doctype, which triggers standards mode. Hence, standards.
Robert Blaut
Comment 14 2010-09-16 01:41:36 PDT
(In reply to comment #13) > </><!doctype html> or > > This case doesn't generate any token for </>. It just gets eaten by the tokenizer. That means the first token we see is the doctype, which triggers standards mode. Hence, standards. Is it correct behavior according HTML5 specification [http://www.w3.org/TR/html5/syntax.html#writing]?
Adam Barth
Comment 15 2010-09-16 02:05:27 PDT
> Is it correct behavior according HTML5 specification [http://www.w3.org/TR/html5/syntax.html#writing]? Yes. Notice the first sentence of that section: [[ This section only applies to documents, authoring tools, and markup generators. In particular, it does not apply to conformance checkers; conformance checkers must use the requirements given in the next section ("parsing HTML documents"). ]]
Note You need to log in before you can comment on or make changes to this bug.