Named flows

[bertfrees]

Section Named Flows: describe how named flows can be used to move content to the bottom of pages, the beginning or end of volumes, etc.

To do:

• [ ] Describe what happens with ‘flow’ properties on elements in named flows and their descendants. (see below)
• [ ] Describe what happens with ‘flow’ properties on elements with 'display: none' and their descendants. (see below)
• [ ] Describe what happens with ‘counter-set’/‘counter-reset’/‘counter-increment’ properties on elements in named flows and their descendants. (see below)
• [ ] Describe what happens with ‘string-set’ properties on elements in named flows and their descendants.
• [ ] Describe what happens with ‘::before’/‘::after’ pseudo-elements of elements in named flows and their descendants. (see below)
• [x] Describe what happens with ‘flow’ properties on ‘::before’/‘::after’ pseudo-elements. (see below)
• [x] Explain that the :flow() selector applies only on elements with that in their flow property, not on their descendants. (EDIT: not relevant anymore)
• [ ] Describe what happens with content in named flows that is not explicitly taken out. Do we need a way to ensure that all flows will actually end up somewhere?
  • maybe related: https://drafts.csswg.org/css-regions/#propdef-region-fragment

[bertfrees]

After have given this some more thought I realize that the current proposal is bit complicated in some ways and that it differs too much with the "recommended" way of doing footnotes (see [CSS3GCPM]). However I still like that the same concept of named flows can be used for both footnotes and content at the beginning and end of volumes.

I would like to change the proposal in the following ways:

• The flow property can cause an element to participate in only one flow (by default the normal flow).
• Forget about the :flow(...) pseudo-class. Elements in a named flow are styled just as if they were in the normal flow. This is much more intuitive.
• To cover the case where an element needs to participate in more than one flow, we could use the ::alternate pseudo-element (and possibly ::alternate(2), ::alternate(3), ...). Note that the [CSS3GENCON] specification is obsolete, but at least the ::alternate concept is easier to grasp.
  EDIT: The ‘::alternate’ pseudo-element should only be used for generating content (just like ‘::before’ and ‘::after’) either to be inserted in place of an element that has been moved to another flow, or to be moved to another flow itself. If needed, a new ‘::duplicate’ pseudo-element could be introduced for duplicating elements that need to participate in more than one flow.
• Support ::footnote-call and ::footnote-marker?

[bertfrees]

Describe what happens with ‘flow’ properties on elements in named flows and their descendants.

If flow = normal (the default), nothing special happens. If flow ≠ normal, the element moves to the named flow as usual. The reference position for computing where the element will end up is what the element's position would have been for flow = normal. If the specified flow is the same one the ancestor element participates in, the descendant element becomes the next sibling of the ancestor element.

Describe what happens with ‘flow’ properties on elements with 'display: none' and their descendants.

The effect of ‘display:none’ is determined when boxes are generated, after content has been moved around using flows. If elements are moved to another position in the box tree, whether or not those elements generate boxes is determined by the effective ‘display’ value of their final container element.

Describe what happens with ‘::before’/‘::after’ pseudo-elements of elements in named flows and their descendants.

These pseudo-elements are moved to the named flow in the some way as with any other descendants.

Describe what happens with ‘flow’ properties on ‘::before’/‘::after’ pseudo-elements.

The ‘flow’ property is not supported on ‘::before’ and ‘::after’ pseudo-elements.

[bertfrees]

Describe what happens with ‘counter-set’/‘counter-reset’/‘counter-increment’ properties on elements in named flows and their descendants.

With named flows coming into play, the scope of counters should be redefined. The bottom line is that counters shall be evaluated at their final position (in the box tree, not the document tree). (This probably means that the specification should be in terms of boxes rather than elements.) Also, each flow will have its own scope. Counters from outside the final container of a flow are visible inside the flow but can not be manipulated. ‘page’ and ‘volume’ are special counters visible everywhere in that page or volume box.

In addition, we need some kind of fallback mechanism to support various cases when a counter needs to be evaluated at its original position, or when a counter needs to be evaluated at the final position of an associated element (::alternate relationship). Examples are:

• footnote number generated and inserted at both the note and the noteref
• include the number of the page on which an end note is referenced in the note

Several solutions are possible. The most elegant is probably to make the ‘counter()’ function smart enough so that it will fall back to associated positions in the box tree if a counter does not exist in a certain place.