Closed andrewpbray closed 1 year ago
Hmm, now that you ask, I realize I might have an incomplete sense of how this behavior is accomplished. This is what I had been thinking...
There would be two (or three) different layout classes: cr-sidebar
(possibly csr-sidebar-rev
) and cr-overlay
. In the filter, these would get evaluated after the sticky blocks and narrative blocks are formed to decide how those content lists get put into the appropriate layout. But I'm realizing - if this is going to be browser / screen responsive, that differentiation needs to happen on the scss end, right? That is: we wouldn't be able to convert a cr-sidebar
into a cr-overlay
if a mobile device is detected because the filter would have already baked those two columns into the html. How should we set that up?
That's the assumption I've been operating on—switching between overlay and sidebar with SCSS. I actually think the DOM that we're outputting for the sidebar should work fine for an overlay too, though, tbh!
The layout I used for my overlay experiment is essentially:
The only difference in our DOM is that the narrative blocks have a wrapper too. So I think the same technique should work, and we'd just use a media query on width to decide whether to apply sidebar or overlay styles.
I think it may become more complicated if we start to have things like the ability to force overlay or sidebar layouts regardless of width, and the ability to customise the layout (eg. to decide what background colour you want for text that passes over the sticky content on mobile). We can definitely pass that through to the DOM with attributes, but it might complicate the styles.
On the other hand, SCSS has a lot of powerful pre-processing features like mixins that might be able to simplify this on the style side! For example, we could write our sidebar and overlay styles as mixins and apply them selectively under media queries. What do you think?
One potential blocker with customisation is that we can't use DOM attributes as styles directly—the Lua script either needs to bake them into style attributes (which is hard if things are supposed to be responsive) or it needs to actually write some SCSS during the render process. That might be tricky! But it also may not necessarily be a version 1 problem—how do you feel about this?
Can also confirm that applying a z-index
to both the sticky content (lower) and the narrative content (higher) is enough to have the narrative content flow over the sticky content! Here I've also added a semi-transparent white bg and some padding to the pars:
Woohoo, glad the z-axis worked!
Thanks for the thoughts and references on the question of layouts for mobile users. I may or may not have a chance to work on this before heading out of town tomorrow, but if not, I'll pick it up when I get back end of next week!
I'll do a proper lookover and test tonight, but this looks good!
I can see you've changed
body_col
tonarrative_col
, which I like!narrative
describes the purpose, which I think makes sense and helps it carry across different layouts.If we think the default experience will be a side-by-side for desktop and an overlay for mobile, should we consider changing
.cr-sidebar
to.cr-section
to make that more layout-agnostic too?