Replies: 7 comments
|
Thanks for the feedback. This is a really good point. A big part of why I really liked how bento turned out is that the slide auto animate via morphing and effects like kenburns. I guess "animate on click" is just a continuation of that theme. Even looking at option 2 (which I like more), I don't think either will add much to the runtime size. I'll try running some tests, but I think we can have a way to keep compatibility. |
|
Good to hear you're looking into it — and option 2 sounds right to me too. Curious to see what your tests turn up. If any questions come up along the way, just ask, I'm happy to help. And while I'm here: bento is a pleasure to work with. One file that opens anywhere, no CDN, no install — I hand a deck to someone and it just opens. That's rarer than it should be. |
|
Hey, just checking in on this one. Anything I can help with to move it along? Happy to test a build or put a sample deck together if that is useful. |
|
+1 on this feature ! That would be awesome to have as I heavily use these animations on click on PowerPoint or fragments on reveal.js. Also +1 on the quick workaround to have a checkbox to ignore the current slide in the count. I will say the same thing as the author, it's a pleasure to use and should have more recognition! |
|
Just a quick heads-up that this feature has been implemented in 1.1.0. Apologies it took a bit of time to get right, but basically now you have 2 options -
Please give this a whirl and let me know. |
|
Thank you — I tested both today and they work beautifully. The reveal steps let us drop a workaround we had been carrying, and one slide is one slide again. Really appreciate you taking this on. |
|
Glad it earned its place. Closing as shipped in 1.1.0. |
Uh oh!
There was an error while loading. Please reload this page.
What I'm asking for
A way to reveal elements one at a time within a single slide, advanced by the same key that advances the deck. PowerPoint calls this "animate on click"; reveal.js calls it fragments.
I searched the issues, the discussions and #124 before writing this. I found nothing on the topic — not planned, not requested, not declined. So this may well be a deliberate omission, and I'd rather ask than open a PR into a wall.
Why I want it
I present to bank and insurance audiences. When three recommendations sit on the closing slide at once, the room reads all three while I'm still on the first one. Revealing them one at a time is the difference between people listening and people skimming.
What I do today, and how well it works
One slide per step,
transition: "morph", shared element ids. Carried elements glide across untouched, the new element runs its entrance. A 20-slide deck became 22.This works, and I want to say so clearly — it isn't a workaround I'm unhappy with. Two things made it work:
opacity: 0,translateY: 16pxand settles over roughly 450ms.Generating it is straightforward: my build script emits N slides from one layout call, and everything except the newly added element keeps its id.
The one thing that breaks
The slide number counts up. My deck shows 18 → 19 → 20 across what the audience perceives as one slide. The footer page badge is part of our client's corporate design, so hiding it isn't open to me, and I can't hard-code a literal because it breaks the moment a slide is inserted earlier in the deck.
Speaker notes have the same shape of problem: they live per slide, so a three-step build wants the same note three times or only on the last one.
Two ways this could go, from cheapest up
1. A slide flag that makes it not count. Something like
countsAsPage: falseon a slide, honoured by{{page:N}},{{pages}}and the present-mode chrome. Steps stay ordinary slides — the format doesn't grow a new concept, the document stays readable in an older shell, and the whole thing is one predicate in the page-number resolver. This alone would close my case.2. Per-element step order. An
fx.stepinteger: elements with a step above the current one stay hidden,→raises the step before moving to the next slide,←lowers it. Closer to what PowerPoint and reveal.js do, and it keeps one slide as one slide — but it's a new navigation state, it interacts with morph and withstateOf, and a deck using it would open wrong rather than merely plain in an older shell. Considerably more surface than option 1.I'd take option 1 and be glad.
What I'm not asking for
Not a layout engine, and not a declarative animation timeline. I read the decision in #194 and the "claimed by the platform" list in #124, and I'm not trying to reopen either.
measure()andvalidate()gave me everything I needed to size my own output — I'd rather have one more primitive than a system.Happy to write option 1 if a maintainer says the shape is right and the page-number resolver is the correct place for it.
All reactions