JayPanoz
commented
6 years ago A little bit of history about the media queries englobing the responsive columns.
A few months ago, when designing a more complex pagination model, we agreed that it was somewhat weird to get 2 columns in portrait mode on mobile devices (smartphones, tablets) and wanted to prevent the following from happening on desktop:
The <figure> in this is using vh units while the image is constrained by object-fit so that it can keep its aspect-ratio, which explains 1. why it is vertically centered and 2. the huge gap between the image and its caption.
And changing the styles on the fly to force <figure>’s sizing based on the width if this happens is a complex problem since we’ve got nothing from multicol. At some point we even wondered whether enforcing an aspect ratio range for the page was a sensible option. But we went with media queries to limit the contexts in which columns are responsive and will switch from 1-col to 2-col layout.
Problem is, in practice, this choice has regularly been an issue, and it impacts the user setting as well (so implementers end up removing media queries, or they don’t know the setting shouldn’t be available on mobile + portrait as it was poorly documented and the info only available in CSS in the form of comments, etc.).
Si it’s less about responsive columns than those media queries.
Right now, responsive columns (i.e. page → spread) are in the pagination module, which may raise implementation issues for various reasons e.g. dev wants to manage it programmatically,
colNumberuser setting doesn’t work in some contexts, etc.It will be a lot better to create a specific module that implementers can opt-in – or opt-out, to be discussed.
Impact:
Implementers might want to manage the availability of the user setting in the UI anyway (for instance, only allowing it on smartphones in landscape mode) so managing this via CSS can be a complication in some situations.