Closed Bug 29417 Opened 25 years ago Closed 25 years ago

HTML 4.0 Strict do not trigger standard mode

Categories

(Core :: DOM: HTML Parser, defect, P3)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: emk, Assigned: rickg)

References

Details

(Whiteboard: (Compatability mode detection))

Attachments

(4 files)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Strict//EN">
(deleted), text/html
Details
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
(deleted), text/html
Details
Proposed patch: only 4.0 without any specifier trigger STRICT
(deleted), patch
Details | Diff | Splinter Review
Additional testcase: HTML 4.01 Strict should also trigger the standard mode, of course.
(deleted), text/html
Details
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
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.
I want to fix this ASAP since this prevents to test the all mode related bug. Standard mode testcase is broken now.
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">
adding beta2 keyword, and removing pdt status
Keywords: beta2
Whiteboard: [PDT-]
removing beta1 keyword so it doesn't show up on beta1 radar
Keywords: beta1
Whiteboard: (Compatability mode detection)
Blocks: 34662
Blocks: 26857
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...?)
>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.
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.
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...
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.
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.
The MacIE5's strategy is discussed at bug 34476.
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
Closed: 25 years ago
Resolution: --- → FIXED
Keywords: nsbeta2
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
updated qa contact.
QA Contact: janc → bsharma
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.

Attachment

General

Creator:
Created:
Updated:
Size: