- From: Peter Moulder <pjrm@mail.internode.on.net>
- Date: Thu, 23 Jan 2014 23:09:25 +1100
- To: www-style@w3.org
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