WIP transition works, except blue desktop #11
Conversation
|
Also I've used explicit |
|
Hey, that's awesome! It's pretty neat how, on the markdown side, all it really takes is tacking a class onto an element, div or span. I can't wait to play with this stuff! I just made a PR into this branch that should hopefully remove the |
|
I've had a chance to read through the scrollama js code and I think I have a sense of how it's built (that console logging is super helpful!). It strikes me that there are (at least) two different transitions here that could be helpful: In terms of API, this could be implemented by using scroller
.setup({
step: ".cr-fade-out-and-fade-in",
offset: 0.4
})
.onStepEnter((response) => {
if (response.direction == "down") {
let allStickies = Array.from(
document.querySelectorAll(".cr-sticky, [data-cr=\"sticky\"]"));
let currentSticky = allStickies[response.index - 1];
let otherStickies = allStickies.slice(0, response.index - 1).concat(allStickies.slice(response.index))
currentSticky.classList.add("cr-scrolledby");
otherStickies.forEach(e => e.classList.remove("cr-scrolledby"));
}
})
// plus the rewind versionAs I think about it, I'm pretty sure this won't work. The dilemma is illustrated by this line:
Looking at the scrollama docs, we also have access to
Do you think this is a good way to approach it - differentiating transitions types based on class and the implementation approach outlined directly above? If so, I can take a crack at implementing it. |
|
That's right! The only complication I would mention is that I wrote the effect of I think having both Your reasoning around making the scroller step selector complex (ie. adding several classes as steps) and using conditional logic in the callbacks is sound to me 😊 Happy to see you go at it! I'll post another comment for the other change we might need below to keep my thoughts straight 😅 |
|
If I understand the need for different transition classes correctly above, we'll also need additional styles available to lay out things like row- or column-based lists to have things fade in sequentially. One way we could do that is to separate out the two jobs that
For example, The only downside of this is that it complicates our API a bit. When reveal has things like this, it only has the fragment itself—the step side is self-evident (it's a click). For us, we need the steps and the content. This might mean that explicitly linking steps and content with an attribute (eg. |
|
I think I understand most of your thoughts, but I don't quite get the use-case you're envisioning:
I think of our current fade-in setup one where, as a step comes into view, the next sticky element in the stack transitions from an opacity of 0 to 1. That leads to an effect where each new sticky element appears on top of the previous stack, like this blue square appearing on top of the pink square: 
I was envisioning the fade-out-and-fade-in analog at this part in the example doc to be just the blue square; the pink square would have faded out as the blue one faded in. So it'd still be one element replacing one another. Could you say more about what you mean by three elements side by side? |
|
Ooooh. Do you mean that you were expecting the fade out of the previous element to have been completed before the next fade in starts (rather than a cross-fade effect)? If that's the case, we can just add a delay to the fade in in CSS and call it a day! I had assumed you meant something more like an incremental list in Quarto, where it's A visible -> A and B visible -> A, B and C visible. If you mean that the pink square is continuing to remain visible after the blue has faded in, we might have a CSS/JS bug there. I coded the |
|
Ah, perhaps a bug! Indeed the pink square remains visible. Here is what it looks like once I've scrolled to the bottom of the second div: 
Ok, I see now what you mean now by the incremental list. That's like a series of revealjs fragments (that don't use r-stack): the object is present in the layout (i.e. it takes up space) but is not visible. More parallels with revealjs! |
|
Ahh, gotcha! If you let me know what browser and OS you're on, I can take a look—I might need to make sure we're not relying on anything too exotic as far as the transition CSS goes. |
|
I'm on: MacOS Monterey 12.6.6 |
|
Closing this branch in favour of the |
First test of actual Scrollama transitions.
This works, with some caveats:
The blue desktop one doesn't currently work because both the wrapper
and the contents![]()
have .cr-sticky.
The double counting of blue desktop is throwing off the count of subsequent sticky elements.
I think both these problems can be solved if the Lua script removes the class from the![]()
when it moves it to the wrapper
. But,
Thst said, it broadly works as expected! 🥳