Closed Bug 34135 Opened 24 years ago Closed 20 years ago

Mozilla needs an HTTP header to disable Quirks mode

Categories

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

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

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: sacolcor, Assigned: harishd)

References

Details

(Whiteboard: (Compatibility mode detection)) 

Currently, a document that conforms to the Transitional HTML DTD will be parsed 
according to Quirks mode, rather than according the W3C spec.  This is 
ostensibly to improve backward compatibility.  However, new authors (and 
hopefully increasing numbers of old ones) will expect standards compliant 
behavior, rather than these quirks.  It has been proposed that an HTTP header 
be created to override the default parsing rules:

"Mozilla-Layout-Mode"  has legal values "standard" and "compat".

If found (either in real HTTP or a META HTTP-EQUIV), the parser will change
behavior as specified.

This issue is being transfered from Bug 31933.
I entirely agree with this idea. I would suggest that a better name for the 
HTTP header would be:

   -Moz-Layout-Mode

...that would be consistent with how we've extended CSS.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: (Compatability mode detection)
Blocks: 34662
Why is this a networking bug? Seems like a parser issue to me.
Assignee: gagan → rickg
Component: Networking → Parser
QA Contact: tever → janc
This was originally entered as bug 31933 for the parser group.  However, rickg 
felt that it should go to networking, because the fix involved HTTP headers, so 
I entered this one for the networking group.  Shall we auction it off to the 
highest (lowest?) bidder? :-)
Gecko will not support the transitional DTD due to time constraints. We do 
support the backward compatible NavDTD and will offer Strict support.

Warren: the http changes being requested here (and elsewhere) are NOT a parsing 
issue as far as I can tell. There's already a mechanism for doing this based on 
meta. If you don't want to address the HTTP issue in necko, then close the bug.
Assignee: rickg → warren
Does Necko store all HTTP headers it's given?  If so, then would the issue would
be querying for it?

What META already exists?  Really, there should never be a META HTTP-EQUIV that
doesn't also work with a real HTTP header...
I don't understand this issue. Why would http get involved in this? 
Yes, necko stores all the http headers. QI to nsIHTTPChannel and get the header 
from that. I still don't see why this would be an http header -- seems wrong.

I assume by "what META already exists?" you mean how do you access the meta 
tags. I don't know -- I assume there's some way through the DOM. Cc'ing Jud.
This should be an HTTP header (in addition to a META element) because:
 * they're extensible, per the spec
 * they're a sensible way to transmit information about a document
 * they're an easy way to send information about large numbers of documents
without editing all the documents

BTW, I was asking what the name of the META that already existed was.

However, if bug 34476 is implemented, this will become less important.
The HTTP issue is covered by bug 3248. Once that is fixed, then using a META 
tag with HTTP-EQUIV should be exactly equivalent to using an HTTP header. 
I hope.

Ok. Sounds like nothing for us to do here then. Pierre can handle bug 3248 and 
you can already access the headers from http.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
I think the only issue left here is a description of the META tag to be 
used...I've been following the quirks issue for a while, and recall a passing 
reference to "rickg's secret META tag".

I'd suggest that once this issue is settled, that those who voted shift their 
votes to bug 34476.
meta http-equiv headers behave nothing like regular headers. they're a hack and 
treated as such on an individual basis.
valeski: Yes, and that is exactly what I hope will be changed by bug 3248...

rick: Would you mind telling us more about the "mechanism for doing this based 
on meta" that you alluded to? Is it <meta name> or <meta http-equiv> and what
are the name and values of the field?

Whatever the name and value of the meta tag are currently, we'll need to decide 
quickly whether they should stay as-is, or should be changed to something 
standard and 'official' (-Moz-Layout-Mode or whatever).  Once their identity 
becomes known, they will quickly become set in stone as code using them is 
written.
News on this? Eventually verify bug. Thanks.
I don't think invalid is an appropriate resolution for this bug.  I think this 
should be done, and I don't see how the bug is invalid (although it is assigned 
to the wrong group).

Reopening and...
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
... assigning back to rickg and marking dependency on bug 3248, so that both a 
META element or a real HTTP header will work.

We still don't know the name of the current META element that rickg mentioned.
Assignee: warren → rickg
Status: REOPENED → NEW
Depends on: 3248
Note: bug 42525 describes a doctype-only method for getting standards layout for 
transitional documents. That method would also be compatible with IE 5 for Mac.
Nominating for mozilla0.9.  I think we need to fix this for Mozilla 1.0 and it
should have significant testing beforehand.  DOCTYPE sniffing is a useful
heuristic for finding new pages vs. old pages, but some authors may want to use
a new/old DOCTYPE and have mozilla choose the opposite mode.  That is perfectly
legitimate -- we should not be making it harder for authors to use valid HTML on
the web.
Keywords: mozilla0.9
updated qa contact.
QA Contact: janc → bsharma
I don't think http headers are the ideal way to let page authors override 
Mozilla's quirks/nonquirks decision, since
- if you do View Source, you don't see HTTP headers.
- if you do Save As, you end up with something that doesn't display as intended 
in Mozilla, since the headers aren't saved along with the HTML.
I agree with David Baron's comment. I design my pages to use all the newest
standards, but I leave in enough old-fashioned code so that older browsers such
as Netscape 4 and WebTV can still display them accurately. It makes absolutely
no sense for Mozilla to punish me for doing this and render it in quirks mode,
completely ignoring the new standards I want to use. That means that if I design
my page to degrade for Netscape 4, Mozilla will display the page in quirks mode,
making all the same standards errors that people download the browser to get rid
of! Please, share the meta tag. As for the header thing, the rule is if it's a
meta tag it should also be an http header. Whether it's useful or not, it's
required.
I think this was solved elsewhere by not rendering with quirks if the full 4.01
Transitional doctype with DTD URL was specified in the HTML? Can't for the life
of me find it in a query though, maybe one of the Cc's knows and can close this.
I agree with Jesse's comments here, an HTTP header for this is beyond wrong.
Keywords: mozilla0.9
An HTTP header for this is far preferable to DOCTYPE sniffing.
QA Contact: bsharma → moied
Why is this header needed? Isn't quirks mode disabled if the DOCTYPE contains an
URI?
cbiesinger: We want to discourage people from intentionally setting the wrong
document type just to get around quirks mode. It would be terrible if everyone
started putting strict (or even transitional if used improperly) doctypes on
their pages even when they aren't really valid. It may make things better for
Mozilla, but it will create problems in other browsers, particularly IE6 which
uses the exact same system as Mozilla for rendering standards.
SkewerMZ: I had the impression that you only want to disable Quirks if your page
is standards compliant. Why would you want to do that if your page isn't compliant?
If you think of adding an HTTP Header to your page, you could also write your
pages according to the standards.

cbiesinger:  This bug is largely intended to provide a way for an author to
override the DOCTYPE based sniffing, in the cases where (for whatever reason)
the sniffing rules generate the wrong behavior (bug 101600 would be one
example).  There was also an argument made in another bug (that I can't find
right now) that using DOCTYPE to control the quirks mode is an abuse of the
purpose of DOCTYPE, and that other means should be used.

Hmm...I also notice that rickg (the prior module owner and assignee) hasn't
commented on this bug in 18 months (and I'm not sure if he's still working on
Mozilla).  Reassigning to the current module owner.
Assignee: rickg → harishd
I don't know if using doctype to decide whether to use quirks mode is an abuse 
of doctype, but I'm pretty sure that using an http header to decide would be an 
abuse of http headers.  Using http headers to control quirks mode would make 
pages stop working when you save them to disk, which would be confusing for 
both testcasers and users.  (See bug 31519 and bug 90490 for fixing similar 
problems with the content-type and content-encoding headers.)  It would also 
make view source less useful.
cbiesinger: To answer your question, we want to satisfy developers for whom 
Quirks creates unwanted problems on their pages, but for whom strict standards 
compliance is not yet an option.

Nobody should be subjected to the strange behavior that's part of NS4 backwards-
compatability just because they don't strictly adhere to a W3C standard (or 
have the guts to lie about it in their DOCTYPE).

Also, this would not be an abuse of HTTP headers. Many pages use headers to 
store specific document information, such as encoding and expiration. In order 
to fully support an extra HTTP header it must also be supported through META 
tags in the document, which is a way to fix the save-to-disk problem. There is 
no alternative that wouldn't violate something from W3C or RFC.
>Many pages use headers to store specific document information, such as 
>encoding and expiration. 

Encoding should become part of the filename when the document is saved, at 
least on operating systems that don't store mime types with each file, such as 
windows and linux (bug 31519, bug 90490).  The expiration date is a hint to the 
browser's caching mechanism, not a statement that "this document MUST self-
destruct", so it should not be saved with the file.

>In order to fully support an extra HTTP header it must also be supported 
>through META tags in the document, which is a way to fix the save-to-disk 
>problem.

That doesn't fix the problem if the page author chooses to send it as a header 
rather than a meta tag.
I agree with the concern that if a site used a http header to trigger strict 
mode and a user saved the file he would not see the exact same layout when the 
file was opened. However i still think we should do it because

1. The site should be aware of this risk when deciding to go with this solution.
   They always have the option of using an <meta http-equiv> if they want to
   make sure that saving works for their users. This is an opt-in feature, we
   are not forcing anything on anybody.

2. Noone has come up with a better solution even though this bug has existed for
   over a year. Just because a solution isn't ideally perfect doesn't mean that
   we should just drop it, in that case we would drop HTML support (and force
   everybody to use XSLT ;-) ).
About HTTP-equiv:
A processing instruction has also been suggested.
will that work for html? xml isn't a problem since xml is (or should be?) 
always in strict mode
Just because it's optional doesn't mean it's ok to include it with the 
browser.  Also remember that this would be an option for web servers, not for 
the users who might decide to save the pages.  I've been to many sites that 
don't care whether you can bookmark a page, much less save its contents.
Target Milestone: --- → mozilla1.0
I believe a fix for this bug would solve my problem but just want to make sure.
Unlike the summary of the bug, I'd like a solution for the opposite problem: I
want to make Mozilla use Quirks mode despite the doctype. I'm assuming an HTTP
header/meta tag could be set to override either way. The problem is that my site
uses a doctype that Mozilla does not recognize and therefore triggers strict mode.

A similar example is IBM.com. It uses the doctype !DOCTYPE html SYSTEM
"http://www.ibm.com/data/dtd/v11/ibmxhtml1-transitional.dtd" which is perfectly
valid. They use a SYSTEM dtd because it is an internal (not public) DTD.
However, it is essentially HTML transitional and would benefit from rendering in
quirks mode. Try the site with or without the doctype. Notice that the expected
rendering is generated in quirks mode, without the doctype.

Regarding the issue in comment 36:

"...it is essentially HTML transitional and would benefit from rendering in
quirks mode"

I'd like to point out that this isn't necessarily a valid conclusion;
transitional != quirks.  Properly designed transitional documents will be
rendered correctly in strict mode.  Quirks mode is only needed for documents
that rely on old-style Netscape 4.x behaviors, and hopefully these will
continuously decrease in number.
mass move to 1.1
Target Milestone: mozilla1.0 → mozilla1.1
It seems somewhat pointless to do this if it doesn't happen by 1.0. See also 
comment #19.
Keywords: mozilla1.0
Just to add my two penn'orth: I think this is a much better way to go than
DOCTYPE sniffing, which I regard as bogus. I prefer the reporter's original
suggestion of "Mozilla-Layout-Mode" (and its meta http-equiv), which would leave
the way open for other user agents identifying themselves as Mozilla :-) to
follow suit and make this a de facto standard. I also think that this should
happen with 1.0 if it is to gain acceptance.

I would be willing to have a crack at implementing this if no-one else wants to.
Whiteboard: (Compatability mode detection) → (Compatibility mode detection)
The number of pages that will render with quirks enabled is small
and shrinking.  There should be a way to disable quirks mode entirely.
> The number of pages that will render with quirks enabled is small
> and shrinking.

I would have thought the opposite, actually. On both counts.
[was 1.1alpha]
Target Milestone: mozilla1.1alpha → Future
I don't believe HTTP is appropriate for this.  The rendering of an HTML page is
a content issue (and arguably even that), not a transport issue.  HTTP headers
are for specifying information about what the content is and how it should be
transported, not how it should be rendered.

Think about why we even *have* a DOCTYPE directive in an HTML document and why
that data doesn't exist in HTTP headers, and ask yourself if a rendering hint
like this belongs with (near?) a DOCTYPE directive as opposed to its own "hints"
HTTP header.  If we can't get this data in the DOCTYPE directive natively,
perhaps we just need to put it in a comment?

 <!DOCTYPE html ...
    -- standards-compliant --
 >

Or our own meta tag:

 <meta name="mozilla-hints" content="standards-compliant" />

If someone still feels this really needs to be in the HTTP headers, maybe we can
make up our own optional content-type parameter for it:

 Content-type: text/html; charset=utf-8; x-mozilla-hint=standards-compliant
Another thought is that one could have an SGML processing instruction for it...
wasn't the idea with an http-header that that allowed a large number of
documents to be changed without going through each and every one of those
documents and modifing them? See comment 9.

It is impossible to solve that problem and at the same time avoid the problems
arised in comment 21, so we have to decide if which problem we can live with.
do people really want this? I haven't heard much demand for it, and I hate
adding yet more codepaths for this stuff.
I think that this bug remains relevant as long as we have a quirks mode; we need
a mechanism to allow the author to handle those instances where our DOCTYPE
sniffing generates incorrect results.  A META tag might also serve this purpose,
but discussion in bug 31933 indicated that an HTTP header would be more appropriate.
Comment #48
>do people really want this? I haven't heard much demand for it, 

I don't believe there is much real demand. I think the little demand this might
have is more about opposing the whole thing of having different modes and
doctype sniffing, and adding a HTTP header to the mess isn't going to make the
situation clearer.

Besides, the issue with Transitional, which apparently inspired this bug, has
been resolved.

>and I hate adding yet more codepaths for this stuff.

Documenting yet another Quirks vs. Standards vs. Almost Standards thing isn't
that great a prospect, either.

Comment #49

> I think that this bug remains relevant as long as we have a quirks mode; 
> we need a mechanism to allow the author to handle those instances where 
> our DOCTYPE sniffing generates incorrect results.  

A HTTP header wouldn't solve anything in Mac IE 5, Windows IE 6 or Mozilla-based
browsers that are already out there. Would author really use a HTTP header or a
method that is more widely supported (even if objectionable as a matter of
principle)?

> A META tag might also serve this purpose, but discussion in bug 31933 
> indicated that an HTTP header would be more appropriate.

If you can add a meta tag, you can change the doctype. If you can add a HTTP
header, chances are you can figure out a way for automating the process of
changing the doctype.

So this isn't a practical matter but a matter of principle: Is it wrong to have
to change the doctype which shouldn't have side effects like it has in order to
escape the side effects?

WONTFIX. We haven't really needed it at all in the years of having Quirks mode,
no other browser has needed it, and there is a simple way of changing what mode
a page gets rendered in: change the DOCTYPE. This RFE would complicate layout
and introduce a negligible performance hit, for no discernible gain.
Status: NEW → RESOLVED
Closed: 24 years ago → 20 years ago
Resolution: --- → WONTFIX
This is the wrong way to fix a self made problem. The right way is to validate
the document against the DTD. If the document is valid, there is no reason to
assume display bugs to be circumvented by using quirks mode. Quirks mode should
be entered only, if the document does not specify a DTD, or if the document is
invalid. In all other cases quirks mode is no enhancement but a bug it self.
You need to log in before you can comment on or make changes to this bug.