This is extracted from an email exchange on <firstname.lastname@example.org> 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).
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".
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?
Correct: pages with an unknown DTD should be in strict mode, pages without a DTD should be in quirks mode.
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.
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
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.
This was already discussed in n.p.m.layout; 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. 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: <38FD013A.CE7FF87B@netscape.com>  Sivonen, Henri. "Re: DTD doctype detection rules", n.p.m.layout 19 Apr 2000 08:46:16 GMT. message-id: <henris-077EBB.email@example.com>  Sivonen, Henri. "Re: DTD doctype detection rules", n.p.m.layout 20 Apr 2000 11:01:41 GMT. message-id: <henris-0EE405.firstname.lastname@example.org> 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: <henris-0F037B.email@example.com> ------------ 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.
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?
Putting on [nsbeta2+] radar.
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.
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
Re-assigning to harishd.
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-.
Nominating for beta3.
fig\tree: What you are suggesting is bug 44525, which has been resolved WONTFIX.
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.
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.
Strict DTD will not be supported for netscape 6.0. Marking beta3-.
Clearing nsbeta3- again. This affects layout mode too, which is not out.
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 ***
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?
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.