Closed jimjam-slam closed 3 months ago
Minor question: now that we have qmds not at the root of the repo (and it's not a prjoect), they're not able to find the closeread
extension. How are you running those?
(this is gonna be super cool tho - great idea for an example!)
On my laptop I've just copied it down and put a hit ignore on the folder so it's not version controlled, but for the Sverto docs website I copy the _extensions
folder down as part of the website deploy action! I assume at some point once we're happy with Close Read we'll organise things into a website :)
@andrewpbray I missed a couple of things when moving the OJS variable commits over, so I just merged the entire of rename-steps
to date into this branch. Now we have a working scrolling globe demo! You just need to copy CR into the doc directory to render it.
The one fly in the soup is that scroll events aren't firing at all on CR narrative blocks that contain OJS outputs or multiple OJS code blocks. You can see this if you take the block where I calculate the angle scale and angle and split it into two code blocks, or if you have a console output anywhere in the code block.
I originally thought this might be #41 shuffling our DOM around again, but inspecting the DOM output, I'm not so sure! The events aren't firing from Scrollama at all.
That said, very happy to have a useful OJS demo!
Wow, this is great!
I'm catching a small blip in the animation when I scroll through and it happens right at the switch to a new step. If you track the value of crTriggerIndex + crScrollProgress
, it starts at 0 + 0
and goes smoothly to 0 + .99
. Next it flips to 1 + 1
, then to 1 + .00
where it goes smoothly to 1 + .99
then flips again.
I've tinkered a bit with the scrollama, trying to get the index to update at the same instant the progress resets, but no luck. If you add console.log()
to look at response.index
and response.progress
, those are tracking our OJS variables, so the problem seems to be with order of firings of scrollama; it updates the index without updating the progress.
Any ideas?
As an aside, this was not the implementation that I expected, but it is quite clever. I was imagining that we'd use a narrative block-spanning step so that the animation would all take place as part of the same step progress. Something like:
::::{.cr-layout}
:::{focus-on="map"}
We want our globe to rotate with the scroll progress — between -180 and 180.
Instead of trying to do the maths to scale it ourselves, we can make a scale with d3.
There are six narrative blocks that we want to scale over, but I'd like the scrolling to start a little late and end a little early — by the time the last block has just started.
So between 0.5 (because the scroll starts with the first narrative block of the document) and 5.1. If the numbers go outside this range, we'll _clamp_ them so that the scrolling doesn't continue.
:::
And then you could just stick to tracking crScrollProgress
.
Will this work from a scrollama perspective, tracking the progress of a very tall element through the threshold? Thoughts on the tradeoffs of these two methods?
One thing that strikes me with the current method is that if you insert other steps / stickies before the ojs map, you'd have to adjust the scale for the new indices.
PS: as I play around with putting multiple paragraphs within a step, it's not quite the behavior I was expecting: the CSS adds padding to any child element of .sidebar-col
.sidebar-col {
grid-column: 1;
/* extended wrapper around content to allow early scroll detection */
> * {
padding-block-start: 20svh;
padding-block-end: 20svh;
vertical-align: middle;
I'm thinking we should specifically target step elements with this padding. What do you think? And what's the best way to target? Assign a class in the filter? Just use the [data-focus-on]
attribute?
@andrewpbray I think we'd probably want some sort of different identifier for a "compound" narrative block — otherwise it's difficult to tell whether somebody wants one or just wants a regular narrative block comprised of a couple of paragraphs.
That said, in https://github.com/qmd-lab/closeread/pull/40/commits/941f382583700f71c0e306730381e44f00808a07 I have fixed the original problem with the animation catching! scroller-init.js
now resets scroll progress to either 0 or 1 when a block trigger event comes in. This fixes problems with the timing of those events.
There is a bit more fiddly math than I'd like dealing with the null
value of the scroll trigger, though 🤔
This was still looking a bit glitchy on my end up I had my versions messed up, so sorry for the delay. This looks great!
That's a good point about the need for more information to disambiguate a progressing trigger that spans multiple pandoc blocks. I'd say we call this PR excellent and leave that block-spanner for another PR!
No worries! Have just commented up above on the names of the variables, but once we resolve that it's good to go 😊
First demo: animating a globe with some labelled cities in OJS!
This is currently animating over time rather than with scroll. It's also not appearing properly (is the trigger working properly?) when Close Read is turned on (but you can see it if you revert to the regular HTML format).