279940 - iframe width handled incorrectly

Status: RESOLVED INVALID

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[Peter L Jones]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050126 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050126 Firefox/1.0+

Example page is rendered with a horizontal scrollbar
(see http://www.drealm.org.uk/ff/hzsb_1.png and
http://www.drealm.org.uk/ff/hzsb_1.png for screen shots, the latter with the
vertical height reduced so that the vertical scrollbar appears).

HTML source validates as XHTML1.0 transitional and CSS compliant.

Reproducible: Always

Steps to Reproduce:
1. View http://www.drealm.org.uk/ff/trivial.html in current Firefox with browser
window maximized or not.

Actual Results:  
Unexpected horizontal scrollbar displayed.

Expected Results:  
Page should render within the available space.

Previously reported against bug
http://bugzilla.mozilla.org/show_bug.cgi?id=147981

Comment 1

[Peter L Jones]

Sorry: second png should be http://www.drealm.org.uk/ff/hzsb_2.png

Comment 2

[Boris Zbarsky [:bzbarsky]]

That's the correct layout, given the 2px border on iframes.

See section 4.1.2 of the CSS1 spec
(http://www.w3.org/TR/REC-CSS1#horizontal-formatting):

   The horizontal position and size of a non-floating, block-level
   element is determined by seven properties: 'margin-left',
   'border-left', 'padding-left', 'width', 'padding-right',
   'border-right' and 'margin-right'.

thus implying that "width" does not include border, padding, or
margin.  Further, CSS2 (at
http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-width) explicitly
says:

     This property specifies the content width of boxes generated by block-level
     and replaced elements.

And at http://www.w3.org/TR/REC-CSS2/box.html#box-dimensions the
specification pretty clearly says that "content width" means "not
including margin/border/padding".

Furthermore, see http://www.tantek.com/CSS/Examples/boxmodelhack.html.
This page was created by one of the members of the CSS working group,
who also happens to be the technical lead of the Mac IE team.  The
page describes what the correct behavior is and further illustrates a
hack to get IE5/Windows and IE5.5/Windows to do the right thing
(basically, by giving them rules that actually set the wrong width).
IE6, like Mozilla and MacIE, has two rendering modes -- your page
triggers the "BackCompat" mode in which its rendering is broken.  In
its "CSS1Compat" mode it will render your page just like Mozilla does.
See
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/compatmode.asp
for more information on that.

Comment 3

[Peter L Jones]

Also for clarity, http://www.w3.org/TR/REC-CSS1#width states that percentages in
width refer to parent element's width -- which explicitly excludes any margin or
padding of *this* element.

Using a value of "auto", however, does not produce the desired effect.  It would
be nice if this cause the margins to be zero and the width to be the remainder
after removing the padding.

http://www.w3.org/TR/REC-CSS1#margin-right
margin-right is initially zero (if not specified, as here).
http://www.w3.org/TR/REC-CSS1#margin-left
margin-left is initially zero (if not specified, as here).
http://www.w3.org/TR/REC-CSS1#width
width is initially auto.

> If exactly one of 'margin-left', 'width' or 'margin-right' is 'auto', the UA
> will assign that property a value that will make the sum of the seven equal
> to the parent's width.

This _should_ mean that "auto" gets an iframe that fills the parent less
border-left and border-right widths.  However, the result is that the width is a
small fraction of the parent width.

See
http://www.drealm.org.uk/ff/trivial_auto1.html (explicit auto)
http://www.drealm.org.uk/ff/trivial_auto2.html (implicit auto)

Comment 4

[Peter L Jones]

Ah... CSS2 states that for a replaced element (which I believe an IFRAME is),
the default width when "auto" is used is the "intrinsic width", which I agree
could be anything...

Making it work like a non-replaced element (i.e. the intrinsic width being
calculated to fill the available horizontal space) would be useful, although
browser-dependent (hence not really useful at all).

Would I therefore be right in thinking there is no way to tell a CSS2 browser to
make an IFRAME the width of the horizontal space after whatever border is in
effect is removed (without _knowing_ what stylesheet might be overriding the
local style definitions)?

Comment 5

[Peter L Jones]

Attachment: iframe auto with content width specified

Comment 6

[Boris Zbarsky [:bzbarsky]]

That's correct, for a CSS2 browser.

For Mozilla in particular, you can use "-moz-box-sizing: border-box" on the
iframe.  This is a proposed CSS3 property, and may well not make it into the
spec (and then may end up being removed from Mozilla, who knows).