Closed Bug 33443 Opened 24 years ago Closed 23 years ago

IMG HEIGHT="xxx%" doesn't work under all circumstances

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: dl001i, Assigned: pavlov)

References

(
URL
)

Details

(Keywords: compat, testcase) 

Using Build: 2000031508

According to the HTML 4.01 specs regarding the Height (and width) attributes of 
the IMG tag,
"...lengths expressed as percentages are based on the horizontal or vertical 
space currently available, not on the natural size of the image, object, or 
applet."

Now, while this isn't entirely clear, I think that the majority of content, as 
well as browser, developers would agree to the following points:
"available space" refers to the width or height of the parent element, minus 
any style-defined padding, and the space that other content above of below the 
image occupies.
In the event that the IMG is a direct decendant of the <BODY> tag, it should be 
the height or width of the current browser window (again, minus any padding.)

Well, Mozilla is kinda funky about this when it comes to the Height attribute.  
Under certain circumstances, it will behave exactly as I have described.  
Examples are, when it is placed within a DIV tag with a predefined height, an 
IMG with a %-based height will scale to the available vertical space in the 
DIV.  However, when an identical IMG tag is placed in a table within a TD with 
a predefined height, it behaves exactly as the w3c says it shouldn't - that is, 
it is displayed at the image's actual height.
IMGs with %-heights also render at their actual height when positioned as 
direct children of the BODY element.

(Internet Explorer renders these as it is supposed to.  if you view my sample 
page (http://malsyned.resnet.rochester.edu/other/test.html) with both IE and 
Mozilla, you can see the difference.)

Also, all of these observations are turned on their ass in wholely 
unpredictable ways when the heights are specified with the HEIGHT attribute 
instead of using STYLE="height: xxx%".

Steps to reproduce:
1.  Make a table
2.  Make a TD with a height set to a specific value
3.  Put an IMG inside it with a height defined in terms of %

Aditional Information:
Mozilla doesn't appear to have the same problems with Widths defined in terms 
of %s.  I haven't tested how it deals with other nesting combinations involving 
Height=%, only <BODY><IMG>, <DIV><IMG>, and <TABLE><TR><TD><IMG>
 On a current CVS build (pulled just before the tree opened today)
for Linux, the test page renders as described by the reporter. (I
can't say if the behavior is wrong by the spec, but it does still
render that way.)

 Platform/OS changed to All/All on the strength of this happening
under Linux too.

(I apologize if any of this is wrong; sages on #mozillazine suggested
it was right to confirm this bug without being sure of what the spec
said should happen, due to the bug's age.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
Here's where the quote 
comes from: http://www.w3.org/TR/html4/struct/objects.html#h-13.7.1

I disagree with the original bug report on one point:
"In the event that the IMG is a direct decendant of the <BODY> tag, it should be 
the height or width of the current browser window (again, minus any padding.)"

As expressed in the quote: "... based on the horizontal or vertical space 
currently available", 'space currently available' refers to the space available 
taking other content into account.

In the simple case of a html consisting of a line of text, an image with height 
100%, and another line of text, both lines should be visible and the image 
should be as tall as possible. Sizing down the browser implies sizing down the 
image up to and including 0px.

What to do if the "other content" on its own is taller than one browser height?
Well, the question is, what is the "current space available"? 
Consistency dictates it to be 0px; if you size down the above example to where 
scrollbars appear, the image shouldn't pop back in any form, but keep being 0px 
high.
Waqar: I think you took img issues from buster, right?
Assignee: rickg → waqar
Accepting the bugs
Status: NEW → ASSIGNED
Target Milestone: --- → M18
I agree with the original bug report and disagree with the comments by Peter 
Annema for the following reason:  The percentage HEIGHT attribute was 
originally defined for Netscape 2.0, and the HTML 4.0 spec is simply trying to 
formalize this specification.  Therefore, Mozilla should maintain the original 
functionality of the percentage HEIGHT attribute as it was implemented in prior 
versions of Netscape (and later in Internet Explorer).  I think one of the 
goals of the HTML 4.0 spec was to maintain compatibility with existing 
implementations whereever possible.  Changing the behavior of existing 
attributes would break existing web pages unnecessarily.  I think that the 
original statement is correct:  "In the event that the IMG is a direct 
decendant of the <BODY> tag, it should be the height or width of the current 
browser window (again, minus any padding.)".

You're right, Chris. Of course Mozilla shouldn't break current pages. However, 
there is an inconsistency between how images inside a div or table, and images 
directly as child of a body are dealt with. An inconsistency which doesn't make 
sense to me.

I propose therefore that in NavQuirk mode (currently all documents which 
don't have their DTD set to HTML 4.0x Strict) the original report's advice be 
followed to keep compatibility with existing pages, while in HTML 4.0x Strict 
mode <table>s, <div>s and <body>s are dealt with equally, like 
dl001i@mail.rochester.edu put it:
'"available space" refers to the width or height of the parent element, minus 
any style-defined padding, and the space that other content above of below the 
image occupies.' [and of course left and right of the image]
This might be related to bug 3916...
*** Bug 3916 has been marked as a duplicate of this bug. ***
Our behaviour in strict/standard mode is fine. That is, we are treating the
HEIGHT attribute of the IMG element just like the "height" property in CSS.
For simple consistency, this is IMHO the best solution.

However, in quirks mode we are not doing the same as Nav4. According to CSS, if
the parent element has a height of 'auto', then percentage heights on child 
elements should also be treated as 'auto', but in NavQuirks mode we should be 
treating percentage values for 'HEIGHT' of elements that are children of BODY
to be relative to the viewport height.

I think. I haven't checked carefully.

See also: 
   http://slip/projects/marvin/html/img_height_percent.html (Netscape intranet)
   http://www.thing.net/~flux/
Component: HTML Element → Layout
Keywords: compat, testcase
This bug has been marked "future" because the original netscape engineer working
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way
-- please attach your concern to the bug for reconsideration.
FOrgot to set the milestone.
Target Milestone: M18 → Future
*** Bug 57766 has been marked as a duplicate of this bug. ***
*** Bug 58502 has been marked as a duplicate of this bug. ***
new url testcase from bug 58502
nominating for mozilla0.9
URL: http://malsyned.resnet.rochester.edu/... → http://test.sieb.net/pictest.html
Keywords: mozilla0.9
*** Bug 63138 has been marked as a duplicate of this bug. ***
imglib
Assignee: waqar → pavlov
Status: ASSIGNED → NEW
Component: Layout → ImageLib
QA Contact: petersen → tpreston
worksforme
Status: NEW → RESOLVED
Closed: 23 years ago
Component: ImageLib → Layout
QA Contact: tpreston → petersen
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.