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 9052 - All DOCTYPE variants that trigger standards mode pre-HTML5 should continue to trigger standards mode in HTML5
Summary: All DOCTYPE variants that trigger standards mode pre-HTML5 should continue to...
Status: VERIFIED DUPLICATE of bug 9071
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.xn--mlform-iua.no/html4-or...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-17 14:11 UTC by Leif Halvard Silli
Modified: 2010-10-22 10:21 UTC (History)
7 users (show)

See Also:

Attachments

Description Leif Halvard Silli 2010-02-17 14:11:20 UTC 
This variant of the HTML4 strict DOCTYPE,

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 
[<!ATTLIST P myattr   CDATA #implied >]>

triggers Strict parsing in pre-HTML5 browsers.

But in Opera 10.5beta, Minefield and Safari 4 it has started to trigger QuirksMode.

According to Lachlan, this is in line with HTML5: 
http://www.w3.org/mid/4B7BB225.9050908@lachy.id.au

According to Maciej it is not in line with HTML5: 
http://www.w3.org/mid/685C7306-C689-4A04-8987-05670EF3B053@apple.com

This bug requester thinks that it should be made clear that it is not in line with HTML5. The spec must eventually change so it is clear that it doesn't trigger QuirksMode.
Comment 1 Leif Halvard Silli 2010-02-17 14:12:50 UTC 
Corrected the example URL
Comment 2 Leif Halvard Silli 2010-02-18 08:58:15 UTC 
Minefield: I trusted Lachlan when I said that Mozila Minefield (Firefox 3.7a2pre)  behaves like Opera 10.5beta.

My own testing, however, showed that Minefield behaves like Firefox 3.6.
Comment 3 Leif Halvard Silli 2010-02-18 09:37:08 UTC 
Philip T. pointed out that HTML5 does require Standards Mode whenever the doctype contains a URL/System Identifier - provided that the internal DTD subset section (in my example: "[<!ATTLIST P myattr   CDATA #implied >]") comes *after* the System Identifier.

http://www.w3.org/mid/4B7C03BA.4050903@cam.ac.uk

As the draft says: 

"Anything else
    Parse error. Switch to the bogus DOCTYPE state. (This does not set the DOCTYPE token's force-quirks flag to on.)"
http://dev.w3.org/html5/spec/Overview.html#before-doctype-system-identifier-state 

And, sure enough, Opera 10.5 Beta behaves exactly that way, as can be verified in my Take 2 of the test 

http://www. xn--mlform-iua.no/html4-or-html5/take2

So does this mean that this bug is solved? No. I agree with the view of Boris Z: «going from treating a doctype as standards to treating a doctype as quirks seems like a bad idea to me»

http://www.w3.org/mid/4B7C0A50.305@mit.edu

On what basis can HTML5 say that this or that DOCTYPE should trigger QuirksMode if it now triggers StandardsMode? Can it be a goal to punish authors for using even a non-standard doctype? Or even to reward them with a method for triggering QuirksMode?

In my view, no. If we consider that QuirksMode has any benefit, then we should even define a specific HTML5 doctype that would trigger QuirksMode, so that authors could author a page according to HTML5 syntax rules and still get QuirksMode. (After all, HTML5 defines standards mode as the default.)

Remedy: 

To fix this bug, the section about "Parsing HTML documents" must be refined so that *only* those doctypes and doctype patterns that are _known_ to cause QuirksMode, will cause QuirksMode. As an exampe, all the HTML4 doctypes that W3 has produced and which are known to not cause QuirksMode, must continue to not cause quirks mode, even if they contain a internal DTD subset (or DOCTYPE comments or any other "stuff" that currently doesn't cause QuirksMode.)
Comment 4 Ian 'Hixie' Hickson 2010-02-25 02:42:55 UTC 
I'm marking this as a dupe of later bug 9071, because bug 9071 has data. Please feel free to reopen this bug if you think it is a separate issue.

*** This bug has been marked as a duplicate of bug 9071 ***