Closed Bug 42525 Opened 24 years ago Closed 24 years ago

[DOCTYPE] Transitional DOCTYPE with URI should trigger strict layout mode

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: hsivonen, Assigned: rickg)

References

Details

(Keywords: regression, Whiteboard: [nsbeta2-][nsbeta3-][rtm++])

Attachments

(4 files)

Test for quirks vs. starndard mode
(deleted), text/html
Details
Test case to verify the bug.
(deleted), text/html
Details
Test case to verify the bug [ Please ignore my previous test case ]
(deleted), text/html
Details
testcase that should display in strict mode
(deleted), text/html
Details
BuildID: 2000060908 A document with this DOCTYPE declaration: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> gets rendered in the quirks mode. Reproducible: Always Steps to Reproduce: 1. Load the attached testcase. Actual Results: The text reads: "Layout not in standard mode." That is the page is rendered in the quirks mode. Expected Results: Expected the text to show up as: "Layout in standard mode." That is expected the page to be rendered in the standard mode. IE 5 for Mac allows HTML 4 Transitional documents be handled in either the standard mode or in the quirks mode. A DOCTYPE declaration without a URI leads to the quirks mode. (ie. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">) A DOCTYPE with the URI leads to the standard mode. (ie. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">) Mozilla, however, handles both cases in the quirks mode. Some authors are likely to expect behavior similar to that of IE 5 for Mac. Some authors really want to use the Transitional DTD but still have to page handled in the standard mode. Currently you can't author valid HTML 4 Transitional and have Mozilla display it according to the specs. Displaying the case without the URI in quirks mode, on the other hand, provides for bugwards compatibility with old pages.
The comment parsing code in strict mode is operating incorrectly in this case. The comment example: <!-->not<!-->. In this case, the word "not" is part of the strict comment, and should not be rendered.
Oh -- wait -- now I recall why. We decided (perhaps wrongly) to allow backward compatible comment handling to operate in transitional mode documents (it's the only area where we take liberties with the spec). Let me think on this one a while.
I used the comment just as a known quirk to detect the compat mode. The problem itself is that the transitional doctype with or without the URI leads to the NavQuirks mode while in IE 5 for Mac the declaration with the URI leads to the standard mode.
There are three parser modes (DTDs) and two layout modes: Strict DTD Transitional DTD Compat DTD Standard Layout NavQuirks Layout A Transitional DOCTYPE should trigger Transitional DTD. This is currently happening, as Rick explained. The comment thing is not a layout quirk and so cannot be used to check Layout mode. See also http://www.bath.ac.uk/%7Epy8ieh/cgi/compat-test.pl (Is that all correct Rick?)
OK. I tested the wrong way. According to http://www.bath.ac.uk/%7Epy8ieh/cgi/compat-test.pl, HTML 4 Transitional gets parsed in the Transitional mode and rendered in the standard mode. Should I resolve this as invalid or leave open for comment handling consideration?
Rick? It's up to you if this gets marked INVALID now...
As stated, the bug is invalid. But now we have a new problem: The composer team assigned a bug to me complaining the their documents (from nav4X) we're not rendering correctly. As it turns out, they place a <doctype HTML 4.0 transitional> tag into the markup -- but then violate the transitional spec. Sigh. After talking with product marketing, the only way out of this is to create a (non-visible) preference to control transitional doctype handling. By default, we will need to load transitional documents in quirk mode. The pref will allow a savvy user to cause transitional documents to be handled by the transitional DTD. It stinks, but there's no other way.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
There are other ways. IE 5 for Mac uses the URI as the preference indicator. The solution isn't ideal, but it's better than considering all transitional documents quirky. Please leave the Transitional doctype with the URI as non-quirky. Otherwise this bug becomes valid. :-) If Composer from 4.x is the only problematic editor that uses the 4.0 Transitional doctype without complying with the spec, the pages can be detected from meta tags eg. <meta name="GENERATOR" content="Mozilla/4.6 (Macintosh; I; PPC) [Netscape]">. Is the string "-//W3C//DTD HTML 4.0 Transitional//EN" supposed to be case-sensitive? The old Composer uses "-//w3c//dtd html 4.0 transitional//en".
According to http://www.bath.ac.uk/%7Epy8ieh/cgi/compat-test.pl, this bug is valid as of build 2000062408.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
We have a fix in hand, which also corrects the composer issue (where composer claims 4.0 transitional but is not). PDT: Please allow this fix so we can put the composer/transitional DTD issue behind us.
Status: REOPENED → ASSIGNED
Keywords: 4xp, compat → nsbeta2
Whiteboard: fix in hand
Adding [NEED INFO]. Nisheeth, are we ok on this bug now? If so, please take it off the radar.
Assignee: rickg → nisheeth
Status: ASSIGNED → NEW
Whiteboard: fix in hand → [NEED INFO] fix in hand
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [NEED INFO] fix in hand → [nsbeta2+] fix in hand
Reassigning to myself. BTW, isn't this bug fixed?
Assignee: nisheeth → harishd
Okay, this is definitely fixed. Will attach a test case to verify this.
Status: NEW → ASSIGNED
Attached file Test case to verify the bug. (deleted) —
Marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Marking verified fixed in the July 10th build.
Status: RESOLVED → VERIFIED
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20000810 <A HREF="showattachment.cgi?attach_id=11201">This attachment (id=11201)</A> is showing up as quirks. It is showing up as quirks here too: http://www.bath.ac.uk/%7Epy8ieh/cgi/compat-test.pl?DOCTYPE=%3C% 21DOCTYPE+HTML+PUBLIC+%22-%2F%2FW3C%2F%2FDTD+HTML+4.01+Transitional%2F%2FEN%22+% 22http%3A%2F%2Fwww.w3.org%2FTR%2Fhtml4%2Floose.dtd%22%3E&MODE=full can someone verify and reopen bug if necessary - thanks.
Transitional DTD has been disabled ( refer bug 42388 ).
However, it should still trigger strict mode in layout when used with a URI. Reopening.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
This bug should then go the layout folks. This is not a parser problem anymore. Giving bug to Mark.
Assignee: harishd → attinasi
Status: REOPENED → NEW
For HTML 4.01 Transitional bug 46958 is a duplicate of this bug. What's the plan with HTML 4.0 Transitional?
Right now, the parser determines the layout mode. I could probably modify the DOCTYPE parsing code I attached to bug 44340 to do this without too much difficulty.
Target Milestone: --- → Future
Harish: layout relies upon the parser having set the mode, so if the mode is incorrect it is not layout (and is likely the parser). David Baron: You seem to be on this bug (via bug 44340) so should I assign it to you? Everyone: Please let me know what if anything this has to do with Layout...
The fix for this may be usurped by the bigger change required to fix bug 48351.
You're right Mark. I forgot the fact that the parser actually sets mode on the layout ( while back layout did this on its own ). Sorry about that. Assigning to myself.
Status: NEW → ASSIGNED
PR2 is outta here...moving from [nsbeta2+] to [nsbeta2-]. Adding nsbeta3 keyword.
Keywords: nsbeta3
Whiteboard: [nsbeta2+] fix in hand → [nsbeta2-] fix in hand
Harish, you assignment to self didn't make it - here ya go :)
Assignee: attinasi → harishd
Status: ASSIGNED → NEW
Marking nsbeta3+. Will fix this once we decided what we are doing with the strict dtd. Should be an easy fix either way. This is nisheeth typing for harish.
Whiteboard: [nsbeta2-] fix in hand → [nsbeta2-][nsbeta3+]fix in hand
*** Bug 43274 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Target Milestone: Future → M18
Since bug 43274 was marked a duplicate of this one, this bug is now also considered to cover triggering the standards layout for unknown doctypes. (Unknown XHTML doctypes should go down the XML + std layout code path.)
I'm going to attach the testcase from bug 43274. Please make sure it works correctly.
Depends on: 50070
This problem would get resovled when bug 50070 gets fixed ( basically by turning off STRICT DTD ). Marking it a dup. *** This bug has been marked as a duplicate of 50070 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
No longer depends on: 50070
Resolution: --- → DUPLICATE
This is a separate issue from turning off the strict DTD, since this affects layout quirks mode. Reopening. If you want to fix both at once, that's fine, but they're separate issues in the code.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Rickg and several other folks seem to disagree in triggering strict layout ( i.e., a transitional doctype,with or without a uri,should trigger quirks layout ). I'm therefore giving this bug to rickg for futher analysis on this issue. And, also, since he's been working on bug 50070. Over to you rickg :-)
Assignee: harishd → rickg
Status: REOPENED → NEW
We did it before, but undid it only because pages were breaking, largely due to the Strict DTD, I think.
Some authors really want a way to use HTML 4 Transitional with standard layout. You get the benefits of standard CSS handling but can also include deprecated HTML to ease graceful degrading in old browsers. It hasn't been demonstrated that too many pages break too much with CNavDTD + std layout for Transitional doctypes with the URI. IIRC, this combination hasn't been tested for Transitional doctypes with the URI. When std layout was previously enabled for these doctypes, the parser mode was strictly transitional and didn't deal well with bad HTML. Not fixing this bug would leave IE 5 for Mac more standards-compliant than Mozilla in this scenario. None of us wants Mozilla to be less compliant than IE, right?
Landed fix for "most" cases. The problem is that nav/ie don't agree on some of the odder cases, so we're punting on them.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Priority: P3 → P2
Resolution: --- → FIXED
Oops, I closed the wrong bug. Sorry.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This is very feature-ish and very unlike the P2 criteria. pdtp5.
Priority: P2 → P5
Whiteboard: [nsbeta2-][nsbeta3+]fix in hand → [nsbeta2-][nsbeta3+][pdtp5]fix in hand
Target Milestone: M18 → Future
Why future a "fix in hand" nsbeta3+ bug? This bug is not feature-ish. As indicated above, the fix for this bug is required for the ability to use HTML 4 Transitional in a standards-compliant way. Some authors want to use standards-compliant Transitional to get the benefits of the standard layout mode and to allow graceful degradion in legacy browsers.
cc ekrock@netscape.com as the reporter of bug 50070 which seems to be relevant for this one. This bug is mainly a decision what layout mode should be used given a certain doctype. It does not make much sense to make this decision after NS6 is out. Please review. Thanks.
Not fixing this bug would leave Web authors with these options: 1) Migrating to HTML 4 Strict 2) Writing doctypeless code to old bugs 3) Declaring documents Strict even though deprecated elements are used 4) Migrating to XHTML Transitional sent as text/html * Option 1 is unavailable to authors who think (or whose clients or managers insist) that pages should be reasonably compatible with legacy browsers. * With option 2 the benefits of standards layout are lost * Option 3 would mean breaking the standards to get the standard layout in one layout engine. This option is not good. However, it is known that this approach has been used in practice to work around this bug in Mozilla. Compelling authors to break standards isn't at all good. * Implementing option 4 without creating a forward-compatibility problem requires great care. Compelling authors to hastily declare potentially non-compliant code as XHTML isn't a good solution. If the triage team thinks treating HTML 4.0 Transitional as non-quirky is too risky (even though IE 5 for Mac does it), please OK at least treating HTML 4.01 Transitional as non-quirky.
1) is the ideal solution. 2) is what happens now, and is what you need if you want pages to be compatible with legacy browsers. 3) is unlikely to happen, as why would people want standards to be followed if they didn't use them. 4) would be handled as normal HTML (quirks mode), as requested by the HTML WG.
I think we can use any indicator of XHTML (an XML declaration or an XHTML doctype) to trigger *layout* standard mode -- just not the Strict DTD or the XML parser.
I am not that convinced that authors will stay away from option 3 if this bug isn't fixed. Past behavior suggests that many authors will choose a hack over standards-compliance if the page looks better that way. AFAIK, option 3 has been used even on richinstyle.com!
Not holding PR3 for this; marking nsbeta3-. Please nominate for rtm if we really need to fix this before shipping Seamonkey.
Whiteboard: [nsbeta2-][nsbeta3+][pdtp5]fix in hand → [nsbeta2-][nsbeta3-][pdtp5]fix in hand
Nominating for rtm because of reasons stated in my previous comments. I can describe concrete authoring scenarios if necessary.
Keywords: rtm
Agreed. We need to fix this for rtm. It is at the core of our standards compliance. We really should fix it for beta3 to get more testing, though...
Rick, this bug is marked "fix in hand". Is it for real, or is the remnant of a previous fix?
David, Ian, Henri -- Please provide as much concrete data as possible about the severity of impact if we don't fix this. This is the data I must have in order to make a case to PDT for accepting a fix like this at this late date. Thanks! Also, could someone please change the Summary from "Transitional DOCTYPE with URI considered quirky" which makes no sense (what's the problem? what's right? what's wrong? what should we do?) to a phrase that clearly states what is wrong and what must be done to fix it?
Also, please document that this is low-risk. (It should be, because we're just choosing which existing, tested code path gets applied in a particular situation, right?)
As I understand the request, folks want Transitional docs to set the layout "mode" to be non-quirky. If that's the consensus, fine -- it's really a *trivial* fix. I expect 2 lines of code, and a bit-o-testing.
My main concern is still (and it used to be the original Summary line of this bug report) that documents with unknown doctypes are displayed in quirks mode. Look at my "testcase that should display in strict mode" (08/24/00 19:14): it uses the doctype from our good friend Todd Farhner at Verso's and it displays in quirks mode. On [2000-08-29 17:04], Harish marked said that it would get fixed when bug 50070 would be fixed and he marked it as dup, but bug 50070 is gone and the problem still remains.
From your comment, it seems you want unknown doc types to be non-quirky. But that's not what 4x would do -- and it doesn't seem to be the original point of this bug. I think IE uses bugward compatibility (I'll double check). If they do, then I'd be disinclined to enter standard mode.
Eh? Netscape 4.x doesn't do DOCTYPE sniffing, and MacIE 5.0 uses the URI the way this bug suggests.
I'm not the best guy to talk about the whole issue but I understood as obvious from the experts that it is very important not to be quirky with unknown doctypes otherwise it would greatly impact the use of doctypes in the future. Quirks mode should be triggered by the absence of doctype, or by the presence of a few doctypes that we think should be quirky.
Colors (all pages) HTML 4 Strict doesn't allow any color definitions for the page. As a result, non-CSS browsers use a browser color scheme when displaying pages authored with HTML 4 Strict and CSS. The default page background color is typically gray in lecagy browsers. Web authors, in general, consider the default gray particularly ugly and also think that most users haven't changed the default. Color is considered important. Even if the page was written to the standards and with (primarily) non-quirky rendering in mind, the author is still likely to want to include deprecated color definitions to get the intented color scheme in non-CSS browsers. Floaters (nearly all pages with images) Making the text wrap around images is a common design practice when images are displayed alongside text. This effect can be achieved by using floating images. Floating behavior can be controlled by using CSS or by using deprecated HTML. In the case of HTML 4 Strict, using CSS is the only option. Pages with CSS-only floaters look particularly badly designed in non-CSS browsers. The user of such a browser might think the author has no skill or taste. The images make big gaps in the text, but the line following an image is next to the image instead of being entirely below the image. On the other hand, the look of such pages in non-CSS browsers can be significantly improved by using deprecated HTML as a fallback solution. The author is likely want to include deprecated floater information even if the page was primarily intented for standards-compliant non-quirky display. The solution Note that in the above examples, the intent is not to make the page look identical in standards-compliant CSS browsers (including Mozilla) and in non-CSS browsers. The intent is not to have Mozilla handle the page the same way old browsers do. Rather, the intent is to leverage standard layout and new features in new browsers while still including some presentational hints for old browsers. Since the Strict DTD doesn't allow the inclusion of such presentational hints, the Transitional doctype declaration has to used in order to keep the code valid. If Mozilla renders these pages in the quirks mode, the goal of leveraging standard rendering in new browsers isn't met. This problem can be worked around in a way that is not standards-compliant. It would be better to discourage the use of non-compliant workarounds by providing a standards-compliant way to leverage the standard layout mode with pages that also contain presentational hints for older browsers. The solution would be triggering the standard layout mode for pages that contain a Transitional doctype declaration in full with the URI. (Note that pages generated by the Composer component of Communicator 4.x don't include a full doctype declaration with the URI and would still trigger the quirks mode.) Not fixing this bug would significantly raise the treshold of migrating from quirks to standards. Risk analysis The fix involves a very slight change in the code that makes the decision about the layout mode. The fix isn't expected to affect the stability of Mozilla. In practice, the only risk is that some non-compliant pages that nonetheless use a Transitional doctype declaration in full with the URI might depend on quirky layout and show up in an unintended in the standard layout mode. This risk could be minimized by restricting the standard layout to HTML 4.01 (and the hypothetical "later") Transitional with the URI and unknown doctypes (as opposed to including HTML 4.0 Transitional with the URI). Of the top sites that I have checked only apple.com uses the HTML 4.01 Transitional doctype declaration with the URI. Fixing this bug would cause a noticable but not fatal misalignment in the navigation bar at apple.com. However, I think the benefits that would come along fixing this bug by far more important than that misalignment. I think it is better to expect Apple to fix their site (very trivial to fix) instead of letting that small misalignment jeopardize the migration from quirks to standards layout. (Note: Previous tests with rendering some Transitional documents in the standard layout mode involved a parser mode that had a very strict error handling policy. This is not the case with the current parser mode. That is, bug reports about the old parser mode shouldn't be held against using the standard layout mode with the current parser mode.)
Rick, as I understand the request, docs with a Transitional doctype _with URI_ should set layout "mode" to be non-quirky. Is this possible? Is it an illusion to think that there is still any chance to get this into PR3? Changed summary from "considered quirky" to "should not be considered quirky". What I'm concerned about is that shipping 6.0 without this fixed would make it nearly impossible to fix it in a later release, or even a mozilla.org release, just because 6.0 will be quoted as precedence.
Summary: Transitional DOCTYPE with URI considered quirky → Transitional DOCTYPE with URI should not be considered quirky
Just summarizing my previous comments: Let's consider these three propositions: P1: Page looks great in Mozilla-based browsers P2: Page looks at least reasonably good in legacy browsers P3: Page validates The way Mozilla currently is, only two of those three propositions can hold true for a [normal] page at a time. Considering past authoring practices and priorities, I think Web authors are likely to pick the combination where P1 and P2 are true while P3 is false. Wouldn't it be ironic, if the introduction of a browser that aspires to be standards-compliant would lead to an increase of pages that are declared as Strict but are deliberately not valid? Fixing this bug would make it possible to have all the three propositions hold true at the same time. That's why I think fixing this bug (in the trunk and in the branch) would a very big win.
Can someone *please* explicitly state that it is possible (and makes sense) to fix this for later releases as suggested by the "Future" milestone? Otherwise this has to be targeted for M18/RTM or marked WONTFIX.
It doesn't make sense to postpone fixing this past the Netscape RTM. If any Mozilla-based browser gets distributed to a lot of people (like Netscape 6) without a standards-compliant way to trigger the standards layout for Transitional markup, the damage to standards-compliant authoring can't be retroactively fixed.
In reference to RickG's comment from 2000-09-28: The intent is not to change all Transitional docs to standard layout. The intent is to trigger standard layout for Transitional documents whose doctype declaration contains the URI. If that is considered too risky for HTML 4.0 Transitional, even doing it for HTML 4.01 Transitional would be *very very* important. That is: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> would go to the quirks mode while <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> would go to the standards mode.
IMO, we should be triggering standard mode for any DOCTYPE declaration with a system ID (i.e., a URI). (We should really be doing the FPI decisions based on a list of doctypes that are quirky, rather than the reverse.) It would make sense to fix this after 6.0 ships if we don't fix it for 6.0. It would just mean that authors would have to wait for 6.0 to drop to insignificant market share before writing standards-compliant pages just like they are now waiting for 4.x to drop off the market. (I suspect 6.0 may drop off the market before 4.x does, since a 6.0 -> 6.1 upgrade should be rather painless.) However, I still think we should fix it the right way for 6.0, although it does need some testing if we are going to do so, and it probably should have been done sooner so we could get more testing. We did agree to fix this before, but the fix was undone to fix bug 42388 in a very easy way right before beta2 (rather than just turning off the Strict/ Transitional DTD, as has been done since). See the comments from 2000-08-11 when this bug was reopened.
Keywords: regression
As per jar's post to n.p.m.seamonkey, PDT won't be looking at this bug until this is [rtm+]'ed. Who, in this case, is the qualified person to give this bug the [rtm need info] status in order to allow working on a patch? Does the [pdtp5] marking need to be removed from the status whiteboard? Does it cause this bug to fall off the reconsideration radar?
First, many thanks to Henri for careful research & analysis and for escalating this. You've performed a real service for Gecko, Mozilla, Netscape 6, standards compliance, and enabling the actual use by web content authors of our standards-compliant layout. Clarifying the current meaning of this bug report ------------------------------------------------- 1) This bug report is not suggesting that we revisit the whole macro-level strict decision that was resolved earlier in a conference call; that's a dead snake. 2) Also, there's a second issue noted by Pierre, the proposal that our URI sniffing should handle unknown doctypes in strict mode (strict by default, quirks only for recognized exceptions) rather than quirks mode as it does currently. I haven't had the time to develop an opinion on that, but to focus this bug report, I will open a separate bug to track that issue. 3) Changing summary from "Transitional DOCTYPE with URI should not be considered quirky" to "Transitional DOCTYPE with URI should trigger strict layout mode." This bug report will now focus on this one issue only. What this bug report is proposing --------------------------------- If we implement this fix for RTM (and I believe that we should, for reasons noted below), then the following DOCTYPEs, which have the URI specified and currently trigger quirky *layout*, will trigger strict *layout* (not parsing) instead: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> The following DOCTYPEs without the URI will continue to trigger quirks mode as they do now: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> Why it's important to do this for RTM ------------------------------------- 1) As noted by Henri, the current inability to include presentational hints for older browsers (while still laying out strictly within Moz/N6) is a significant obstacle to web content authors who wish to take advantage of Gecko's hard-won standards compliance. Fixing this bug will solve that problem and will greatly enhance the ability of content developers to actually make use of the standards-compliant layout we worked so hard to achieve. 2) It's important to do this for RTM as opposed to a later point release because if we delay this change to a later point release, web content developers won't be able to take advantage of it until Netscape 6.0 drops to negligible market share, replaced by the point release. 3) Achieving standards compliance was one of the key strategic goals for the entire Gecko and Mozilla projects; removing blockers that prevent content authors from leveraging that standards compliance is critical to achieving success on the web. 4) This bug is important even if you're just looking at AOL's internal needs alone. Fixing this bug will significantly simplify the task of AOL online properties (and unaffiliated sites as well of course) who want to make sure they work well on Netscape 6; fixing this will significantly ease internal evangelism for Netscape 6 support throughout AOL online properties. Marking P2 as this bug is critical to enabling high-profile web content properties, including those of AOL itself, to support and optimize ASAP for Gecko-based browsers such as Netscape 6 and Gecko-based devices such as the AOL/Gateway appliance. Clearing [pdtp5] to trigger re-evaluation. Why this is low-risk -------------------- a) This fix is low-risk with respect to destabilizing the Mozilla codebase. We're simply modifying our DOCTYPE sniffing rules to switch which existing layout approach is followed for a particular DOCTYPE. b) This fix is also low-risk with respect to creating incompatibilities with existing web content. We know that IE5 for the Mac already shipped with this feature. Given the priority Microsoft places on backward compatibility, they would not have done this if they felt it would cause IE5 for Mac to display legacy content poorly. c) I and/or the Mozilla evangelists will take care of evangelizing apple.com (the one known site with a problem here) to fix their markup. Issues ------ 1) We need an engineer who will write the patch, get it reviewed and super-reviewed, and check it in. Rick, the bug's currently assigned to you; could you do this? If yes, please confirm and mark [rtm+ need info]. If not, let's look for someone who is able to. Clearing fix in hand. 2) PDT needs to approve the check-in. I'll be happy to present to PDT team if necessary. Please mark rtm++ as soon as a fix is attached, reviewed, and super-reviewed, and call me if you're even considering marking this rtm-. Changing from FUTURE to M19. Thanks all!
Priority: P5 → P2
Summary: Transitional DOCTYPE with URI should not be considered quirky → Transitional DOCTYPE with URI should trigger strict layout mode
Whiteboard: [nsbeta2-][nsbeta3-][pdtp5]fix in hand → [nsbeta2-][nsbeta3-]
Target Milestone: Future → M19
I think the original idea was that all DOCTYPEs with a URI should trigger strict layout mode. Does anybody object if I retitle the bug? (The old title pointed to a specific symptom. The new one attempts to describe the general problem but I think does not.)
I think that Rick wanted to trigger the quirks mode when we had no DOCTYPE at all, of course, but also when the DOCTYPE matched one of the few recognized ones like HTML 3.0. The original title was something like "Documents with unknown DOCTYPE should be displayed in strict mode".
David--thanks for checking, *please* do not retitle this bug! We're going to keep this particular bug report focused on the simplest, lowest-risk case of "The HTML 4.0x Transitional DOCTYPE with URL should trigger strict layout mode." That is the least-controversial, lowest-risk thing being discussed here and the proposal PDT is most likely to accept given the limited time before ship. It's also probably the most important. David and Pierre's proposals each may (or may not) be something we want to do for RTM, but each proposal affects a much larger class of documents than this proposed fix (David's proposal: all DOCTYPEs with a URI; Pierre's proposal: all unknown DOCTYPEs) and as a result *might* cause more backward compatibility problems since they're affecting the handling of more pages than this bug fix. To keep this bug report focused, I have hived off two new bug reports to track David's and Pierre's proposals, which each need to get their own cost-benefit analysis and rtm++ or rtm- status distinct from what I did above for the simple case. Here they are: David: bug 55263: "all DOCTYPEs with a URI should trigger strict layout mode" Pierre: bug 55264: "Documents with unknown DOCTYPE should be displayed in strict mode" BTW, I recognize of course that depending upon the evaluation of David's and Pierre's proposals, we might want to make all the changes at once for efficiency. The point however is that I'm trying to get the cost-benefit analysis for each separate proposal (and rtm approval or denial status) contained within its own separate bug report, instead of mixed together in this one.
Clarification to my risk analysis which addressed HTML 4.01: Implementing this for <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> is very safe. Implementing this for <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> would, on some sites (eg. www.sun.com, www.versiontracker.com), cause table cells whose content lower than the line height (ie. small images) be sized vertically to the line height. IE 5 for Mac gets around this. This might be addressable in the UA style sheet.
MacIE5 gets around it by implementing the Inline Box Model incorrectly.
Marking [DOCTYPE] for easy searching.
Summary: Transitional DOCTYPE with URI should trigger strict layout mode → [DOCTYPE] Transitional DOCTYPE with URI should trigger strict layout mode
I think that at this point it would make sense to narrow this bug to apply only to <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> in order to avoid box sizing issues with sites that use <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">. RickG, What's the situation with this bug?
Is RickG known to be aware of this bug and its current state?
Too much spam - removing self. Sorry for *my* spam.
Requesting a triage on this bug. It's nominated but doesn't have a - or +. Are we going to fix this for rtm ?
I'm brutally aware the issue -- and I have a simple patch to correct. I'll add a patch that corresponds to henri's latest proposal, to do this only for the doctype (HTML 4.01 or greater): <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Status: REOPENED → ASSIGNED
MSIE5Mac uses strict rendering for the HTML 4.0(0) doctype with URI, right? If we don't, we might cause troubles for pages that use this doctype to trigger strict rendering (especially because MSIE5Mac shows this behaviour), not? Should we file a bug about HTML4.00 specifically?
We cant do that because nav4x/composer emited that doctype but expects backward compatible behavior. :(
no, Nav4x Composer used an invalid doctype altogether (it was lowercase) and so should not be an issue in deciding the resolution for this bug.
Here's the patch which fixes this bug: Index: nsParser.cpp =================================================================== RCS file: /cvsroot/mozilla/htmlparser/src/nsParser.cpp,v retrieving revision 3.225.2.1 diff -r3.225.2.1 nsParser.cpp 633a634 > 701a703,705 > PRInt32 theMajorVersion=3; > PRInt32 theMinorVersion=0; > 775d778 < PRInt32 theMajorVersion=3; 783c786 < else aBuffer.Mid(theNum,theVersionPos,3); --- > else aBuffer.Mid(theNum,theVersionPos,4); 785a789,792 > if('.'==theNum[1]) { > theNum.Cut(0,2); > theMinorVersion=theNum.ToInteger(&theErr); > } 828a836,838 > else if((eDTDMode_transitional==thePublicID) && (eDTDMode_strict==theSystemID)) { > aParseMode=(4<=theMajorVersion) ? eDTDMode_strict : eDTDMode_quirks; > } 867c877 < aParseMode=eDTDMode_quirks; --- > aParseMode=(0==theMinorVersion) ? eDTDMode_quirks: eDTDMode_strict; 875a886 >
RickG, Great! Thank you. Could a qualified Netscape person, please, give this [rtm+] so that this gets on the PDT's radar? Ben Bucksch, IE 5 for Mac indeed triggers its standard layout mode for HTML 4.0(0) Transitional with the URI. However, in the case where line-height hasn't been explicitly defined by the author, IE 5 for Mac uses the image height to size vertically the enclosing box of the image (the Nav 1.x way). This isn't exactly the way described in the CSS spec and, therefore, this trick isn't used in Mozilla's standard layout mode. I recommended excluding HTML 4.0(0) from the scope of this bug in order to avoid any panic related to table cells being sized "unlike the author intended" on existing pages. OTOH, HTML 4.01 Transitional pages with the URI (like HTML 4 Strict) pages are currently *very* rare.
Rick, could you please attach patch & get reviewed and super-reviewed? Then we can go to PDT.
The patch was already attached; r=attinasi; sr=buster.
Somehow I've managed to apply the patch by hand to the latest source tarball (mozilla-source.tar.gz 26063 Kb Fri Oct 13 10:03:00 2000) from the trunk. In case you want to try out the patch on linux without building mozilla, you can download http://www.ags.uni-sb.de/~afranke/mozilla/42525/libhtmlpars.so and just copy it into the components dir of a recent working mozilla installation, as a replacement for the existing library. This should work at least on Red Hat and SuSE linux, with todays nightly, M18 and Netscape PR3.
rtm++
Whiteboard: [nsbeta2-][nsbeta3-] → [nsbeta2-][nsbeta3-][rtm++]
four days now since ++. What's the holdup? Let's get this in before it gets minused.
Awaiting secondary review from harishd. I'll ping him again.
Am I misunderstanding the intent of the W3C in creating the transitional doctype? It seems to me that the comments at the top of the DTD are saying that the transitional DTD is meant as something authors can use while waiting for CSS support from browsers to increase. Why would an author then want the browser to render their document in strict mode if they had specifically chosen not to by specifying a transitional DTD?
Jerry, I suppose that you didn't read my previous explanations above. I think fixing this bug is in accordance with the W3C's intent for HTML Transitional. Summary of previous explanations: During the transition period (hence the name Transitional) from presentational HTML to style sheets, authors will want to get the benefits of the standards-compliant layout model (in the browser that support it) before they are willing to drop support for old browsers entirely. The goal in that case is not to make the page look identical across browsers. Rather, the goal is to make the page look great in CSS browsers and reasonably good in non-CSS browsers. Moving directly to HTML Strict would (usually) cause the page look bad in non-CSS browsers which is unacceptable to many authors during the transition period. On the other hand, staying with quirks would mean not getting the benefits of the standards layout in new browsers. For example, an author might want to use mainly the features of non-deprecated HTML and CSS but then also include deprecated presentational hints about the page color scheme and about floating images. The standards *layout mode* does not throw out deprecated code like (now removed) Strict *parser mode* did. If you want to use the quirks mode, you can do that easily by not using the doctype declarations that trigger the standards layout mode. However, the are others who want to use the standard layout in Mozilla and still provide presentational hints for old browsers.
I went through the patch with rickg yesterday ( 10/17/00 ). And everything looks fine. But, forgot to update the bug with r= info. So, here it is r=harishd.
*desperate whisper* please check this in before the pdt rtm-'s it. please. please. please. *end desperate whisper*
YAY..this just landed on the branch (4:15 PDT, 12:15 NZST) :-) Thanks, harishd for landing and rickg for fixing.
This bug, more than any other, scares me of being disparaged in the same breath (for the same reasons) as other (former) netscape employees.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Verified in 2000101908-MN6 Mac 2000101904-Mtrunk Mac 2000101821-Mtrunk Solaris Sparc rickg, harishd, many thanks for fixing & landing. And many thanks to everyone who helped in getting this fixed.
Hmm.. Apple's site ,which uses a transition 4.0.1, now has misaligned images in it's navigation bar. Check out www.apple.com. Rick, Should I reopen this or report a new bug ?
petersen, this is known, see above. File a bug in the Evangelization component.
I imagine you may want to make one bug that will cover all the related reports you will get as a result of this decision. It will be better than having scores of bugs for each site that will inevitably get reported to be "broken".
Status: RESOLVED → VERIFIED
Can someone write an final summary of what the new behavior now is with all the doctypes? For instance, how will doctypes for HTML 2 or 3.2 be handled? How will all available doctypes of HTML 4.0 and 4.01 be handled? How is XHTML handled with all available doctypes or without a any doctype? Just want to get a clear and final answer rather than try to interperet what has been said previously. Jake
http://lxr.mozilla.org/seamonkey/source/htmlparser/src/nsParser.cpp#579 is an overview about DTD handling. Is it up-to-date?
No it is not up to date. Mozilla was recently made to render HTML 4.01 Transitional with a URI pointing to the loose.dtd in standards mode as well.
SUMMARY ------- * The handling of this doctype <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> and the hypothetical later ie. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.02 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> was changed. * The changes are effective in builds from 2000-10-19 onwards * Among others, no doctype, HTML 2.0, HTML 3.2 and these doctype declarations trigger the quirks layout mode: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> * HTML 4.x Strict doctypes, XHTML 1.0 doctypes and this doctype <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> trigger the standards layout mode. * XHTML served as text/html without a doctype declaration isn't "strictly conforming" and triggers the quirks layout mode. * The metabug is bug 34662 * Minimal documentation is covered in bug 36045 * Comprehensive documentation is covered in bug 31932 Let's keep possible further discussion (eg. about XHTML details, ISO doctypes or content served as text/xml) off this bug report.
*** Bug 78076 has been marked as a duplicate of this bug. ***
I'm very close to undoing this fix -- see bug 98977 and duplicates. The main idea of our quirks mode decision is for identifying pages that didn't exist before we had significant presence on the web. Pages that trigger strict mode through the fix for this bug and therefore have problems are becoming more common.
David: Which doctypes in particular are you intending on changing? I noted Marc Attinasi's comments in Bug 102412, where he suggests that <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> should be rendered in quirks, and I strongly disagree. If that doctype is switched back to quirks, there will be no way to have a transitional document rendered in standards mode. This would disadvantage those who want to write standards-compliant documents for the benefit of those who continue to write nonconforming ones; this would seem to be contradictory to the goals of the Mozilla project. I believe that the more appropriate fix is Evangelism, to get them to fix the broken code. CCing attinasi to invite his comments.
dbaron, please, please avoid changing the standards-modeness of HTML 4.01 Transitional with the SYSTEM identifier. If there is no way to activate the standards mode for transitional, the cost for adopting standards becomes too high. Isn't the goal to help people move to standards? The real issue is bug 22274. The line-height behavior with table cells is completely counter-intuitive. If a compromise was made with bug 22274, there would be not need to protect folks from the standards mode. I know that you don't want to make any compromises with the standards mode, but what's the point if using the standards mode becomes so difficult that almost no one uses it? BTW, I've seen more XHTML 1.0 Transitional pages breaking due to bug 22274 than I have seen HTML 4.01 Transitional pages breaking due to bug 22274. Also, Mac IE 5 and Windows IE 6 go into their respective standards mode for HTML 4.01 Transitional with the SYSTEM identifier. That is an attactive choice for authors. If Mozilla goes into the quirks mode, then Mozilla will be the browser that appears non-compliant and causes problems. The problem is not the doctype. The problem is that a line box is generated when a table cell contains only an image (with no non-white space).
I'm agnostic on this - mostly. If evangelism can solve our compatibility problems while allowing us to do the 'right thing' from a standards perspective, then that is great. Otherwise, we have the compatibility vs. standards religious war on our hands.
Maybe an example would help. We need at least one loose doctype to be rendered in Standards mode. The one I have used is: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html401/loose.dtd"> I worked on a site where all the html I wrote would have been valid under the strict doctype, except for one area; setting the border on images. I would have done this is css, but, as I found out, NN4.xx reacts in incredibly nasty ways when any attempt is made to set styles on images such as width, height, and border. I also wanted to advertise the site as being valid and have the w3c html validator report no errors. If I used the Strict doctype, I would get the following error: Error: there is no attribute "BORDER" for this element (in this HTML version) However, using the Transitional doctype, I was able to avoid the error AND continue to have Mozilla/NN6.x (and presumably both IE6 and IE5 for Mac) display the page in standards mode while continuing to support NN4.xx (and IE5.x). Now, this may seem incredibly trivial, but if it wasn't for the availability of a transitional doctype that could trigger standards mode, I wouldn't have been able to have nearly seamless support for all modern browsers, have them all display the page with a consistent look and feel, AND pass w3c html validation with zero errors! The 4.01 Transitional doctype triggering Standards mode is pretty much a panacea for me. Please don't take it away otherwise my efforts to support standards AND provide legacy support will be for naught! Would you like to reward developers like me who sincerely try to support standards or the stupid bastards that wouldn't know a standard if it bit them in the ass? jake
I just found an MSDN link detailing exactly how IE6 and later do their DOCTYPE checking, and a lot of the differences between their compliant and non-compliant modes: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html/cssenhancements.asp
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: