This is extracted from an email exchange on <email@example.com> between Matthew
Brealey and Todd Fahrner (a copy of the message is available in the archive at
>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
Created attachment 10445 [details]
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
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: 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
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.
 Sivonen, Henri. "Re: DTD doctype detection rules", n.p.m.layout
19 Apr 2000 08:46:16 GMT.
 Sivonen, Henri. "Re: DTD doctype detection rules", n.p.m.layout
20 Apr 2000 11:01:41 GMT.
See also Henri's summary:
Sivonen, Henri. "Re: DTD doctype detection rules", n.p.m.layout
19 Apr 2000 13:43:33 GMT.
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.
>Henri, I've CCed you
For discussion about the quirkiness of HTML 4 Transitional, see comments in bug 34476
and bug 42525.
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"
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
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-.
Created attachment 11258 [details] [diff] [review]
Nominating for beta3.
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
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.
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
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
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