Bugzilla

Comment 1

•

20 years ago

Attached file minimal testcase (obsolete) — Details

Outer div is position:absolute. Inner div (yellow) has width:100% and
height:100%.
In IE, the inner and outer divs are displayed at 100% height and width of the
viewport (minus margins).
In Firefox (and Safari), the inner div shrink-wraps it's content (and the outer
div shrink-wrpas the inner one).

Updated

•

20 years ago

Component: Layout → Layout: R & A Pos

Keywords: qawanted → testcase

OS: Windows XP → All

QA Contact: core.layout → core.layout.r-and-a-pos

Hardware: PC → All

Comment 2

•

20 years ago

Rewrote summary.

This appears to be correct CSS2.1 behaviour.  According to section 10.3.7 of the
standard

   http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width

the absolutely positioned <div> element should have shrink-to-fit width with
left margin as for static positioning, and it does.  Ditto for its height.

In the original URL, the inner element was an <embed> with width and height
attributes (of 100%) rather than another <div> with CSS width and height, which
makes things a little more ambiguous, but a little experimentation suggests that
these attributes are being interpreted, reasonably enough, as a percentage of
available space within the previously constructed <div> box (with width forced
to be at least the minimum for embeds of 240 pixels).

So, there's probably no bug to fix here, unless it's a new "quirk", though Tech
Evangelism might be in order.

I'm going to mark this bug NEW, since the issue is clearly real and verifiable.
 Can someone with some more layout expertise confirm my assessment and mark this
bug INVALID, reassign it to Tech Evangelism, or take some other appropriate
action?  Thank you!

URL: http://www.aldingtoncraigandcollinge....

Status: UNCONFIRMED → NEW

Ever confirmed: true

Summary: http://www.aldingtoncraigandcollinge.co.uk/ behaves wrongly when displayed in the browser → <embed width="100%" height="100%"> (or similar element) inside absolutely positioned <div> doesn't fill browser window

Comment 3

•

20 years ago

The thing is, we have a quirks-mode only thing to emulate IE's behavior.  And
the problem is that on other testcases, it looks like IE's percent heights don't
cross absolutely positioned element boundaries (see bug 221784 and testcases
therein).

So what exactly is IE's behavior?  How to reconcile the testcase in this bug
with the testcases in bug 221784?

Comment 4

•

20 years ago

Attached file page showing buggy IE6 behaviour on this issue — Details

Turns out IE6 (version 6.0.2900.2180.xpsp_sp2_rtm.040803-2158) behaviour is
buggy on this issue.  Try rendering the attached HTML in IE6.  The grey
<applet>'s width is 75% of the white <div>'s width which is 75% of the browser
window.  (<applet> can be replaced with <img> with same results.)

That is, IE appears to be taking the missing width for the absolutely
positioned element from the *child* element, taking it to be "75%" verbatim
(and so 75% of the browser window).  Since the applet width is also "75%", it
becomes 75% the width of its containing element and so 75% of 75% of the
browser window.

If I add additional <applet> elements with fixed or percentage sizes, things
get even more bizarre, so I can't guess what IE's algorithm is ultimately
doing.

Comment 5

•

20 years ago

Hmm... so a 50% width/height <applet> in an abs pos div with auto width/height
will end up 25% of the width/height of the viewport in IE6?

Comment 6

•

20 years ago

Yes for width, but height is handled differently.  For example,

<html><body style="background: black">
<div style="position: absolute; height: 90%; background: white; border: solid red">
<applet height="50%" width="50%">
</div>
</body></html>

produces an applet that's 25% the width of the viewport and 45% the height. 
However, change "height: 90%" to "height: auto" and the border shows the box has
collapsed to zero height.

This resembles the height:auto and width:auto calculations for absolutely
positioned elements from CSS2 (revision 0), where the width and height were
supposed to expand to the size of the initial containing block (here, the width
of the viewport but the height of zero, since there's no other content to grow it).

Comment 7

•

20 years ago

Attached file improved testcase — Details

This is the same as my first testcase, but retaining the "height:90%" on the
outer div. This demonstrates that this bug is actually about width (whereas bug
221784 was about height).
Still seems to me that there is no need for an embed/applet to demonstrate this
- the issue is basically the same with a simple div, using CSS height/width.

Attachment #168349 - Attachment is obsolete: true

Comment 8

•

20 years ago

So... in the testcase in comment 1, what is IE's rendering?  Is it 100% height?

Frankly, the width thing is not so interesting to me; we don't plan to try to
emulate that brokenness.  But I'd like to sort out exactly what's going on with
height.

Comment 9

•

20 years ago

Yes, in the first testcase, IE5/Mac renders 100% height (with white margins). I
don't have access right now to a Windows machine, so you might want to ask
someone to verify that on IE/Win (or I can do it next week).

However, as I said, the problem with the site on which this bug was originally
filed is the width, not the height.

Comment 10

•

20 years ago

Ha ha ha...

Well, on the first testcase attachment (id=168349), the version of IE6 for
Windows XP mentioned in comment #4 renders a yellow box with 100% (except for
small white margins) width and just high enough for the text.

(On the testcase attachment (id=168398), the yellow box is (nearly) full width
and about 90% height with white margins.)

Comment 11

•

20 years ago

Oh.  IE/Mac.  IE/Mac has a totally different rendering engine from IE/Win...

Marking invalid, since our rendering is correct.  As Kevin points out, IE is
implementing an old CSS proposal that's since been superceded.

Status: NEW → RESOLVED

Closed: 20 years ago

Resolution: --- → INVALID