Closed Bug 61901 Opened 24 years ago Closed 23 years ago

[DOCTYPE] Layout different despite transitional doctypes that point to same DTD

Categories

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

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

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: lists, Assigned: harishd)

References

(
URL
)

Details

(Keywords: testcase, Whiteboard: [Hixie-P4])

Two pages differing only in the text of the doctype line are rendered differently by Mozilla M18 (2000-11-30-08-Mtrunk). The loose.dtd pointed to in each doctype is reported as being exactly the same using a diff command. These differences seem to be caused only by Mozilla's interpretation of the doctype line. See URL for examples. This report results from chasing a bug in the rendering of HTML Tables, and I've used a copy of the test case submitted in bug 55850.
Assignee: clayton → harishd
Status: UNCONFIRMED → NEW
Component: Layout → Parser
Ever confirmed: true
OS: Mac System 8.6 → All
QA Contact: petersen → janc
Hardware: Macintosh → All
(Note: The indicated build is not really the M18 build. This issue is still current.) A HTML 4.01 Transitional doctype declaration with the usual URI (http://www.w3.org/TR/html4/loose.html) activates the standards layout mode as expected. However, a HTML 4.01 Transitional doctype declaration with a more rare URI (http://www.w3.org/TR/1999/REC-html401-19991224/loose.html) activates the quirks mode. The latter URI should also be acceptable according to http://www.w3.org/TR/html4/struct/global.html#h-7.2
Blocks: 34662
This is, again, because of the incorrect heuristics used in DetermineParseMode that I've been arguing against for months: if(IsLoosePI(aBuffer,thePrefix,25)) searches for strings such as "loose" in the first 25 characters after "http://www.w3.org/tr/"
This error must be fixed a.s.a.p. And 'arguing against' does not help, as it seems. Sorry, but who is responsible for this typo? Looks like a simple fix to me.
I've been arguing against it because I'm not the maintainer of the code. The maintainer of the code (rickg) believed, the last time I asked him, that it is fine as is. He argued (roughly) that if there weren't any common DOCTYPE declarations where it gave the wrong results, then I shouldn't worry about the code being wrong. And, BTW, I did more than argue against it. I submitted a patch (in bug 44340) which was, a few weeks before I filed the bug (when I had sent it to rickg via email), a complete and working patch, although the code was rapidly changing under me. Fixing this one line might be easy (but it might not -- how would you propose fixing it?). However, there are lots of other problems of this sort, and fixing the whole thing requires a bit of work. I've been planning to do it when I have time, as you might notice by my recent comments in bug 44340 and bug 55916.
Giving bug to rickg.
Assignee: harishd → rickg
updated qa contact.
QA Contact: janc → bsharma
Keywords: mozilla1.0, testcase
Whiteboard: [Hixie-P4]
*** Bug 91550 has been marked as a duplicate of this bug. ***
I would like this problem to be fixed for 0.9.4. We have some web sites which believe that they are using quirks mode but in fact is treated to be in strict mode by Mozilla. Here's the DOCTYPE that fails and this is causing layout problems: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> This is treated as a strict mode declaration even though this is a known quirks mode declaration. (Just click on the link and see for yourself.) See the testcase in Bug 91550. Re-assigning to harishd.
Assignee: rickg → harishd
Keywords: nsBranch, topembed
I think it was actually intended that 4.01 transitional with a system identifier would trigger strict mode, but maybe we should revert that...
> This is treated as a strict mode declaration even though this is > a known quirks mode declaration. (Just click on the link and > see for yourself. Gerv and I tested IE 5.5 and IE6-beta and they both interpret this as a quirks mode. Though our interpretation might be correct, we are facing a practical problem if web designers use IE5/6 as the testing standard. This probelm surfaced in one of the top 100 Japanese sites. I will provide the URL later.
How did you determine whether IE6 was using strict mode or quirks mode. (IE 5.5 didn't have modes, I don't think. One good test for the modes in IE6 should be inheritance into tables. The inline box model won't test it in IE6, though, I don't think.)
> How did you determine whether IE6 was using strict mode or quirks mode. A good point. I don't know the answer to this question. However, we can tell that the inline image in the test case for Bug 91550 inherits the image height from the surrounding text unless the font size is specified for the TD element. Mozilla has 2 different sets of behavior with regard to this test case, the image shows as 3px in height (quirks mode), or the image shows as 16px in height (like the surrounding text) -- strict mode. IE 5/6 behaves as the latter. What do we call this behavior of IE?
> IE 5/6 behaves as the latter. What do we call this behavior > of IE? Correction. The above text should read as: "IE 5/6 behaves as the former."
CC'ing Gerv.
Please, please, don't make <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> activate the quirks mode. We need a way to activate the standards mode for transitional docs. See bug 42525. Besides, that doctype has been activating the standards mode since last November and it also activates the standards mode in Window IE 6 and Mac IE 5. There are people who are knowingly using this doctype in order to activate the standards mode. If the line box sizing with images is a topembed problem, please address that particular problem instead on making the doctype all quirky. See bug 22274.
> If the line box sizing with images is a topembed problem, please > address that particular problem instead on making the doctype all > quirky. See bug 22274. I am confused. I think there is a problem of line height for inline images. But in 91550, Marc says that Mozilla is behaving correctly in standard mode and Quirks mode, and he further says that the image height soudl display as 3px in the test case there in the Quirks mode but as 16px in the standard mode. Well, we tested Win IE 6 and Mac IE5, and both display the image height as 3px using the DOCTYPE I mentioned above. So one or the other analysis wrong if we believe that IE6 or Mac IE5 recognizes the cited DOCTYPE to be in the standard mode. Either 1) the DOCTYPE I cited is not a standard mode and the image height problem in Mozilla is due to this, or 2) the image height problem should not be affected by the DOCTYPE I cited above at all, and the problem is somewhere else. In this case, I need to re-open Bug 91550. Then there is a 3rd possibility -- Win IE6 and Mac IE5 is incorrect in dealing with the DOCTYPE cited and Mozilla is correct. I need a resolution to this problem conlusively. Is the image height problem an evangelism issue or a bug? There is also the practical issue, many sites test with IE and if the layout is OK with IE and not OK with Mozilla, we have a practical problem. Marc, if the image height problem is not a DOCTYPE issue, I need a real answer to the problem.
Bug 91550 is, in fact, a dup of bug 22274. * The doctype <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> activates tha standards mode in Mozilla, Netscape 6.0, Netscape 6.1, Windows IE 6 and Mac IE 5. Whatever you do, please, please, avoid changing that. (Mozilla has been doing this since 2000-10-19. I said "November" in my previous comment, but that was inaccurate by a couple of weeks.) * The above has been documented - About Mac IE 5 by Eric Meyer on O'Reilly Network shortly after Mac IE 5 was released and later by me at http://www.hut.fi/u/hsivonen/doctype - About Mozilla by me at http://www.hut.fi/u/hsivonen/doctype and later in the Bugzilla Helper. - About Netscape 6.x at http://www.hut.fi/u/hsivonen/doctype and on DevEdge online. - About Windows IE 6 on MSDN. - Plus is various documents and newsgroup postings linking to one of the above. * The real problem here is bug 22274. The particular unwanted case of line-height and image height interaction only occurs in the standards mode of Mozilla. It does *not* occur in the standards mode of Mac IE 5 or in Opera. I can't check Windows IE 6 at the moment. * The image/line-height interaction problem has been deemed not-a-bug by David Baron and Ian Hickson, which is why the behavior persists. I don't disagree with them about the interpretation of the CSS2 spec, but I think in practice the result causes headaches to unsuspecting designers, which is why I filed bug 78208. * There is an extremely simple solution to the image height / line-height issue: http://www.hut.fi/u/hsivonen/standards#the-solution
Forgot to mention: Given the resolution of bug 22274, this issue has been handled as an evangelism issue for quite some time now.
Sorry, I made a serious copy/paste mistake above. I pasted the wrong doctype. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> activates the *quirks* mode in Mozilla. (But standards in Windows IE 6 and Mac IE 5.) <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> activates the *standards* mode. (Notice the version number.) Please avoid changing the behavior of the doctype with version 4.01.
henri, thank you for the additional info. I also get your suggesiton on hw to fix the problem. For the time being, I am going to drop the DOCTYPE issue. I've removed topembed kewyword. But I have not decided what to do with the image height issue. It seems unrealistic for us to keep on ignoring what other browers do in that case.
Keywords: topembed
Following standards and following what other browsers do are very different. In Standard mode, we follwo the standards, as published. In Quirks mode, we follow the leading browsers if it is important. Pusing the quirks of existing browsers into Standard mode seems a big mistake to me. This can only cause the standards to become meaningless.
Kat: We *don't* ignore what other browsers do. We do almost EXACTLY what other browsers do, in quirks mode. That's what quirks mode is about. If our standard mode is more standards-compliant than their standard mode then TOUGH. Web authors can use quirks mode. Microsoft have already followed our lead on many issues where we have taken a stand -- just look at the improvements in IE6-pre. There is no reason to think that they won't eventually implement the inline box model correctly in their standard mode too.
*** Bug 91706 has been marked as a duplicate of this bug. ***
The summary of this bug is no longer true since I checked in the fix for bug 55264 at 2001-09-08 11:37 PDT. Do we want to do anything about this bug? I suggest that we probably should not (see bug 42525 and bug 22274, although in the new code having an empty internal subset would probably also be a satisfactory solution for bug 42525).
Now that the fix for bug 55264 fixes this one, too, I think this one can be marked FIXED. (Requiring the use of an empty internal subset in order to make a transitional doc be rendered without quirks would probably make doctype sniffing even more confusing to authors than it is now.)
Agreed. Marking this fixed. Hurray! FOR GREAT DOCTYPE SNIFFING.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 100017 has been marked as a duplicate of this bug. ***
QA Contact: bsharma → moied
You need to log in before you can comment on or make changes to this bug.