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)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: hsivonen, Assigned: rickg)

References

Details

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

Attachments

(4 files)

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.
Keywords: 4xp, compat
Blocks: 34662
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, compatnsbeta2
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
Marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 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 ago24 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 ago24 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 ago24 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.
Bug 57371 tracks the Apple issue.
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

Created:
Updated:
Size: