HTML 4.0 Strict do not trigger standard mode

VERIFIED FIXED in M16

Status

()

defect
P3
normal
VERIFIED FIXED
20 years ago
18 years ago

People

(Reporter: emk, Assigned: rickg)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: (Compatability mode detection))

Attachments

(4 attachments)

Reporter

Description

20 years ago
Steps to reproduce:
1. Launch Mozilla.
2. Navigate to the following attachment.

Actual result:
The following FPI erroneously trigger the standard mode:
   <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Strict//EN"> --- (1)

The following FPI erroneously trigger the quirks mode:
   <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> ---(2)

Expected result:
Case (1) should trigger the quirks mode since it is an invalid doctype.
Case (2) should not trigger the quirks mode sinse it is a strict doctype.

This is a simple fact, not an opinion.

I have opened this bug since bug 1312 closed.
I'm using 2000022619 nightly build on Windows 2000.
Nominating for beta1.  This shouldn't be backwards in the beta.
Keywords: beta1
Assignee

Comment 5

20 years ago
marking PDT-, since it's not essential for beta.
Whiteboard: [PDT-]
Surely this is something that web developers need to have early warning about. 
Not doing this for beta 1 is inviting alienation.
Should at least be relnoted for beta1 that this will change in future.
Reporter

Comment 9

20 years ago
I want to fix this ASAP since this prevents to test the all mode related bug.
Standard mode testcase is broken now.
Reporter

Comment 10

20 years ago
ISO doctypes are now:
<!DOCTYPE HTML PUBLIC "ISO/IEC 15445:2000//DTD HyperText Markup Language//EN">
<!DOCTYPE HTML PUBLIC "ISO/IEC 15445:2000//DTD HTML//EN">

Comment 11

19 years ago
adding beta2 keyword, and removing pdt status
Keywords: beta2
Whiteboard: [PDT-]

Comment 12

19 years ago
removing beta1 keyword so it doesn't show up on beta1 radar
Keywords: beta1
Whiteboard: (Compatability mode detection)
Blocks: 34662
Reporter

Updated

19 years ago
Blocks: 26857
Assignee

Comment 13

19 years ago
Ok -- I agree that the first one should not be interpreted as standard; the 
second one however is arguably non-strict. I'll do at least the first one for 
beta2 -- but I can't promise that the strictDTD will be fully operational by 
then (I seriously doubt it).
Status: NEW → ASSIGNED
Target Milestone: --- → M16
Why should HTML 4.0 strict cause quirks mode?  It's been strict mode all along,
and that hasn't seemed to cause any problems.  (And isn't it just a one or two
line fix anyway...?)
Reporter

Comment 15

19 years ago
>Ok -- I agree that the first one should not be interpreted as standard; the
>second one however is arguably non-strict. 

The second one *is* definitely a strictDTD.
Have you ever seen the HTML 4.0 Spec.?
( http://www.w3.org/TR/1998/REC-html40-19980424/struct/global.html#h-7.2 )
|The HTML 4.0 Strict DTD includes all elements and attributes that have not
|been deprecated or do not appear in frameset documents. For documents that
|use this DTD, use this document type declaration: 
|<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
|        "http://www.w3.org/TR/REC-html40/strict.dtd">
And we can omit system identifiers.

>(And isn't it just a one or two line fix anyway...?)

Yes it is. I already posted a patch.
Assignee

Comment 16

19 years ago
Ok -- a few facts for the newcomers. First, I never asserted that strict DTD's 
should invoke quirks mode. I invented the notion of quirks within Gecko, so I'm 
familiar with the idiom. 

Second, my wonderment has to do with how to interpret strictness when dealing 
with a web that is largely non-strict. Clearly a DTD that calls out strict 
explicitly is asking for new rules to be applied -- rules that will in fact 
adhere to the new version of our COtherDTD as soon as the tree opens and I can 
land it. But there are interesting cases in the middle. 

Third -- (VYV03354@nifty.ne.jp) -- patronizing the developers is not advised. 
My  point is that Gecko must do something rational in the face of badly formed 
markup. I frequenty see content where the system ID is missing and the DTD spec 
is incomplete. In such cases I have to interpret -- and I *must* do so 
liberally. When page designers get it right there's no dispute; it's when they 
get it wrong, or partially right that is the subject of my question. 

Comment 17

19 years ago
I guess the first question is who uses strict DTDs. It it's anal retentive web
developers who use a text editor and _know_ the strict standard, and want to
comply (like me :) then it should use strict mode. 

If there are HTML generators producing strict documents, and web designers are
editing them manually, putting in stuff that belongs in quirks mode, things are
going to fail horribly.

Might it be an idea to pop up a warning if we come accross some stuff that
belongs in quirks mode, it might be an idea to say 

"A document claiming proper HTML is actually badly formed. Enable quirks mode?"
with a yes/no and remeber decision. The thing is the average user is jsut gona
go "Huh?", so it might be an idea to put an option to always use quirks mode in
the preferences. Most of the general users, don't seem to care abotu strict or
quirks mode. They want it to work. 

Just some thoughts...
Assignee

Comment 18

19 years ago
Fixed in my tree. Note, however, that I don't simply apply doctype matching, 
since (once again) I get a considerable degree of badly formed markup. The 
intent however is to adhere to the rules of strictness better, while retaining 
some degree of compatibility.

Comment 19

19 years ago
over in 31933, I just added the following plus an attachment; i guess the discussion has 
moved over here, so i'll reproduce my comment, with apologies to those who are getting 
redundant copies:

MacIE5 has shipped with a DOCTYPE-based compatible/standard switch. I suggest 
evaluating it against whatever criteria one may have, and emulating it if found to be 
satisfactory. There is some chance that WinIE may follow MacIE5's (demonstrably useful) 
implementation, so this is potentially a very considerable interoperability issue. In fact, if 
Mozilla and MacIE5 follow a common model, this might increase the likelihood that a 
future version of WinIE will come into line.

Notably, Standard (aka "strict", not "quirks/compatibility"), is the default mode for all 
DOCTYPEs containing the string "HTML", with a list of ~20 DOCTYPEs in common use on 
the Web as exceptions triggering Compatibility mode, in which WinIE5 is emulated to a 
certain extent. The lack of any DOCTYPE also triggers Compatibility mode. 

The edge case is HTML 4: if the DOCTYPE is Transitional without URI (such as Composer 
generates), the mode is Compatible; if Transitional with URI, then Standard. HTML 4.0 
Strict and all XHTML/XML+CSS are treated in Standard mode.

I think MacIE5's level of real-world compatibility speaks for itself about how "safe" it is to 
make Standard/Strict the default for HTML, with a finite number of cases triggering 
Quirks/Compat. It just works. 
Reporter

Comment 20

19 years ago
The MacIE5's strategy is discussed at bug 34476.
Assignee

Comment 21

19 years ago
I've just landed the first of several updates that make mozilla handle 
strict/standard/compatibility modes better. In general, it's in alignment with 
todd's proposal -- but the algorithm is considerably more sophisticated than 
just basing our mode on the presence of the HTML keyword in the doctype. 

Note: I've only now begun to implement the STrict dtd; use it at your own risk.
(To enable it for now -- you must set ENABLE_STRICT=true in your environment).
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Updated

19 years ago
Keywords: nsbeta2

Comment 22

19 years ago
Anyone with a Win2000 setup able to verify this?
This wasn't Win2000 specific - it was filed from someone on a Win2000 machine. 
I saw it on either Linux, Win98, or both.  Marking All/All.
OS: Windows 2000 → All
Hardware: PC → All

Comment 24

19 years ago
updated qa contact.
QA Contact: janc → bsharma

Comment 25

18 years ago
Verified on 2001-07-19-branch on WinNT

The above attached tests load as expected (i.e. all in standard mode).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.