Closed Bug 31933 Opened 25 years ago Closed 25 years ago

NavQuirks mode triggered for Transitional documents when not desired

Categories

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

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

Tracking

()

Status:
CLOSED WONTFIX

People

(Reporter: sacolcor, Assigned: rickg)

References

Details

(Whiteboard: (Compatability mode detection))

Attachments

(2 files)

MacIE5 Standard/Compatibility mode-switching test document
562 bytes, text/html
Details
MacIE5 Standard/Compatibility mode-switching test document
562 bytes, text/html
Details
This bug is being split off from #1044 as the result of issues raised there. Currently, NavQuirks mode is triggered by the use of the Transitional DTD. This means that any web developer that writes a Transitional document (this includes the majority of pages I've seen in the wild) has to continue to code for the Nav 4.X bugs retained by NavQuirks mode. As a result, Mozilla is only perpetuating Nav 4.X's problems. A better way to trigger NavQuirks might be to use the following: 1) User selectable option in the menus or preferences. 2) Page authors can include a META tag, something like: NavQuirks = yes|no|user yes = Use NavQuirks mode no = Do not use NavQuirks mode user = Use user settings (default)
I think the DTD based selection should stay (perhaps in modified form). However, the HTTP header/META element and the pref are good ideas. Confirming bug, although it should probably go to another component.
Status: UNCONFIRMED → NEW
Ever confirmed: true
See also bug 1312, where a lot of these issues have already been discussed. Reassigning to Parser component.
Assignee: pierre → rickg
Component: Style System → Parser
QA Contact: chrisd → janc
Hardware: PC → All
After reading Bug 1312, I'm now leaning toward the following sceme for resolving the parsing mode (In priority order) 1) A META tag. If the document's author explicitly tells us to use/not use quirks mode, we should honor that instruction. If there's no META tag, go on to #2. 2) User preference. I'd suggest a radio box somewhere for "Mimic Navigator 4.x". The options would be "Yes", "No", and "Best Guess". If "Best Guess" is selected (probably the default), go on to #3. 3) Evaluate by DTD. The exact DTD triggers are debatable (and have been, at some length in bug 1312). However, they should be thoroughly documented, and optimally user-configurable, if only through a prefs file. IMHO, any of the three official 4.01 or 4.0 DOCTYPES should result in standard-compliant mode, since the entire meaning of that DOCTYPE is "This document conforms to the appropriate standard".
The problem with your suggestion (3) is that there are a significant number of pages out on the web that use an HTML 4.0 transitional DTD. Probably, many of these pages depend on quirks that won't be implemented in strict mode. However, probably almost all of them do not use a SystemID for the DTD, so the presence or absence of a SystemID could be used.
I could go for that, although I'm still a little bit apprehensive because it effectively means that we're telling the page's author "We know you declared that your document should be parsed according to the W3C standard, but we're going to assume you didn't really mean it". It also raises some forward- compatibility concers, as authors will (hopefully) begin to code to the standard, and not to Navigator's bugs. However, the SystemID and META tag logic do provide a way to make it work, and I don't have a better idea to suggest, so I'd vote for doing it this way.
Seems that we've both had the same idea on this - I've just entered a similar bug in 32086 (proposing an HTTP header). The suggestion in this bug is suboptimal for several reasons: 1. You shouldn't have to change your markup to get your page to work (for example, at richinstyle.com I use a hack to workaround Netscape 4's insistence on adding extra cellspacing; because I use transitional DTD Mozilla behaves the same, but because Mozilla supports @import my hack doesn't work and my pages IE does not do this)). 2. The user doesn't know, and shouldn't have to, which mode is best for a page. Personally I would prefer if all 'DOCTYPE triggers compatibility mode' parsing would be disabled and instead authors have to enable bugs (why on earth should the browser default to being buggy?????).
The reason we have quirks mode is because lots of pages on the web will break in standard mode, and we want pages to be usable in the browser so that people will use it, even before the designers of those pages start testing in it. Therefore the suggestion that the default always be standard mode is ridiculous. Also, I think "Mimic Navigator 4.x" is probably not the best wording for the pref, since that's not what quirks mode is.
Default mode is quirks mode so that we behave reasonably in accordance with what people expect from navigator. There are enough mechanisms to subvert that default (and to behave in standard mode) so I'm marking this wontfix.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
But there aren't standards-compliant ways of doing so if the page doesn't validate to a Strict DOCTYPE. Reopening bug. I think there should be an HTTP header (also usable with META) that can set the mode, overriding the DOCTYPE. Please ignore the comments from Matthew Brealey about defaulting to Strict -- that was not what this bug was about.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
*** Bug 32086 has been marked as a duplicate of this bug. ***
David: if I understand you correctly, you're *really* asking for a way for the document to specify standard mode regardless of the doctype? You suggest something in the HTTP realm, or via meta. I have a secret meta mechanism already in place, but I don't feel that the HTTP is the right way to go. Am I missing something?
Well, my intent when I filed this bug was to provide a mechanism for both the page author and the browser user to control Quirks mode, with the DTD detection mechanism only used as a last resort. As I discussed in bug 1044, I have a lot of code that validates to Traditional that IE handles fine, but which Nav4 processes incorrectly. If Mozilla tries to use the DTD to determine quirks mode, it's going to give me the same problems that Nav4 did, forcing me to either code special workarounds, or just accept poor display quality on Mozilla. I strongly suspect that there are many other developers in a similar situation.
I think HTTP is a good mechanism because it makes it easy for an author to make a global change to all pages. HTTP entity headers are also explicitly extensible (see sec. 7.1 of http://www.ics.uci.edu/pub/ietf/http/rfc2616.txt ). It then also makes a <meta http-equiv="..." ...> make sense (although you could be using a name="" meta rather than an http-equiv="" meta - I can't tell).
I was thinking of something along the lines of: <META name="MozNavQuirks" content="true"> But I'm not all that familiar with HTTP, so if you think an http-equiv would be more helpful, that sounds good. Also, I'm not familiar with RDF; there might be some kind of RDF syntax that would be more appropriate.
I'd like to know what specific HTTP header is being proposed here. Please give an example, using the precise syntax that is being proposed.
OK... I'll make up a name: the "Mozilla-Layout-Mode" entity header, which takes values "standard" and "compat". Thus, one could include an HTTP header: Mozilla-Layout-Mode: standard which is equivalent (see http://www.w3.org/TR/REC-html40/struct/global.html#h-7.4.4.2 ) to the meta element: <meta http-equiv="Mozilla-Layout-Mode" content="standard">
Would a Web site send this header to *any* browser, or only to Mozilla?
I'm closing this bug, as it's not a parser issue. If you want to do something new and interesting with HTTP, please open a new bug/feature request on the networking team.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WONTFIX
I've filed Bug 34135 to handle the HTTP header issue. What about the user preference? Whether or not there's a UI for it, there should be a way for the user to override the quirks/standard mode default decision logic.
Whiteboard: (Compatability mode detection)
Blocks: 34662
I have very mixed feelings about a user preference for this. I see the use for sophisticated users, but in general it is the browsers *job* to make the right decision about this kind of thing. Yes, all the variables involved make this a difficult decision to make. Do we just punt and tell the user, "Hey, *you* figure it out." The need for a quirks mode is an artifact of Mozilla's heritage and the heritage of the Web. It is a bit of implementation ugliness. It is the kind of thing applications are supposed to hide from the user. A user preference should be a measure of absolute last resort. I think that between the doctype modulus and an HTTP header, document authors have about as much as Mozilla can possibly offer them while still engaging quirks for oblivious legacy documents. I think that before resorting to a user preference, those facilities should be substantially field tested to see exactly how big their weaknesses are.
braden: Check my comments from 2000-03-15. The user preference is secondary to the author preference, and would default to 'Best Guess' (use the DTD). I think we want to take our best guess by default, but both the author and the user should have some way to override that default. This is important because no matter what we do, we won't be right 100% of the time. Also, I think there are many users that will be confused by the behavior of quirks mode. I remember the webmaster of RichInStyle.com originally gave Mozilla a poorer standards-compliance rating than it deserved, because Moz was rendering his pages in quirks mode. He eventually recoded his pages to Strict, but having this preference would have saved him a lot of trouble. The last thing I'd want to see is a reviewer at one of the big 'zines can Mozilla for non-standards-compliance because they were running in quirks mode and didn't know it. I'm sure they run through all the (exposed) preferences during the review process, and if they see this one, at least they'll know what the deal is.
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-30 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 attach a simple test case useful for exploring MacIE5's mode-switching heuristics. (sorry about the duplication)
I think that all the issues in the bug have been moved into other bugs as follows: Quirks mode based on document DTD: bug 29417 Quirks mode based on HTTP header: bug 34135 Quirks mode based on user preference: bug 26575 Let's move any further discussions to the appropriate issue.
I've decided that a pref is the only viable solution; Harish has been given that task.
Verifying, as this has been weeded out obviously.
Status: RESOLVED → VERIFIED
Bug 42525 covers the doctype switching issue.
*** Bug 92313 has been marked as a duplicate of this bug. ***
The resolution of bug 42525 appears to remedy the underlying problem in this bug (undesired quirks mode in transitional HTML documents), although not via the META tag proposed in the summary. Changing resolution to CLOSED.
Status: VERIFIED → CLOSED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: