- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 25 Jan 2016 10:48:19 -0800
- To: fantasai <fantasai.lists@inkedblade.net>
- Cc: www-style list <www-style@w3.org>
On Mon, Jan 25, 2016 at 10:36 AM, fantasai <fantasai.lists@inkedblade.net> wrote: > On 01/23/2016 11:15 AM, Johannes Wilm wrote: >> On Fri, Jan 22, 2016 at 10:36 PM, Tab Atkins Jr. <jackalmage@gmail.com >> <mailto:jackalmage@gmail.com>> wrote: >>> >>> >>> The page-float 'clear' values (block-start/end, and ones that act like >>> that) are defined backwards - as written, they prevent *further* >>> page-floats in the same position. That's not how clear works in other >>> contexts - 'clear' indicates that the element wants to move if *it* >>> isn't the first in that direction. >>> >>> So "clear: block-start;" should be defined as making the page float in >>> question move to the next appropriate fragment if it's not the first >>> float in that position. >> >> >> Yes,s o it should lock the current fragment from any further floats in >> that same direction AND defer itself at least one fragment, right? >> Else we could end up with subsequent floats being placed in that same >> fragment. > > Well, but that's how clear generally works. So, yes, subsequent content > would be allowed (unless said content also clears). Yeah, clear:left does *not* prevent further left floats, it just ensures that the *clearing float* is the first left float on the line. We must not change this behavior for other types of floats, at least by default. Adding "prevent any further floats in this position" via a keyword or another property would be fine, if it's needed, but we should make sure it's actually needed and can't be addressed by just adding 'clear' to more things. ~TJ
Received on Monday, 25 January 2016 18:49:10 UTC