Open bertfrees opened 9 years ago
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:
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.
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:
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.
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:
Explain that the :flow() selector applies only on elements with that in their flow property, not on their descendants. (EDIT: not relevant anymore)