This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25233 - Specify that "Optionally, a DOCTYPE” means that quirky doctypes must be ignored
Summary: Specify that "Optionally, a DOCTYPE” means that quirky doctypes must be ignored
Status: RESOLVED MOVED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC All
: P2 editorial
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: HTML WG Bugzilla archive list
URL: http://www.w3.org/html/wg/drafts/html...
Whiteboard: whatwg-resolved
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-02 16:34 UTC by Leif Halvard Silli
Modified: 2016-07-06 20:52 UTC (History)
5 users (show)

See Also:


Attachments

Description Leif Halvard Silli 2014-04-02 16:34:45 UTC
This issue is related to bug 25232.

SITUATION: 

For docs inside @srcdoc, spec says that the DOCTYPE is optional:
http://www.w3.org/html/wg/drafts/html/master/single-page.html#attr-iframe-srcdoc
Thus, DOCTYPE is not required for @srcdoc documents.

But what should the parser do if there is a *quirky* DOCTYPE inside the @srcdoc? Should it ignore the DOCTYPE? Or should it render the document in quirks mode?

PROPOSAL:

We should take same attitude to this as we have taken to UTF-8. Thus, qurks mode should *not* be spread to new contexts. Therefore, spec should point out that "Optionally, a DOCTYPE" means that the DOCTYPE is to be ignored and thus, that the iframe document is to be rendered in no-quirks mode.

IMPLEMENTATIONS:

* Firefox implements the proposed behavior
* Webkit and Blink (at least current release of Safari and Chrome) places the docuent in no-quirks mode if the DOCTYPE is lacking. However, if there is a quirky doctype, then they put the document in quirks mode.
Comment 1 Travis Leithead [MSFT] 2016-04-25 18:17:33 UTC
HTML5.1 Bugzilla Bug Triage: Moved to https://github.com/w3c/html/issues/254

If this resolution is not satisfactory, please copy the relevant bug details/proposal into a new issue at the W3C HTML5 Issue tracker: https://github.com/w3c/html/issues/new where it will be re-triaged. Thanks!
Comment 2 Simon Pieters 2016-07-06 20:52:50 UTC
https://bugs.webkit.org/show_bug.cgi?id=159489

(Chromium now seems to get this right.)