Re: [css-break] Independence of parallel flows

On Wed, Jan 15, 2014 at 02:48:39PM +1100, I wrote:

>   To say that the choice of fragmentation break inside one flow has absolutely
>   no influence on the choice of break in another seems too strong.
>   [...]
>   I suspect that this wasn't actually the intent of this section, but I so far
>   haven't worked out what it does intend by "independently" and "not affect the
>   content wrapping".

Table cells are another interesting case: UAs must apply the break-before
and break-after properties to boxes in the normal flow of the fragmentation
root, which can include table cells and their in-flow content.  If cell A
contains a forced break, then I think the intent was to say that following
cells would normally still start in the fragmentainer where cell A started.
It presumably wouldn't be altogether true to say that this has no effect on
parallel cells: maybe a parallel cell has vertical-align:bottom (say for a
heading), in which case it must be aligned with the bottom of the last row
that it spans, whose position might be affected by the break in cell A, so
the choice of breaks in that bottom-aligned cell might well be influenced
by that break in cell A.

(Incidentally, we might point out that in the common case of a heading row
 whose cells are all bottom-aligned, implementation is a bit difficult
 because you have to know where in the fragment the row ends before having
 a final pagination for the cells, but that row end position is in turn
 influenced by pagination choices of those cells.  I don't see that there's
 much we can do to remove the difficulty, but we might at least draw
 implementers' attention to the difficulty to save them from a dead end.
 Discussion of what middle-aligned cells spanning a fragmentation break
 should look like probably belongs in another thread.)

Doing ‘hg annotate’ and looking at the changes that went into this text, I
think I see how it came about and what the intent might be.  The original
text said that a break "ends layout in the current fragmenter"; I think the
intent of this new text was to clarify that a break in one flow doesn't
prevent other flows from continuing to use that previous fragmentainer.

So I think that this section wasn't intended to impose any normative
requirements at all: it looks like it was mostly intended to retract an
apparent requirement imposed by a previous draft.

If that is indeed the case, then I think the fix is to remove the
appearance of imposing normative requirements ("independent", "does not
affect"), and instead make sure that each requirement in the rest of
the document is clear about its requirements (such as being clear that
properties only impose requirements on the flow in which they occur).

Looking at whether they are in fact clear, I do see one problem, namely
that various properties talk about breaking "the flow", but this term
doesn't seem to be defined.  It looks like it might be a reference to the
CSS2.1 definitions of "the flow of an element" and "the normal flow", but
those terms don't consider table cells to be separate flows.

("Fragmented flow" is merely defined in terms of "content flow", which isn't
itself defined in at least this document.)

I suggest that this ‘Parallel flows’ section be changed to define a term
involving the word "flow" (possibly simply using "fragmented flow";
or if a different term, then perhaps "content flow", or more generally
changing "content flow" in the definition of "fragmented flow" to use this
new term).  Perhaps the approach to defining it would be first to define
those boxes that establish new flows (table cells, floats etc.), similar
to how "the flow of an element" is defined in CSS21/visuren.html.

Then, for each of the break properties, its requirements should (if I've
correctly understood) be written in terms of this new flow term, which
should make these bits clearer and ward off other issues.

(I don't know whether this is a good example, but right now I'm not sure that
 things are well defined and work out well when break-before is applied to one
 of a group of sibling block-level boxes that each create a parallel flow,
 such as flex items: I think in this case that the subsequent parallel blocks
 have to start in a later fragmentainer than where previous parallel blocks
 start, and I wonder whether this creates problems for things that expect
 them to be parallel in the sense of starting in the same place in
 block-progression dimension.  No need to reply to or look into this, it's
 just an example of the sort of issue that might be cleared up by the
 change.)


I hope at least some of that's helpful — even if it only shows better my
misunderstandings!

pjrm.

Received on Thursday, 23 January 2014 12:09:46 UTC