Steps to reproduce: 1.Launch the Mozilla1.4 2.Open http://www.mozilla.org/quality/browser/front-end/testcases/oji/test7.html. 3.The applets with height=10% or 5% or 3% can't work as relative "height" attriibute.
regression from April 8 2003 to April 15 2003. see #191246
Severity: normal → major
Priority: -- → P2
regression from April/11 2003 to April/12 2003 (layout/html/base/src/nsObjectFrame.h and layout/html/base/src/nsObjectFrame.cpp). see #191246 It is do absolutely relate to patch: http://bugzilla.mozilla.org/attachment.cgi?id=119582&action=view Please check it asap. Thanks!
Depends on: 191246
Wrong component, and as I said, we should only "fix" this if it's breaking a lot of sites out there -- the behavior the testcase claims is "correct" is not correct per the CSS spec.
Assignee: position → block-and-inline
Component: Layout: R & A Pos → Layout: Block & Inline
Priority: P2 → --
Is this the same as bug 208550?
*** Bug 208550 has been marked as a duplicate of this bug. ***
As has already been said, this is invalid. A quirk could be implemented, but only if significant numbers of real-world sites depend on it.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID
*** Bug 224187 has been marked as a duplicate of this bug. ***
*** Bug 224129 has been marked as a duplicate of this bug. ***
> I don't use any CSS in my page You use the "height" attribute. Mozilla is a CSS browser -- presentational attributes in HTML are mapped into equivalent CSS. Hence you are effectively using "height: 100%" on that element. > CSS spec saying height should not work in this case. It does work. A percentage height will be that percentage of the parent height ... unless the parent height is "auto". In that case, percentage heights are treated as "auto". This is clearly described at http://www.w3.org/TR/CSS21/visudet.html#propdef-height So if the parent has no explicit height, "height: 100%" is equivalent to not specifying a height at all. Now we realize that a lot of sites depend on the NS4/IE way of doing this. Which is why we violate the CSS spec in quirks mode to make this work. But your page claims to be XHTML (not that it's well-formed XHTML, mind you), which is a recent enough doctype that the page author should be aware of the CSS specification and the way CSS layout works, and hence we use standards-compliant layout on that page.
> So if the parent has no explicit height, "height: 100%" is equivalent to not > specifying a height at all. ...which means the default, "auto" is taken. But "auto" doesn't mean the browser should take some random value: "The height depends on the values of other properties." Unspecified values are treated as 0, so the auto-result (window height minus border, top, bottom etc.) should be the same as window height, shouldn't it?
<applet> is a replaced element. So auto height means intrinsic height. See http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-height What is the intrinsic height of an <object>? Intrinsic means it should be completely independent of the rest of the page layout.... So the rendering should be identical to the rendering when height is not specified at all (see comment 10 again). If we had a way to ask the applet for an intrinsic height, we would, but we don't. So we do in fact have to just make up an intrinsic height. For compat reasons, the intrinsic height is 240px for <applet> and <embed> and 0 for <object> (since that's what IE does if you set no height attr).
Also note that I don't know where the "window height minus border, top, bottom etc." comes from... The parent of the <object> is <body> and the height of <body> is auto (and certainly not window height).
*** Bug 226315 has been marked as a duplicate of this bug. ***
This is not helpful behavior. If a page has no real height then frames specifying a 50% or 100% height would not work either. There would be no point in specifying a height in percent for any object. This is a nonsense, surely in this type of case the height should be taken to be the height of the browser window. As a matter of interest I have added the applet to a table with a fixed height, one would expect the percentage height to work as the height is now known. Unfortunately this sets the height to 240 as well. <table width="100%" height="500"> <tbody> <tr> <td> <b>applet height=10%</b><br> <applet align="left" height="10%" width="400" code="JitterText.class" codebase="."> </applet> </p></ul> </td> </tr> </tbody> </table>
*** Bug 277294 has been marked as a duplicate of this bug. ***
Just to complement this bug. The 2 testcase-webpages <object> with relative height: http://www.mozilla.org/quality/browser/front-end/testcases/oji/objtest7.html and <applet> with relative height: http://www.mozilla.org/quality/browser/front-end/testcases/oji/test7.html have been updated according to explanations provided in comment #10 and comment #12 in this bug. See bug 392221 for more info.
> <object> with relative height: > http://www.mozilla.org/quality/browser/front-end/testcases/oji/objtest7.html Now: http://www-archive.mozilla.org/quality/browser/front-end/testcases/oji/objtest7.html > and > <applet> with relative height: > http://www.mozilla.org/quality/browser/front-end/testcases/oji/test7.html Now: http://www-archive.mozilla.org/quality/browser/front-end/testcases/oji/test7.html
You need to log in before you can comment on or make changes to this bug.