New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add incremental reveal to slides #111
Comments
Been thinking about it for a while, but currently your only option is to make each transition its own slide. Keeping this open to see if anyone has ideas for what something like this could look like. I'm not 100% into a special list syntax. |
The
It's easy parse and is minimally invasive. It's also visually easy to spot and edit. It also lends itself to some animation specifications via CSS classes.
Also maybe |
Even more obvious
|
I am personally against it, as it adds a rather non-obvious syntax to Markdown. One of the best features of |
What about just a class specification on the slide itself (incremental-lists)? Bullet lists for that slide would then be increamental. Doesn't require a change to the current slide syntax and covers the use common case of increamental reveal of lists. (I can do a pull request once we agree on the method). |
How would you specify the class on the slide? What I'm proposing:
This would amount to keeping the code of cleaver itself clean, while enabling all sorts of crazy functionality to be "installed". Thoughts, @mike-ward @jdan ? |
Cleaver currently supports adding classes to sldes. Example:
My proposal exploits a mechanism already in place. |
Ah, nice! Sorry I didn't know that. That's great, because then it would be as simple as having something that, given a slide has a class, wrap the
What do you think about something like that? |
Even better would be to have Cleaver emit events on the slide which bubble up and are handled by the root. If anyone wants to capture those events and stop the propagation, that's simple and pure JS. |
I think I'm understanding your code. Not familar with the Cleaver code, but it looks like the forward/back logic takes a promise given your example. Of course, the tricky part is the showNext() method. Thoughts on that implementation? Internal tracking or hang something off the DOM? |
I'm not familiar with the Cleaver code either, so I was hoping you would correct me, actually 😂. If you can wait until the weekend, I can give a look at the code and propose/implement a solid change. Otherwise, try your hand at it and let's see what happens :) The important thing for me is that we don't build any "arbitrary magic classes" into cleaver, but we build support for "arbitrarily controlling slides", and then an "incremental plugin" would be trivial to pull off. |
I'm buried in my own open source projects. I was thinking of a more immediate solution. A plugin architecture may be more too much for me at this time. |
For an immediate solution, simply hack on |
No, no, no. Must concentrate on own projects. Do not be distracted by shiny ✨ new project 😄 |
Same here 😂 |
Is there a way to do incremental reveal in slides?
If not, maybe something could be added? Pandoc does this a couple of ways.
In lists:
for in-slide reveals
The text was updated successfully, but these errors were encountered: