The default bug view has changed. See this FAQ.

Documents with unknown DTDs should trigger stict mode in layout

VERIFIED DUPLICATE of bug 42525

Status

()

Core
HTML: Parser
P2
critical
VERIFIED DUPLICATE of bug 42525
17 years ago
17 years ago

People

(Reporter: Pierre Saslawsky, Assigned: harishd)

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2-])

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
This is extracted from an email exchange on <www-style@w3.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).
(Reporter)

Comment 1

17 years ago
Created attachment 10445 [details]
testcase
(Reporter)

Updated

17 years ago
Severity: normal → critical
Keywords: nsbeta3
OS: Mac System 8.5 → All
Priority: P3 → P2
Hardware: Macintosh → All

Comment 2

17 years ago
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

17 years ago
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?
(Reporter)

Comment 4

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

Comment 5

17 years ago
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.
(Reporter)

Comment 6

17 years ago
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

17 years ago
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

17 years ago
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: <38FD013A.CE7FF87B@netscape.com>

[1] Sivonen, Henri. "Re: DTD doctype detection rules", n.p.m.layout
      19 Apr 2000 08:46:16 GMT.
      message-id: <henris-077EBB.11512419042000@uutiset.saunalahti.fi>
[2] Sivonen, Henri. "Re: DTD doctype detection rules", n.p.m.layout
      20 Apr 2000 11:01:41 GMT.
      message-id: <henris-0EE405.14065220042000@uutiset.saunalahti.fi>

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.16484019042000@uutiset.saunalahti.fi>

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

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

Thanks.

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

Comment 10

17 years ago
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?
Status: NEW → ASSIGNED
Keywords: nsbeta3 → nsbeta2
Whiteboard: fix in hand

Comment 11

17 years ago
Putting on [nsbeta2+] radar.
Whiteboard: fix in hand → [nsbeta2+]fix in hand
Blocks: 34662

Comment 12

17 years ago
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.
(Assignee)

Comment 13

17 years ago
Marking FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 14

17 years ago
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 15

17 years ago
Re-assigning to harishd.
Assignee: rickg → harishd
Status: REOPENED → NEW
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Whiteboard: [nsbeta2+]fix in hand → [nsbeta2+]fix in hand, 07/12/00 EDF

Comment 16

17 years ago
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-.
Whiteboard: [nsbeta2+]fix in hand, 07/12/00 EDF → [nsbeta2-]fix in hand, 07/12/00 EDF
(Assignee)

Comment 17

17 years ago
Created attachment 11258 [details] [diff] [review]
Proposed patch...
(Assignee)

Comment 18

17 years ago
Nominating for beta3.
Keywords: nsbeta3
(Assignee)

Updated

17 years ago
Target Milestone: --- → M18

Comment 19

17 years ago
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

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

Comment 21

17 years ago
Marking nsbeta3+...
Whiteboard: [nsbeta2-]fix in hand, 07/12/00 EDF → [nsbeta2-][nsbeta3+]fix in hand, 07/12/00 EDF

Comment 22

17 years ago
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.
Whiteboard: [nsbeta2-][nsbeta3+]fix in hand, 07/12/00 EDF → [nsbeta2-][nsbeta3-]
Target Milestone: M18 → Future

Comment 23

17 years ago
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.
Keywords: patch, rtm
Whiteboard: [nsbeta2-][nsbeta3-] → [nsbeta2-]
(Assignee)

Comment 24

17 years ago
Strict DTD will not be supported for netscape 6.0. Marking beta3-.
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
Clearing nsbeta3- again.  This affects layout mode too, which is not out.
Whiteboard: [nsbeta2-][nsbeta3-] → [nsbeta2-]
(Assignee)

Comment 26

17 years ago
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 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → DUPLICATE
Summary: Documents with unknown DTDs should be displayed in strict mode → Documents with unknown DTDs should trigger stict mode in layout

Comment 27

17 years ago
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.

Comment 29

17 years ago
verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.