Closed Bug 91550 Opened 23 years ago Closed 23 years ago

The height attribute value for img tag is ignored

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED INVALID
Milestone:
mozilla0.9.4

People

(Reporter: momoi, Assigned: attinasi)

Details

(Keywords: intl, topembed)

Attachments

(3 files)

A minimum test case for img height problem -- 3px but displays like 16px on Mozilla.
395 bytes, text/html
Details
Illustrative testcase showing the impact of font-size on the cell's height, even if there is no text, in Standard Mode
1.18 KB, text/html
Details
Illustrative testcase showing the (lack of) impact of font-size on the cell's height if there is no text, in Quirks Mode
1.09 KB, text/html
Details 
** Observed with 7/19/2001 Win32 build **

I will attach a minimum test case but the problem is something
like this:

<img src="/images/common/clear.gif" width="3" height="3" alt="">

This is an image which creates a line divider on a page. The height
value is more like 16px, however, Mozilla while IE and Comm 4.x 
displays the height of 3px. 
This depends on DOCTYPE declarations.

I will attach a minimum test case below and different DOCTYPEs you can
use.
Compare the display with IE and Comm 4.x. Both display the
height as 3px.

Here are the DOCTYPEs under which Mozilla displays the height too tall:

1. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

2. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
            "http://www.w3.org/TR/html4/strict.dtd">

3. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">

Here are the DOCTYPEs under which Mozilla displays the height as 3px as
intended:

4. No DOCTYPE declaration 

5. <!DOCTYPE HTML PUBLIC  "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">

6. <!DOCTYPE HTML PUBLIC ""-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/1999/REC-html401-19991224/frameset.dtd">

7. <!DOCTYPE HTML PUBLIC  "-//W3C//DTD HTML 4.01 Transitional//EN">

8. <!DOCTYPE HTML PUBLIC ""-//W3C//DTD HTML 4.01 Frameset//EN">

Note in particular the difference between 1 and 5. I believe they are
both widely used DOCTYPE URLs.
Assignee: karnaze → attinasi
Take the attachment file and change the DOCTYPEs mentioned above and 
observe the differences.
Umm. Sounds bad. I'll look into it.
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.3
shanjian, do you think your comment in Bug 41461 might
explain this problem, too?
> shanjian, do you think your comment in Bug 41461 might
> explain this problem, too?

Maybe not. Changing the locale setting makes no difference
in the problem described here.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Keywords: intl, nsBranch
I think that the layout in both strict mode and quirks mode works as intended. 
One thing that surprises me though is that 5. and 6. triggers quirks mode.
I thought that any DOCTYPE with a "HTML 4.01" public id + a system
identifier would trigger strict mode. But this is perhaps what bug 61901 is
about. (Also, watch out for the double quote typos in 6. and 8.)
Keywords: topembed
We should at least agree on one thing. That is that the 
DOCTYPE #1 behavior is incorrect and this problem should be
fixed. DOCTYPE #1 should behave the same as DOCTYPE #5.
the problem seems in table code instead of in img code. 
I have no clue what this bug has keyword "intl", there are nothing related to 
international usage of html here at all. 
The reason for intl is this particular porblem was found on one
of our top Japanese sites and we would like to have this core problem
fixed.
We only run in two modes, Standard and Quirks. Problems with Doctypes causing
the wrong mode are covered elsewhere (bug 61901 for example). Using the Viewer
application I can switch back and forth between the two modes regardless of the
doctype, and the differences in the layout can be seen just going from Standard
to Quirks mode.

The height of the IMG is in fact correct. I changed the testcase to use a
colored image and you can clearly see that the height of the image is 3px in
either mode. The difference is in the cell padding around the image, and that
is, as Mats suggested, correct. I'll explain why I think it is anyway.

In Standard mode, the height of the cell is determined by the height of the line
in the cell, and that is determined by the height of the font, not the height of
the image. Setting the font-size on the TD element to 3px will size the cell to
3px high, but by default the font-size is larger (whatever your font-prefs
indicate, about 12pt usually).

In Quirks mode, we size the cell to the line height as well, but the line height
is determined by the height of the contents of the line, in this case the image.

So, the DOCTYPE problems are covered elsewhere, and the layout in Standard and
Quirks modes are correct, so marking INVALID. I will also attach another
testcase showing how the line height is handled in Standard mode since it is not
totally obvious.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Marc, thanks for the analysys.
My concern for the problem mentioned in this report can be
addressed in Bug 61901 as long as it has the right target date.
By the way, giving the foregoing dicsussion, this bug could
have been marked as a duplicate of Bug 61901.

In fact, that is exactly what i will do now.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---

*** This bug has been marked as a duplicate of 61901 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
I'm going to re-open this bug. I understand from comments in 
Bug 61901 that the same issue was discussed in Bug 22274.
We have a practical problem -- IE5.5/IE6/Mac IE5 don't behave
like Mozilla with regard to the test case. Whether or not Mozilla
is correct, we will continue to see this problem. As long as there is
possibility that the spec followed by IE may also have a point, 
this will continue to be a problem for Mozilla and we may have a
hard time convincing web developers that they should fix their 
site. 
I want this issue revisited.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Why is behavior on a test case a practical problem?  Are there lots of web pages
that are triggering strict mode that aren't ready to be?  If so, maybe we need
to revisit some of our quirks/strict decisions.
I believe that the action should be on bug 61901 - not here. The problem that
was reported here is really just a case of the doctype triggering the wrong
layout mode. There is not a problem with the height of images being ignored, or
of any layout deficiency.

I agree we need to revisit the general problem, but isn't bug 61901 the place to
do it? I do not understand why this bug was first marked a dup of bug 61901 and
then reopened for furether investigation when the analysis is, I believe, complete.

I recommend getting bug 61901 assigned to an owner that is working on the
project (rickg has resigned) and promote it to topembed. I also suggest marking
this bug INVALID or a DUP and closing it.
Sorry - I just read the recent comments in bug 61901 and I now understand why
this bug was reopened. I still think it is the wrong approach, however, but I
guess the issue needs to be hashed-out somewhere.
I read bug 61901.
I read this bug.
I don't understand why this bug was reopened. 

In standards mode, we are following the specs perfectly, *significantly* better
than any other browser on the market. No other browser comes close to getting
the inline box model correct, like we do.

In quirks mode, we are following the popular browsers very closely. Pages render
fine in quirks mode when it comes to the issue being discussed herein.

If this bug is open because IE has a bug in *their* standard mode which is
causing *them* to render pages *incorrectly* then that's *not our problem*.
The line has to be drawn somewhere, and it is being drawn on the standard mode
vs quirk mode boundary.

This bug is INVALID.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → INVALID
Ian, thanks for your comments. 
I expected you and emeyer to stick to the
position you described above. I am currently 
studying the following page at MSDN:

http://msdn.microsoft.com/library/default.asp?url=/workshop/author/css/overview/CSSEnhancements.asp

The description here looks promising and may give us a way
out of the dilemma I see. I would like to see what the IE6-RTM
looks like. Hopefully that would be within a few days. 
I will then respond to your and Marc's comments. Thanks.
IE6-RTM behaves exactly like IE 5.5 I reported above. There is
no change here. We continue to have the same problem if web
developers keep on using IE 5/6 as the test targets. Sigh ...
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: