Incremental rendering

[paulrouget]

Incremental rendering

[paulrouget]

You're right, no incremental rendering yet. I want to do this, but I still don't know what is the right approach.

[reagle]

On Friday, July 15, 2011, paulrouget wrote:

You're right, no incremental rendering yet. I want to do this, but I still don't know what is the right approach.

Thanks. For what it's worth, html5slides, slidy2, and others have implementations.

I ask this because we been discussing a new presentation output format for pandoc and the author likes DZslides except for this feature missing.

[paulrouget]

Do you have any suggestion about what it should look like? My initial thought was to render incrementally elements that are in a <ul class="incremental"><elt1><elt2>...<eltN></ul> (same for <ol>).

Would it make sense?

[reagle]

I would defer to John, since his pandoc tool would be the one generating the markup -- but, yes, I imagine that would work.

On Friday, July 15, 2011, paulrouget wrote:

Do you have any suggestion about what it should look like? My initial thought was to render incrementally elements that are in a

...

(same for

).

Would it make sense?

[pci]

Oops, I issued a pull request without reading this first - my mistake!

S5 have a nice way of implementing both
<ul class="incremental"><li><li>....</ul> and
<ul><li class="incremental"><li class="incremental">...</ul>.
By just running a one-off script on pageload to change the first type into the second, and then just look for "incremental" nodes within a slide.

This has the nice bonus that "incremental" can be added to non ul/ol items as well.

[pci]

My Pull request (issue #13):

You can setup incremental rendering of a list in any of the following ways:
<ul class="incremental"><li><li>....</ul> (as suggested above).

In addition a .incremental-list class can be used on any element to make the list incremental:
`

• ....

....

` In each case the sheet will iterate through all the sub-elements one-by-one. You can also select individual elements to be incremented: `

`

As for styling there are three classes:
.incremental - elements not yet shown
.current - the most recently shown element
.incremented - elements that have been shown, if no style is given the element will use the default slide css

I think that's the sum of it!

[paulrouget]

I don't understand the need of 2 different classes here (incremental and incremental-list).

[pci]

.incremental-list is used to flag all (first generation) child elements as incremental.

.incremental is used to flag an element as incremental

Using .incremental on a ul/ol is legacy code and I really should remove it for consistency.

[hsablonniere]

My Pull request (issue #14):

In my implementation I got 3 classes

.incremental
Every HTML element having this class will be iterated through.

.incremental-list
Every direct HTML child of element having this class will be iterated through.

.incremental-skip
If you used .incremental-list and you want a child (or more) to be skipped out of the iteration. Put an .incremental-skip class on it and it will be revealed at the same time as the next element to be incremented (see example for details...).

Once you flagged your markup with this classes, next button will just iterate over elements having .incremental or being .incremental-list direct child in the same order as the position in the DOM.

If you have nested HTML lists, you'll have to put .incremental-list on each one. I though iterating through each child (direct or not) would be good but Philip had a good point : it would behave crazy with inline MathML, SVG, etc... Is it what you meant by recursive lists, Paul ?

For styling you can use above described classes and .incremented which is added after element has been incremented.

The implementation is different but it works almost like Philip. I missed one feature that I would really like to use : the .current class.

[pci]

I think Hubert and I have generally settled on the same classes for the end user (I think .current could easily be added to his, or .incremental-skip to mine to make them identical).

Our difference is in the implementation (please correct me if I'm wrong Hubert!):

• I've gone for simpler CSS : each element only ever has one of the revealing classes (.incremental, .incremental-current or .incremented) and the end users style sheet can use these three classes directly, e.g.:

.incremented{}
.incremental{opacity:0.1;}
.incremental-current{color:#F06;}
</style>```
However my javascript is more lengthy as I have to call an additional one-off function when template.html is opened.

 - Hubert has gone for simpler javascript : no need for the one-off function, all changes are covered by the new ```forward()```/```back()``` functions. However his css is more complex with elements having mulitple completing "incremental"-type classes that means the end user's style sheets aren't quite as simple, needing ```:not``` selectors and child selectors, e.g.:
```<style>
.incremental:not(.incremented), .incremental-list > :not(.incremented){visibility: hidden;}
.incremental-current{color:#bada55}
</style>```

It the end, we came to the conclusion that both methods had their advantageous and that the html implementation can be made identical, the difference is simply whether we want simple CSS or simple javascript.

Hubert, have I missed/misrepresented anything?

[hsablonniere]

No Philip you summed it up just right :-)

One small adjustment :
:not selectors aren't mandatory at all. I just use the fact that default visibility is visible but you could do the same with :

<style>
.incremental, .incremental-list > * {visibility: hidden;}
.incremented {visibility: visible;}
.incremental-current{color:#bada55}
</style>```

[paulrouget]

Ok, I have to catch up here. Working on it right now…

[paulrouget]

Random comments: We don't want to use classes, but attributes here (classes are for the slides writer). I'd like to avoid complex selectors in the editable part of dzslides. More comments to come…

[hsablonniere]

When you say attributes, do you mean ARIA stuff like the one used for current slide ?
So users would use that to add style on incremented items ?

I'm ok with that.

[paulrouget]

Ok, read and understood both approach. Both very good and quite similar.

But here, I'd like to introduce this notion of cursor (see issue #17).
Also, I think we should keep the same mechanism as we use for the slides:

  .incremental > * {
    opacity: 1;
  }

  .incremental > *[aria-selected] {
    opacity: 1;
    color: red;
  }

  .incremental > *[aria-selected] ~ li {
    opacity: 0.2;
  }

What do you think?

[paulrouget]

… and hidden in the DZSlides core, we would have something like this:

  .incremental {visibility: hidden}
  .incremental[active] {visibility: visible}

[paulrouget]

… and before setting the list as [active] we would select the first item as [aria-selected].

[paulrouget]

I like this method because it doesn't introduce any new classes, and only one attribute is created ([active]). And it's consistent with the slide selectors.

[paulrouget]

If one of you can try to implement this approach to validate that it could work, that would help a lot :)

[hsablonniere]

I'm on it...

[hsablonniere]

I'm done for today!

I've done some tries, I'm heading in the good direction but it's not that easy to implement in a simple manner.

To be continued...

[paulrouget]

Sure. Thx for the hard work. Let us know if you need any help here.

[paulrouget]

Fixed by commit 1841b19

[pci]

Brilliant work! A great solution in the end :)