RE: [css3-break] Force-breaking around floats

See inline:

-----Original Message-----
From: Alan Stearns 
Sent: Tuesday, November 19, 2013 9:06 PM
To: Mihai Balan; WWW Style
Subject: Re: [css3-break] Force-breaking around floats

>On 11/19/13 7:25 AM, "Mihai Balan" <mibalan@adobe.com> wrote:
>

[snip]

>>
>>    1. What should happen when a float contains a forced break (e.g. an 
>>element *inside* the float has `break-after: always`)? I suspect it 
>>should break, but exactly how does that look and how the resulting 
>>float fragments interact with the rest of the content (fragments) is 
>>something that I feel is likely to blow up in our face.
>
>It should break, and section 5.1 [1] attempts to deal with some of the implications of this. The examples use unforced breaks, but where an unforced break could occur you should be able to force a break.
> 

Not quite. With unforced breaks, I think it is impossible for normal flow content to  end up below the float fragment in the first fragmentainer. With forced breaks, the first fragment of the float could be near the start of the first fragmentainer with a lot of normal flow content still unbroken. Will this normal flow content be rendered below the first fragment of the float? Does the first float fragment create a "continuation" to the next fragmentainer?
Here's two pictures to make things clearer:

In both figures, <.>s represent normal flow content, <~~~> represent a forced break and the floats are explicitly listed

A. Float fragments are treated as two distinct floats

+--[First fragmentainer]------+
| /=======\ ................. |
| | first | ................. |
| | float | ................. |
| | frag. | ................. |
| |       | ................. |
| \~~~~~~~/ ................. |
| ........................... |
| ........................... |
| ........................... |
| ........................... |
+-----------------------------+

+--[Second fragmentainer]-----+
| /~~~~~~~\ ................. |
| | second| ................. |
| | float | ................. |
| | frag. | ................. |
| |       | ................. |
| \=======/ ................. |
| ........................... |
| ........................... |
| ........................... |
| ........................... |
+-----------------------------+

B. Float fragments are "linked" together
+--[First fragmentainer]------+
| /=======\ ................. |
| | first | ................. |
| | float | ................. |
| | frag. | ................. |
| |       | ................. |
| |~~~~~~~| ................. |
| |xxxxxxx| ................. |
| |xxxxxxx| ................. |
| |xxxxxxx| ................. |
| |xxxxxxx| ................. |
+-----------------------------+

+--[Second fragmentainer]-----+
| /~~~~~~~\ ................. |
| | second| ................. |
| | float | ................. |
| | frag. | ................. |
| |       | ................. |
| \=======/ ................. |
| ........................... |
| ........................... |
| ........................... |
| ........................... |
+-----------------------------+

This has the potential to become even trickier when different-sized fragmentainers, writing modes, or box-decoration-break are thrown in the mix.
 
[snip]

>>    Also, since forced breaks are actually properties of a "point" 
>>between boxes and not properties of a box (or element), I doubt it even 
>>makes sense to make applying breaks around floats optional.
>
>I don't know the reason for making this optional on floated boxes, but I'm not sure I understand the question you're asking. If a float would normally render in fragment container 1, and the floated element itself has "break-before:always" or the element before the float has "break-after:always" I assume the float would render in fragment container 2. Is there an ambiguity I'm missing?
>


The ambiguity comes from the fact that breaking control properties apply to a boundary (or break opportunity in Fragmentation parlance) and not to a box. The fragmentation spec basically says that break-before/break-after values accumulate in order to decide whether at the boundary between two adjacent boxes there _should_ be a forced break or if an unforced break _can_ be placed. In this reading, that break-after on the first block is equivalent to break-before on the second block. Now, if either of these blocks is a float and the UA does not process break properties on floats, this equivalence does not hold anymore. This can lead to inconsistent behavior in UAs that do not process break properties on floats and can bloated stylesheets that needlessly repeat break properties.

Is it clearer now?

Thanks a lot,
m.

Received on Friday, 6 December 2013 09:34:36 UTC