Last Comment Bug 43274 - Documents with unknown DTDs should trigger stict mode in layout
: Documents with unknown DTDs should trigger stict mode in layout
Status: VERIFIED DUPLICATE of bug 42525
Product: Core
Classification: Components
Component: HTML: Parser (show other bugs)
: Trunk
: All All
P2 critical (vote)
: Future
Assigned To: harishd
: Jan Carpenter
: Andrew Overholt [:overholt]
Depends on:
Blocks: 34662
  Show dependency treegraph
Reported: 2000-06-20 23:51 PDT by Pierre Saslawsky
Modified: 2000-09-05 14:47 PDT (History)
10 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testcase (565 bytes, text/html)
2000-06-20 23:51 PDT, Pierre Saslawsky
no flags Details
Proposed patch... (8.21 KB, patch)
2000-07-11 14:15 PDT, harishd
no flags Details | Diff | Splinter Review

Description User image Pierre Saslawsky 2000-06-20 23:51:03 PDT
This is extracted from an email exchange on <> 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 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 User image Pierre Saslawsky 2000-06-20 23:51:48 PDT
Created attachment 10445 [details]
Comment 2 User image rickg 2000-06-20 23:56:10 PDT
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 User image rickg 2000-06-20 23:59:22 PDT
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 
Comment 4 User image Pierre Saslawsky 2000-06-21 00:05:16 PDT
Correct: pages with an unknown DTD should be in strict mode, pages without a DTD 
should be in quirks mode.
Comment 5 User image rickg 2000-06-21 00:23:59 PDT
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 User image Pierre Saslawsky 2000-06-21 01:28:48 PDT
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 User image Karl Ove Hufthammer 2000-06-21 03:49:49 PDT
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 User image fantasai 2000-06-21 08:31:59 PDT
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: <>

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

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: <>


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 User image Henri Sivonen (:hsivonen) 2000-06-21 09:30:15 PDT
>Henri, I've CCed you


For discussion about the quirkiness of HTML 4 Transitional, see comments in bug 34476 
and bug 42525.
Comment 10 User image rickg 2000-06-26 15:19:58 PDT
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 User image leger 2000-06-26 16:48:26 PDT
Putting on [nsbeta2+] radar.
Comment 12 User image Bernd Mielke 2000-07-03 11:05:15 PDT
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.
Comment 13 User image harishd 2000-07-04 09:39:50 PDT
Marking FIXED.
Comment 14 User image Jan Carpenter 2000-07-06 16:06:49 PDT
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 User image leger 2000-07-07 08:36:04 PDT
Re-assigning to harishd.
Comment 16 User image Nisheeth Ranjan 2000-07-11 13:50:30 PDT
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 User image harishd 2000-07-11 14:15:55 PDT
Created attachment 11258 [details] [diff] [review]
Proposed patch...
Comment 18 User image harishd 2000-07-11 14:16:51 PDT
Nominating for beta3.
Comment 19 User image fig\tree 2000-07-20 20:06:19 PDT
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 User image Matthew Paul Thomas 2000-07-21 00:57:19 PDT
fig\tree: What you are suggesting is bug 44525, which has been resolved WONTFIX.
Comment 21 User image Nisheeth Ranjan 2000-08-04 11:55:35 PDT
Marking nsbeta3+...
Comment 22 User image Nisheeth Ranjan 2000-08-14 16:40:20 PDT
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 User image Matthew Paul Thomas 2000-08-14 22:56:59 PDT
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 
Comment 24 User image harishd 2000-08-21 15:46:17 PDT
Strict DTD will not be supported for netscape 6.0. Marking beta3-.
Comment 25 User image David Baron :dbaron: ⌚️UTC-8 2000-08-21 15:57:58 PDT
Clearing nsbeta3- again.  This affects layout mode too, which is not out.
Comment 26 User image harishd 2000-08-21 16:37:31 PDT
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 User image Matthew Paul Thomas 2000-08-24 01:40:30 PDT
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 
Comment 28 User image Henri Sivonen (:hsivonen) 2000-08-24 04:46:00 PDT
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 
Comment 29 User image Jan Carpenter 2000-09-05 14:47:48 PDT

Note You need to log in before you can comment on or make changes to this bug.