Closed Bug 31933 Opened 25 years ago Closed 24 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: 24 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: 24 years ago → 24 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: