W3C home > Mailing lists > Public > public-css-archive@w3.org > June 2016

[csswg-drafts] [css-page-floats] Absolutely positioned?

From: Brad Kemper via GitHub <sysbot+gh@w3.org>
Date: Sat, 25 Jun 2016 23:50:07 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-162305167-1466898606-sysbot+gh@w3.org>
bradkemper has just created a new issue for 
https://github.com/w3c/csswg-drafts:

== [css-page-floats] Absolutely positioned? ==
https://drafts.csswg.org/css-page-floats/#relation_to_absolutely_positioned_exclusions
 implies that page floats are absolutely positioned, which the actual 
position determined by the spec logic. The subsections are about how 
"absolutely positioned exclusions" are different from inline floats. 
So are these actual absolutely positioned exclusions (with automatic 
locations based on values defined in this spec)? Or are they just 
similar to "absolutely positioned" items, and if so, how similar? For 
instance, do they create a containing block for their positioned 
descendants? Are margins not collapsed? Are 'auto' margins changed to 
0? Are 'auto' widths shrink-wrapped? Do most 'display-outside: inline'
 things become block? Put another way, is the computed value of 
'position', 'absolute'?

IMO, the answer to all these should be "yes". The spec kind of implies
 it, but the closest it comes to actually saying so is "Floats that 
are not inline floats should behave the same as absolutely positioned 
exclusions." Related question: what if 'left', 'right', 'top', and/or 
'bottom' are not 'auto' for the page-floated item? What wins?

Note that setting position:absolute normally overrides floats, but 
these aren't really floats, they're absolutely positioned exclusions 
with actual positions determined another way. Another reason why the 
'float' property should not be overloaded to include this completely 
separate model of wrapping.

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/243 using your GitHub 
account
Received on Saturday, 25 June 2016 23:50:10 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:30:20 UTC