Closed Bug 34135 Opened 25 years ago Closed 21 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: 25 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: 25 years ago → 21 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.