S5 1.1a3
We’re up to 1.1 alpha 3, with the big news this time around being incremental display. So far, the way this works is that you can class a ul or ol element, and have the bullets in that list be incrementally displayed. This is easier to understand by seeing than by reading an explanation, so go check out the alpha testbed. In the first slide, all the bullets are displayed incrementally; you move through them by using any “next” action (keyboard or mouse). You can also back up using a “previous” action. The exception to this is the next and previous controls in the lower right-hand corner of the slide. These always move forward or backward by one slide.
On the first slide, all of the bullet points are greyed out until you advance through the slide. On the second slide, the first point is pre-highlighted. This is intentional; it shows the difference between the two ways of presenting an incremental list. On the third slide, the main-level points are all normal but the sub-list is incremental. Again, this is intentional. The highlight effect is completely CSS-based (using the class current), so every theme can have its own incremental-display look. I picked red because it was really, really obvious, and I was too lazy to think about what color would fit in better with the default theme. I’ll get around to tidying that up later.
The one thing I’ve made the system do but am not sure about is that when you back up to a slide that has incremental display, it starts out looking normal and then “un-highlights” as you move backward through the points. I’m not sure that this is desirable, but at the same time I think it could be very useful. (Plus you can always skip back a whole slide by using the lower-right controls.) I’d like to hear feedback on what people think about the way the incremental display works now, and how it could be better.
For those who want to play around with incremental display, you add a class of inc to a list whose items you want to be incremental. If you want a slide to start with the first point highlighted, add psf to the class value, so you have class="inc psf". If you want to reveal arbitrary elements one by one on a slide, individually class them with inc.
I don’t have all of the contributed code merged into the JS yet, but I’ve seen everyone’s contributions from earlier posts, so please be patient. I’m still at a loss as to how to make the intra-slide links work in Safari, and could use help figuring out what’s wrong there. To test it, hit the “skip to summary” link on slide 1 of the testbed. For that matter, if you uncomment the li:after rule in pretty.css, you’ll see that Safari keeps adding “NaN” into the classes of incrementally-displayed list items when you move back and forth from one incremental slide to another. I can’t figure that one out, either. Help is always appreciated.
So from my original 1.1a2 to-do list, the following are still left to do:
- A way to choose whether to show/hide all of the navigation controls, or just the menu. Indicating the preferred behavior via a
metatag is starting to feel more like the right way to go, since it means the presentation author can decide whether he wants the controls to be visible or hidden. The problem of exactly how to manage the behavior is as yet unresolved. - Better, possibly more dynamic, theme selection. I still don’t have a clear idea of how this would really work. It might be better to simply write a clear description of how to associate a new theme with the presentation file, and write up guidelines for theme authors.
- A way to indicate the target resolution in the CSS, so that the scripts can use that for scaling purposes (and thus make the scaling more intelligent). I’m actually leaning pretty heavily toward dropping this, because I don’t see a pressing need to include it at this stage. For the purposes of scaling foreground iamges, it wouldn’t be much more powerful than the author managing scaling via CSS.
And there you have the current state of s5 development. Feedback is welcome. Ever forward!
