Join GitHub today
Page margins implementation #2
Currently, we’re relying on CSS for horizontal margins (left/right). Vertical margins (top/bottom) are managed at the web view (or iframe) level so that we don’t mess with the viewport height unit.
This issue discusses the pros and cons of using this CSS implementation.
How it works
Because columns have a floor but no ceiling in this configuration i.e. they can grow to 100% of their container’s width, we have to limit line-length using
Which means we must have margin set to
In pink, the column width, and in yellow, the elements nested in
It is still unclear how we should manage
Which means you could use
Once again, this can be set with a variable.
It is set in pixels so that it doesn’t increase with font-size.
As you can see, there is no column-gap, everything is currently managed with
Closer to the metal
We rely on the browser/web view to compute and lay out everything, avoiding possible rounding errors which might create extra bugs (due to JS’ inaccuracies you must take care of).
You don’t have to tweak values in real-time so it’s faster in theory. We’re trying to take advantage of columns’ logic there. Although they’re using a pseudo-algorithm and are missing some pieces (
It is responsive by default i.e. “one font-size to rule the whole.” For instance, if font-size is too big for 2 columns then it will automatically switch to 1,
Although it’s responsive by default, you can still use CSS variables to force specific values if needed.
You can fine-tune
Switching from 1 to 2 columns is one line of CSS but you would have to enable/disable the setting in some conditions e.g. make it available only in landscape mode on mobile.
A custom margin user setting could be applied changing the value for padding. Thanks to
You would get some flexibility with the font-size setting i.e. either keeping the same page size in all configs or making it responsive to the current font-size.
Extra design options for CSS authors
Should an implementer decide to use CSS variables in production, and since they are interpolated by the rendering engine itself, it could open up new design options for CSS authors. For instance, you could in theory do “full-width” images by using the
It works in two-page spread too.
You could also expose that as a data-attribute (e.g.
We could also have full-width headers, blockquotes, preformated text, etc (padding would simply be
I guess it would be more reasonable to tag anything CSS Variables as progressive enhancement in such cases, so that implementers don’t have to polyfill for browsers which don’t support them—should they use CSS variables, obviously. But that is implementers’ call.
Authors willing to do such effects will do it anyway. Only will they have a margin/padding on every element but figures. This might irritate some readers because this margin could be set in
If we could at least explore and discuss design solutions (and their issues), it would improve the current situation a little bit (authors so frustrated they don’t even want to explain their current problems).
The whole logic might not be easy to grasp at first, since columns’ logic might be weird when you’re not used to it. I must still document how columns work to make it clearer to people who are not familiar with it.
You must deal with large screens
On large screens, you either have to control the font-size (bigger default if desktop + large viewport) or the viewport itself (web view || iframe’s size).
Users might no be used to responsive margins
Users might not be used to responsiveness and could see the
CSS authors could mess things up e.g. page margins, line-length, media queries, etc. (either by using super specific selectors to force their own values or by accident), which would defeat this CSS approach since you’ll have to add inline styles in the DOM to make sure your values apply.
By providing design options to authors, we could prevent nasty hacks. Since a lot of hacks are the result of current design limitations, managing some on our side—with much better control—could probably much their life easier, especially if they just have to add attributes in their markup (cf. pop-up footnotes). See issue #1.
You can not have equal left, center (gap) and right “margins”. Center (gap) will be at least double the outside margins since you can’t target even and odd columns to apply padding on the left or the right (
You could add the missing width for left and right margins to the web view or iframe though.
Two-page spread implies some complexity
You have to reset
It requires normalization
You must normalize font-size for
How do RS tend do do this?
No margin, no padding,
Consequently, a user setting for page margins would bring some complexity and some Reading Systems prefer not to implement it.
Please note we should at least have a minimal margin (
What we need
Since some user settings heavily depends on this decision, it’d better be taken as soon as possible. “Default CSS” and “reading modes” phases shouldn’t be impacted at first sight but the sooner, the better.
Important note to TestFlight users: Adobe’s page template currently breaks pagination.
If you have something like
Issues I can currently report:
So, more info as regards margins.
From ebpaj guide v 1.13:
Which is what we’re currently doing.
Maybe we should also tell them that (from “Items RS are expected to have in the future”)
would be a lot easier to manage at the RS Level if they didn’t require that RSs shall not independently add margins that affect the usable screen size in the body element? As-is, those two are kind of conflicting i.e. a “you can’t have your cake and eat it” combo of requirements/expectations since it adds so much complexity to respect both.
Update: I’m currently designing advanced pagination + scroll + margins.
My main objective is finding a design system which is not Kafkaesque since we must deal with different viewports, paged/scrolled views, the number of columns, and user settings and that could bring a lot of complexity and abstraction.
I’m not saying the model I’ve been designing so far is perfect—and I must still test it extensively—, but well, it seems to me KISS-enough at the moment.
Question is do you feel like this is too simplistic at first sight?
It seems to me having the same margins in paged and scroll views are the way to go for consistency. After all, contents displayed in a single-column paged-view can be seen as “a fragmented document scrolling on the opposite axis.”
Columns are currently responsive by default i.e. a column must be at least
I’m wondering if this is the best option though, as we can more or less predict for which configurations 2 columns may be set → smartphones and tablets in landscape mode + larger screens. And they could be responsive to the user’s font-size anyway.
Finally, I’d much prefer we don’t target specific devices using media queries, as this is unmaintainable in the long term.
For vertical writing, I had to temporarily set an extra left and right
So we have this for the kihon-hanmen (text frame):
So if we decide to manage this extra