Open HadrienGardeur opened 2 weeks ago
Alright, indirectly documenting what’s happening being the scenes with CSS multicol, and clarifying the behaviour based on that. I guess it’s useful for others checking this issue re. "content area" and how it translates.
First things first, we have multiple widths in practice:
width
of the Navigator’s container, which is part of the app UI;max-width
of the content paginated using columns, which serves as line-length.For auto (layout) we’re doing the following:
innerWidth
;Basically, value auto
is the multiple of optimal line-lengths + gap (page gutter as padding in ReadiumCSS) you can fit in the viewport.
The Navigator’s container is then constrained by line-length and gap in order to be consistent with dual-column mode.
With that in mind, let’s now switch to the other options: single or dual column/spread.
forcing a single column while remaining in almost full width for the content area
The navigator’s container is not constrained in that case.
The line-length is applied, be it the optimal one or, in the future, the one the user has set.
dynamically calculating and fitting the width of the content area for dual column mode
In practice, you just have to set column-count: 2
and CSS multicol will take care of the rest.
The width of the navigator’s container is constrained by the line-length and the gap.
fallback when dual columns can't be fitted (could be a single column and/or a smaller line length)
Based on the dual column mode case, the fallback you get for free from CSS Multicol is that it will force 2 columns no matter what so, you get a smaller line-length by default.
So if you want to switch back to a single-column you have to simply change the column-count
based on conditions. In that case, what should be these conditions?
Based on the dual column mode case, the fallback you get for free from CSS Multicol is that it will force 2 columns no matter what so, you get a smaller line-length by default.
So if you want to switch back to a single-column you have to simply change the column-count based on conditions. In that case, what should be these conditions?
IMO we need a way to return the current number of characters per line that's actually displayed (vs the optimal number of characters), which an app could use to lower the number of columns to a single column when the number of characters per line gets below a specific number.
This could even be part of the Preferences API where we would support both:
Some additional thoughts on this:
For this task, we're targeting the ability to force a single or dual column/spread.
For reflowable EPUB files, this means:
For FXL files, this means: