WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED INVALID
14938
absolute positioned DIV w/ single float:right child is sized to its children. bug?
https://bugs.webkit.org/show_bug.cgi?id=14938
Summary
absolute positioned DIV w/ single float:right child is sized to its children....
Darin Fisher (:fishd, Google)
Reported
2007-08-10 19:10:14 PDT
absolute positioned DIV w/ single float:right child is sized to its children. i'm not sure if this is a bug, but IE and FF2 both size the DIV to the parent node. At
http://studio.metacafe.com/
, this causes the "Download Metacafe Pro 1.2" link (in the upper right corner) to sometimes wrap in a weird way. It seems like they only sometimes serve the page with this link present. I'll attach a reduced test case that more clearly illustrates the difference. Through testing, I found that IE and FF2 behave one way (they size the DIV to its container), and WebKit, FF3, and Opera9 behave a different way (they size the DIV to its contents). It is possible that this difference causes more glarring artifacts on other pages, but given this particular instance alone, I'd say that the "bug" is fairly minor.
Attachments
reduced testcase
(753 bytes, text/html)
2007-08-10 19:12 PDT
,
Darin Fisher (:fishd, Google)
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Darin Fisher (:fishd, Google)
Comment 1
2007-08-10 19:12:28 PDT
Created
attachment 15916
[details]
reduced testcase
Darin Fisher (:fishd, Google)
Comment 2
2007-08-10 19:15:13 PDT
To be clear, it seems that the author expected the text in the #inner <LI> element to not be broken into multiple lines. I'm not entirely sure what should happen in this case, so my summary of this bug report may be off.
Gérard Talbot (no longer involved)
Comment 3
2010-06-18 20:22:54 PDT
> absolute positioned DIV
#outer { position: absolute; top: 10px; right: 10px; } [quote] 'left' and 'width' are 'auto' and 'right' is not 'auto', then the width is shrink-to-fit. Then solve for 'left' [/quote] Coming from CSS 2.1, section 10.3 Calculating widths and margins, 10.3.7 Absolutely positioned, non-replaced elements
http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width
> w/ single float:right child
#outer ul { list-style: none; float: right; } [quote] If 'width' is computed as 'auto', [then] the used value is the "shrink-to-fit" width. [/quote] CSS 2.1, section 10.3.5 Floating, non-replaced elements
http://www.w3.org/TR/CSS21/visudet.html#float-width
So, both parent container and unique child are sized according to shrink-to-fit width calculation. #inner { position: absolute; right: 10px; bottom: -100px; } Same thing here because 'left' and 'width' are 'auto' and 'right' is not 'auto': shrink-to-fit width calculation. That's why the text in the #inner <LI> element is broken into multiple lines. FWIW, when I view the provided testcase with Firefox 3.6.3 build 20100423, Opera 10.10, Konqueror 4.4.4 and Google Chrome 6.0.437.1 dev, I get the same rendering. regards, Gérard Talbot
Gérard Talbot (no longer involved)
Comment 4
2010-06-18 21:55:24 PDT
I tripled-checked the spec and I see no implementation bug: the #outer div should be sized to the preferred width of its sole child since shrink-to-fit width calculation is applied to the child first and then to its parent. IE8, Opera 10.53 and Safari 5.0 build 7533.16 also render the testcase the same as Firefox 3.6.3 build 20100423, Opera 10.10, Konqueror 4.4.4 and Google Chrome 6.0.437.1 dev. regards, Gérard Talbot
Robert Hogan
Comment 5
2012-09-26 12:30:46 PDT
(In reply to
comment #4
)
> I tripled-checked the spec and I see no implementation bug: the #outer div should be sized to the preferred width of its sole child since shrink-to-fit width calculation is applied to the child first and then to its parent. > > IE8, Opera 10.53 and Safari 5.0 build 7533.16 also render the testcase the same as Firefox 3.6.3 build 20100423, Opera 10.10, Konqueror 4.4.4 and Google Chrome 6.0.437.1 dev. > > regards, Gérard Talbot
That's good enough for me - closing as invalid.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug