Add incremental reveal to slides

[mike-ward]

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:

 - item1
 > - item2 reveal
 > - item3 reveal

for in-slide reveals

### Slide with a pause

content before the pause

. . .

content after the pause

[jdan]

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.

[mike-ward]

The . . . syntax is perhaps sufficient. Any line with only . . . and/or surrounding whitespace indicates a pause.

 - item
 . . .
 - item 2
 . . .
 - item 3

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.

 - item
 . . .fade
 - item 2
 . . .swoosh-left
- item 3

Also maybe , , , instead of '. . .` since commas usually indicate a pause in sentences.

[mike-ward]

Even more obvious

- item 1
/* pause */
- item 2

[guifromrio]

I am personally against it, as it adds a rather non-obvious syntax to Markdown. One of the best features of cleaver is it's simplicity. However, as always... PR welcome!

[mike-ward]

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).

[guifromrio]

How would you specify the class on the slide? What if we, instead, gave the opportunity to arbitrarily control slide navigation from "client" JS? I guess that would be a "cleaner" solution, in that this could be made a separate plugin of sorts.

What I'm proposing:

• Markdown should not be affected in any way. Determining whether a slide should have "incremental list" behaviour should be separate. This adheres to the principle that content and presentation must be separate. So, for example, in your script you could have a match parameter that you fed a string or Regex. If a given slide matches, the behaviour applies.
• When going back/forward, any "plugins" would be given a chance to be notified and either abort or continue with the operation. Then, it would be this plugin's responsibility to actually show/hide the elements when going back/forward.

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 ?

[mike-ward]

Cleaver currently supports adding classes to sldes.

Example:

-- my-slide-class

My proposal exploits a mechanism already in place.

[guifromrio]

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 backward and forward calls.

var onIncrementalSlide = function (slide, resolve, reject) {
  if (slide.anythingElseToShow) {
    showNext()
    reject()
  }
  else {
    resolve()
  }
}
Cleaver.onSlideForward('incremental', onIncrementalSlide)
Cleaver.onSlideBackward('incremental', onIncrementalSlide)

What do you think about something like that?

[guifromrio]

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.

[mike-ward]

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?

[guifromrio]

I'm not familiar with the Cleaver code either, so I was hoping you would correct me, actually :joy:.

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.

[mike-ward]

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.

[guifromrio]

For an immediate solution, simply hack on navigate :) https://github.com/jdan/cleaver/blob/master/resources/script.js#L13

[mike-ward]

No, no, no. Must concentrate on own projects. Do not be distracted by shiny :sparkles: new project :smile:

[guifromrio]

Same here :joy: