Overlay and sidebar layout options #55

jimjam-slam · 2024-07-29T11:05:43Z

Closing #24 in favour of this (I also cherry-picked the commits from #52 and #53, as they generalise the ` injection code. Shouldn't matter which is merged first!). Adds two options:

format:
  closeread-html:
    overlay-side: # "left", "center or "right"
    sidebar-side: # "left" or "right"

The Lua filter throws an error if both are used on the same doc. These options set a class on <body>.

These classes can be be inherited on individual .cr-layout using helper classes:

.cr-layout-overlay-left
.cr-layout-overlay-center
.cr-layout-overlay-right
.cr-layout-sidebar-left
.cr-layout-sidebar-right

What do you think, @andrewpbray? I haven't touched colours here, just layout! I also didn't try to do tablet layouts: the layout locks for mobile devices (< 576 px, equivalent to Bootstrap's XS class), but anything wider than that uses the same layout. Just wanted to make sure I got this done before I took off! 😅

Also note I've hard coded the margins for now, but we could potentially write in additional options to pass that in from YAML. For now I've set the sidebar columns ratios to 1fr 2fr, overlay margins to 65%/5% (or 5%/65% on the left). Centre margins are auto, but perhaps we want to set those to percentages too to fix the width. Mobile narrative margins are 0.5em.

(Note that poem doesn't seem to be scaling)

(It generalises meta injection)

Note layout override in sticky blocks test

jimjam-slam · 2024-07-29T11:12:36Z

Re. sidebar widths, we may want to adjust this to accommodate your comment @andrewpbray:

While tinkering around with styling, I realized nytimes keeps their sidebar at a fixed width. Try widening and narrowing the window here:

https://www.nytimes.com/interactive/2022/03/06/books/auden-musee-des-beaux-arts.html

andrewpbray · 2024-07-29T18:17:55Z

Ooo, feel like a kid in a candy shop getting to look at all this fine work! This inspires three lines of thinking:

YAML [1/3]
On a very long roadtrip yesterday I got to thinking about how we could leverage logic similar to code cell options for propagating yaml options down into our document. What are your thoughts on having the users do something like:

format:
  closeread-html:
    cr-section:
      layout: {sidebar-left, overlay-center, etc}
    trigger:
      padding: 40svh
      propagate-focus: {up, down, false}
    sticky:
      margin: 10 10 10 10

The propagate-focus key could be the lua filter behavior that we spoke of yesterday but the remainder would be ways to pass stuff to the classes .cr-section, .trigger, or .sticky (I'd imagine just offering up the most-used style attributes for those who don't want to tinker with the .css file). In the document, we could allow syntax like:

:::{.cr-section layout="overlay-right"}
:::

Which the filter would annotate with a higher level of specificity to override any global layout specified in the yaml.

andrewpbray · 2024-07-29T18:54:24Z

JS vs Lua [2/3]
What's the rationale behind assigning some of these classes in the js instead of in the Lua filter? My rough model for the division of responsibilities there is that the Lua makes the HTML doc (and css) that populates the initial doc that loads. Any changes to it based on user input (i.e. scrolling) is handled by js.

Would it work to write a lua filter that would look something like:

-- set default
local section_layout = "sidebar-left"
-- overwrite section_layout if found in yaml via separate filter on meta

function assign_layouts(div)
  
  if div.classes:includes("cr-section") then
    -- loop over attributes to find any that are layout
    --  if found, use it to overwrite section_layout
  
    -- form appropriate class string from section_layout
    -- add class to div and return it
   
  end
end

What are your thoughts on the tradeoffs of these two methods? I know your time is very limited. I'm happy to work on a lua implementation if that's helpful.

andrewpbray · 2024-07-29T19:47:37Z

Display [3/3]

I'm running into some unexpected behavior when viewing https://closeread.netlify.app/, which published via quarto publish locally.

Sticky blocks looks like the overlay layout, as planned (albeit with some ojs errors). Minard, though, looks like it's still on sidebar-right:

Any ideas what's up?

To loop back to this topic:

Re. sidebar widths, we may want to adjust this to accommodate your comment @andrewpbray:

While tinkering around with styling, I realized nytimes keeps their sidebar at a fixed width. Try widening and narrowing the window here:

It's not a super strong preference, but I think I do prefer that fixed sidebar. Right now nytimes.css is getting there with min-width: 400px; which... I don't quite understand. It seems like it's behaving as if width: 400px, i.e. it does grow beyond 400 px when the page gets very wide.

What do you think the best way is to implement this? Which units?

andrewpbray · 2024-07-29T17:42:44Z

_extensions/closeread/grid.css.map

@@ -0,0 +1 @@
+{"version":3,"sourceRoot":"","sources":["grid.scss"],"names":[],"mappings":"AAAA;AAEA;EACE;EACA;;AAEA;EACE;;AAEA;EAEE;EACA;;AAEA;EACE;;AAKN;EACE;;AAIA;EACE;EACA;EACA;EACA;EACA;;AAEA;EACE;EACA;EAGA;EAEA,YACE;;AAOJ;EACE;;;AAMR;AACA;EAEI;IACE;;EAEA;IACE;IACA;IACA;;EAGF;IACE;;;AAMR;AAAA;AAAA;AAAA;AAMA;AAAA;AAAA;AAAA;AAAA;AAAA;EAOE;;AAEA;AAAA;AAAA;AAAA;AAAA;AAAA;EACE;EACA;;AAGF;AAAA;AAAA;AAAA;AAAA;AAAA;EACE;;;AAOF;AAAA;EACE;EACA;;;AAKF;AAAA;EACE;EACA;;;AAKF;AAAA;EACE;;;AAKJ;AAAA;EAGE;;AAEA;AAAA;EACE;EACA;;AAGF;AAAA;EACE;;;AAGJ;AAAA;EAGE;;AAEA;AAAA;EACE;EACA;;AAGF;AAAA;EACE;;;AAIJ;AAEA;EAEE;AAEA;AAAA;EAEA;EACA;EAEA;EACA;EAGA;;AAGA;EACE;;AAGF;EACE;EACA;;;AAKJ;AAKE;EACE;EACA;;AAIF;EACE;;AAIF;EACE;EACA;;AAEA;EACE;EACA;EACA;;;AAMN;AAII;EACE;EACA;;AAEA;EACE","file":"grid.css"}


If we're including the css and the scss files in the extension, what's the role of this map file (I've never seen these before)?

I haven't worked with them much, but my understanding is that they allow someone using the browser developer tools to look up a stylesheet rule that is applied to an element (mochas we were doing the other day, clicking on bootstrap.min.css next to a rule) and be redirected to the SCSS that generated it. So it maps the SCSS to the compiled CSS.

That said, it's not necessary for the user! If we wanted, we could git rm the map and then put it on .gitignore.

Hmm, I'd be inclined to git rm it since I'd bet anyone whose doing that will be able to figure out where to look in these stylesheets.

_extensions/closeread/scroller-init.js

andrewpbray · 2024-07-29T18:41:46Z