43274 - Documents with unknown DTDs should trigger stict mode in layout

Status: VERIFIED DUPLICATE of bug 42525

(Core :: DOM: HTML Parser, defect, P2)

Description

[Pierre Saslawsky]

This is extracted from an email exchange on <[e-mail]> between Matthew 
Brealey and Todd Fahrner (a copy of the message is available in the archive at
http://lists.w3.org/Archives/Public/www-style/2000Jun/0032.html).

---
>But then anyone using a new DTD, such as that of the new ISO/IEC
>standard, which is just about the strictest DTD around, will find their
>ultra-strict page will be rendered in quirks mode because the browser
>was released before the dtd.

Again: not so in MacIE5. I don't know the latest turn of the wind 
about Mozilla's policy here, but I and several others have argued 
strenuously in the past that all unknown HTML document types must 
trigger strict mode, as in MacIE5. In other words, strict should be 
the default in Mozilla. If what you assert is true, please speak up 
in the appropriate Mozilla forums.
----

I'm going to attach a testcase with the DTD used by Todd's company on all their 
customers' sites (such as http://www.motorola.com). As you can see, the page is 
displayed in quirks mode in Mozilla (that's bad) and in strict mode in MacIE5 
(that's good).

Comment 1

[Pierre Saslawsky]

Attachment: testcase

Comment 2

[rickg]

If I understand the bug report correctly, we're being asked to render pages 
without a doctype in strict mode. Do do so would break the VAST MAJORITY of 
pages on the web, that lack a doctype and expect to be rendered, "like they 
always have". 

Comment 3

[rickg]

Pierre, in reading the testcase, it seems you're actually not arguing the case 
for pages without a doctype, but rather, pages with an unknown doctype. Is this 
correct?

Comment 4

[Pierre Saslawsky]

Correct: pages with an unknown DTD should be in strict mode, pages without a DTD 
should be in quirks mode.

Comment 5

[rickg]

I'd have to argue that the rule needs to be modified. If the HTML version is 
clearly apparent, and less than 4.0, we should be in quirks mode since it's 
likely to have preceeded the strict DTD's.

Comment 6

[Pierre Saslawsky]

I totally agree with that too, sorry for not having been more explicit up front:
        no DTD:              quirks
        DTD HTML 1.0 to 3.0: quirks
        DTD HTML 4.0+:       strict
        other DTDs:          strict

Comment 7

[Karl Ove Hufthammer]

Some authoring tools (Netscape 4.x, I think) generate documents with HTML 4.0 Transitional DTD, and these need to be rendered in quirks mode too. So, I think HTML 4.0 Transitional and Frameset should be rendered in quirks, HTML 4.0 Strict in strict and HTML *4.01* Transitional, Frameset and Strict in strict mode.

Comment 8

[fantasai]

This was already discussed in n.p.m.layout[1]; AFAIK, it should be working that 
way, since the general consensus was for unknown doctypes to be rendered in 
standard mode.

As for HTML4 transitional doctypes, Henri Sivonen also proposed that all 
transitional doctypes with a URI be rendered in standard, and all transitional 
doctypes without one be rendered in quirks mode.[2] There are various comments 
dealing with that issue in bug 31933, but I don't know what the consensus is.

A lot of all this has already been discussed in the newsgroup--just never put 
into the "official" list of detection rules (AFAIK).

IMO, the current set of rules should be summarized and resubmitted for 
discussion, as this is a very important issue.

------------

The first post in the thread is 
   Gessner, Rick. "DTD doctype detection rules", netscape.public.mozilla.layout
     18 Apr 2000 17:43:38 -0700.
     message-id: <[e-mail]>

[1] Sivonen, Henri. "Re: DTD doctype detection rules", n.p.m.layout
      19 Apr 2000 08:46:16 GMT.
      message-id: <[e-mail]>
[2] Sivonen, Henri. "Re: DTD doctype detection rules", n.p.m.layout
      20 Apr 2000 11:01:41 GMT.
      message-id: <[e-mail]>

See also Henri's summary:
    Sivonen, Henri. "Re: DTD doctype detection rules", n.p.m.layout
      19 Apr 2000 13:43:33 GMT.
      message-id: <[e-mail]>

------------

Henri, I've CCed you; since I've referenced so many of your posts, I thought
you might be interested. Please pardon me if that's not the case.

------------

This bug is closely related to bug 1312, but don't mark it as a duplicate.

Comment 9

[Henri Sivonen (:hsivonen)]

>Henri, I've CCed you

Thanks.

For discussion about the quirkiness of HTML 4 Transitional, see comments in bug 34476 
and bug 42525.

Comment 10

[rickg]

PDT, please allow this (it's the same fix as the other bug I've recommended) so 
that we can put these issues behind us now. Pretty please?

Comment 11

[leger]

Putting on [nsbeta2+] radar.

Comment 12

[Bernd Mielke]

The changes from 2000-06-29 will cause a plenty of bug reports like bug 44395
and bug 44463. These documents have the following doctype
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
and contain html errors. Mozilla does not switch back to the compatibility mode
under these conditions.

Comment 13

[harishd]

Marking FIXED.

Comment 14

[Jan Carpenter]

Not fixed, judging by the testcase provided.
2000-07-06-09-M17 - WinNT
2000-07-06-08-M17 - Mac
2000-07-06-08-M17 - Linux

Reopening bug

Comment 15

[leger]

Re-assigning to harishd.

Comment 16

[Nisheeth Ranjan]

Just spoke to Harish.  He will attach the fix to this bug report and check it in  
for beta 3.  This bug isn't something we would pull beta 2 off the wire for and 
so it is getting marked nsbeta2-.

Comment 17

[harishd]

Attachment: Proposed patch...

Comment 18

[harishd]

Nominating for beta3.

Comment 19

[fig\tree]

I see some feasible solutions to this madness:

first the feature in bug 6211 should get implemented.

second, there should be a popup warning on the first visit to a 4.0
transitional  page with errors, very much like the security warning when
entering a secure site or "javascript errors" dialog IE used to present to
users. The user then should have the option of "Always render this site in
quirks mode" (not in that exact wording of course), which adds it to a list of
"bad sites" that moz will always render-transitional-in-quirks-mode. Of course
there should be a UI to manage that list also.

the typical reaction of a user (the mass market is what we are trying to target
isn't it?) when they see a page in moz that misrenders due to transitional
doctype non-conformance is NOT "hey this website sucks" but "hey mozilla sucks
cause this page works fine in NS4x and IE"

This problem is bigger than it seems because various popular webpage editing
tools default to transitional and then don't conform to it. these "broken" tools
are used by people who really don't care about doctypes.

I really think the rendering behavior for 4.0 transitional will be one of those
make-or-break issues for Mozilla.

Comment 20

[Matthew T (active 1999-2002)]

fig\tree: What you are suggesting is bug 44525, which has been resolved WONTFIX.

Comment 21

[Nisheeth Ranjan]

Marking nsbeta3+...

Comment 22

[Nisheeth Ranjan]

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration, but do not clear 
the nsbeta3- nomination.

Comment 23

[Matthew T (active 1999-2002)]

Please, no. Renominating. This is a must-have for RTM, otherwise Mozilla 5.0 (and 
Netscape 6.0) will be actively *penalizing* future Web authors for using
up-to-date standards (standards produced after this browser is released), by 
rendering them in Quirks mode. And that would be absurd.

And we already have a patch, so it's not as if this is going to require days of 
work.

Comment 24

[harishd]

Strict DTD will not be supported for netscape 6.0. Marking beta3-.

Comment 25

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Clearing nsbeta3- again.  This affects layout mode too, which is not out.

Comment 26

[harishd]

I understand that David.  The issue will be covered in bug 42525.
Okay, I'm going to change the summary and mark this bug a dupe ( though it's 
not identical )of bug 42525.

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

Comment 27

[Matthew T (active 1999-2002)]

If layout is being covered in bug 42525, then perhaps this bug can be reopened, 
nsbeta3-ed, and used to track future use of StrictDTD in parsing rather than 
layout?

Comment 28

[Henri Sivonen (:hsivonen)]

StrictDTD is going to be removed from the build.

Also, it is not a good idea to attempt validating unkown doctypes against a hard-coded 
DTD.

Comment 29

[Jan Carpenter]

verified