minor changes and new approach to incremental slides

[vuvova]

Here's the description of the commits:

1. "also show overview on Escape" — many javascript-based presentation frameworks show the overview on Esc key (e.g. flowtime.js, reveal.js, shower). dzslides doesn't and I originally thought that overview is not supported. Only later looking at the code I saw that it actually does work. I've made dzslides to show overview on Esc to avoid similar confusions in the future.
2. redo incremental lists: three commits. This changes the approach to incremental lists. Instead of putting "incremenal" in the UL element, one now puts "next" on every LI element. Benefits:
   • more flexible. "next" can be on any element, not only on LI. So any part of the slide can be incremental (there's an example with "next" on P)
   • simpler styles: only one rule to specify the behavior, not four (for UL, for UL:active, for LI, and for LI:aria-selected)
   • because any element can be incremental, the behavior can also be arbitrary styled. There's an example where text highlighting appears incrementally (color:yellow), while the text itself doesn't disappear or appear.
   • another feature: incremental elements can optionally have sequence numbers (using next-order attribute). They will appear in that order. There's an example too.
   • incremental elements behave as in shower — their incremental behavior happens only once, further back()/forward() don't make elements to disappear again. One needs to reload the page to reset incremental elements. This is very important — after a slide is completely shown, you can quickly go back and forth to any slide, answering questions of attendees, and and incremental behavior would only be annoying. I hated that in every my talk (libreoffice, Slidy, etc) — until I saw how shower does it.
3. other commits are pretty much self-explanatory

[paulrouget]

Thanks. I added you as a collaborator. Feel free to merge this PR.

[vuvova]

Thanks. But now, playing devil's advocate, I need to mention that

• I've only used it on firefox, up to 38.8.0 (I did email my presentations a couple of times and they worked for others, but this is no proper testing)
• about 862d504 — I think that in 2016 one does not need them on CSS3 attributes, but I did not test on other browsers
• 83245a3 — while long-awaited functionality (I personally wanted it for years), the feature is not fool-proof. That is, it works, but it's quite possible to generate a PDF that shows slides incorrectly or misses some text.
• a85357f — header/footer are done kinda hackish, they're in the body, not on every slide. So they don't move when the slide changes. That's why I use horizontal scrolling as a transition between slides and disable header/footer in the overview. It would be much better to have them on every slide
• new incremental syntax changes existing behaviour. Luckily, DZSlides is just one file (and that's what I love about it), so users will hardly ever upgrade DZSlides in the already existing presentation, that is backward compatibility is not really an issue. But you might still have some concerns about it.

So, just to know for sure, what commits out of everything I have it my branch, you want me to merge?

[paulrouget]

about 862d504 — I think that in 2016 one does not need them on CSS3 attributes, but I did not test on other browsers

I think it's ok. All browsers have dropped the prefix afaik.

83245a3 — while long-awaited functionality (I personally wanted it for years), the feature is not fool-proof. That is, it works, but it's quite possible to generate a PDF that shows slides incorrectly or misses some text.

Still progress. Land it.

a85357f — header/footer are done kinda hackish, they're in the body, not on every slide. So they don't move when the slide changes. That's why I use horizontal scrolling as a transition between slides and disable header/footer in the overview. It would be much better to have them on every slide

Right. Maybe skip that one then.

new incremental syntax changes existing behaviour. Luckily, DZSlides is just one file (and that's what I love about it), so users will hardly ever upgrade DZSlides in the already existing presentation, that is backward compatibility is not really an issue. But you might still have some concerns about it.

I'm ok with this. Land it.

So, just to know for sure, what commits out of everything I have it my branch, you want me to merge?

I'm ok if you land all of them. Up to you about the header/footer thing.

[vuvova]

Okay, thanks. Then I'll push everything — just tested, if header/footer are not used they don't affect anything (so one can use them with certain transitions and inside a slide, or one can not use them at all).

Thanks!