Closed Bug 33443 Opened 25 years ago Closed 24 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: 24 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.