[css-page-floats] should intersect with [css-page]

[v-python]

I've been trying to figure out how to have different styles on left-hand and right-hand pages of paged media. It seems that css-page only defines margins and gutter and crop marks and such, and while it supports page numbering, it doesn't seem to affect page formatting. Left-hand and right-hand pages want to be different because of the way books are bound. Floats are the first issue that came to my attention in this regard, although there may be others. I applaud the extension of floating to the vertical as well as horizontal direction, but the horizontal direction still doesn't seem to have the ability to put float a block left if it is on a left-hand page and right if it is on a right-hand page, or vice-versa. Many printed books use such a style, but as far as I can tell, in the latest drafts there is not yet a method to implement such a style.

[rachelandrew]

You can use the spread pseudo-classes for that https://www.w3.org/TR/css-page-3/#spread-pseudos

You didn't mention which user agent you are working with, but the Prince docs are pretty good in terms of explaining how this works: https://www.princexml.com/doc-prince/#page-rules

I don't think this is a Page Floats issue however.

[v-python]

Thanks for the reply, Rachel, but the spread-pseudos, which I had seen, as well as everything else in the css-page specification, seem to only affect the way the page itself is formatted with respect to margins, gutter, etc. But I can't see how to affect content layout based on the page being an odd or even page. Perhaps I didn't state the question clearly, so I'll try for an example to clarify.

Imagine a large, box to be laid out by fragmentation and it turns out it will take 10 pages... somewhere in the "middle" there is a float. How do I instruct, using current or proposed standard CSS, that the float should be to the left if it is on an even page, or to the right if it is on an odd page?

[fantasai]

There were proposals to handle this in early drafts of css-regions and css-scoping, see https://www.w3.org/TR/2014/WD-css-scoping-1-20140403/#fragment-scoping ... however, this is really hard! See the issues against ::first-line style resolution as an idea. It gets even worse with layout-affecting things like floats and margins, basically tossing in a large chunk of the layout complexity of overflow fragments https://www.w3.org/TR/css-overflow-4/#fragment-overflow or regions..

Bottom line, we'd like to do it, but it's super complicated, so it's not happening in the near future! But it is on the to-do list?

Fwiw, pathway to getting there is

1. Fix ::first-line style resolution to be precise, understandable, interoperable, and usable -- we will reuse this model for per-fragment style inheritance within a styled container.
2. Get overflow fragments specced and implemented, including variable-width fragmentation (see https://www.w3.org/TR/css-break-3/ ) -- this gets us per-fragment box layout.
3. Define and implement region-scoped selectors -- this gets us per-fragment style resolution within a container.
4. Relax restrictions on what can be scoped per-page now that we can do per-fragment inheritance, style resolution, and layout!

Unfortunately, each of these steps is a major project, implementation-wise. And not particularly easy to spec, either. I guess, follow along with ::first-letter fixes, each one is one step closer to per-page styling? :)

[v-python]

Interesting. I'm glad it is recognized as an issue; it's certainly a common feature in print layouts. I'm not sure I understand the connections to ::first-line, except maybe if there is a plan to do ::nth-line also? At least obviously, there will be more than one page to which formatting would need to apply. Where can I follow along with the ::first-letter (or did you mean ::first-line?) fixes?

Once you expanded my outlook to the idea of region-scoped selectors, it makes me wonder if another issue I've bumped into is related. I'm tossing hundreds or thousands of small items in a grid, for one application, and I discover that there is only one way to control grid-column track width, and that is via grid-template-columns (unless I missed something). There seems to be no way to specify a selected subset of tracks to have a given width, after the fact (in a cascade), but rather one must "keep notes" and update the grid-template-columns specification. And, there's no selector to say "element::nth-track( 2n )" to supply zebra striping or checkerboard backgrounds. Would this fall under the concept of region-scoped selectors? Are these ideas that are already in discussion somewhere?