Last Comment Bug 33443 - IMG HEIGHT="xxx%" doesn't work under all circumstances
: IMG HEIGHT="xxx%" doesn't work under all circumstances
Status: RESOLVED WORKSFORME
: compat, testcase
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: P3 normal with 1 vote (vote)
: Future
Assigned To: Stuart Parmenter
: Chris Petersen
:
Mentors:
http://test.sieb.net/pictest.html
: 3916 57766 58502 63138 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2000-03-27 10:19 PST by dl001i
Modified: 2001-05-20 13:50 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description dl001i 2000-03-27 10:19:09 PST
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>
Comment 1 Chris Siebenmann 2000-05-02 18:45:26 PDT
 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.)
Comment 2 Peter ``jag'' Annema 2000-05-02 20:40:45 PDT
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.
Comment 3 rickg 2000-05-03 22:48:42 PDT
Waqar: I think you took img issues from buster, right? 
Comment 4 waqar 2000-05-05 16:51:18 PDT
Accepting the bugs
Comment 5 Chris LaRosa 2000-05-11 12:05:42 PDT
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.)".
Comment 6 Peter ``jag'' Annema 2000-05-11 20:48:25 PDT
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]
Comment 7 Sitsofe Wheeler 2000-05-19 14:45:59 PDT
This might be related to bug 3916...
Comment 8 Hixie (not reading bugmail) 2000-05-20 03:22:12 PDT
*** Bug 3916 has been marked as a duplicate of this bug. ***
Comment 9 Hixie (not reading bugmail) 2000-05-20 03:27:55 PDT
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/
Comment 10 waqar 2000-06-12 16:11:21 PDT
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.
Comment 11 waqar 2000-06-16 15:33:49 PDT
FOrgot to set the milestone.
Comment 12 James Lariviere 2000-10-30 13:00:21 PST
*** Bug 57766 has been marked as a duplicate of this bug. ***
Comment 13 James Lariviere 2000-10-30 14:23:44 PST
*** Bug 58502 has been marked as a duplicate of this bug. ***
Comment 14 Doron Rosenberg (IBM) 2000-10-30 14:45:14 PST
new url testcase from bug 58502
nominating for mozilla0.9
Comment 15 Fabian Guisset 2001-01-04 10:23:03 PST
*** Bug 63138 has been marked as a duplicate of this bug. ***
Comment 16 Stuart Parmenter 2001-05-20 13:49:44 PDT
imglib
Comment 17 Stuart Parmenter 2001-05-20 13:50:28 PDT
worksforme

Note You need to log in before you can comment on or make changes to this bug.