Modern HTML Presentations

I'm looking for any and all thoughts, concerns, and feedback on a number of plans for this project.

1.0

SemVer

The deck.js project currently does not use semantic versioning. There is only a "stable" branch, and "master" serves as an integration branch where I can live with changes for a while before merging into stable. When I initially released it, this was just something I decided to punt on until it became necessary. When the project grew to a point that it made sense, I turned it into an experiment. How long could this thing go until versioning became an issue? I haven't fielded a complaint about it in those two years.

But as you'll see below, going forward without a versioning scheme would be a problem. The only reason it's worked until now is relative stability of the API from Day 1. I want to make some breaking changes to the current API. Before that happens, there needs to be a version to break from. So the first order of business will be to release the 1.0.0 version of deck.js.

Fix (Some) Open Issues

I've created a 1.0 milestone in the issue tracker. It's bug fixes, little style tweaks, documentation improvements, @flavorjones's SCSS improvements, etc. There is only one issue that is technically an API addition, but I don't think the changes it introduces will effect any 3rd-party deck extensions.

1.x, 2.x, beyond

These ideas are in no particular order.

Extensions

I believe extensions could benefit from a little more structure in how they're integrated with deck core. My instincts say that this change can be made without breaking backwards compatability, but I'm 100% willing to break it if needed. I want to expand extend to take an object. The properties of this object would look something like this...

• name: Required. A string to identify this extension.
• methods: Optional. A hash containing new methods. The equivalent of using the current extend.
• options: Optional. A hash of options to add to the deck options object. Extension options will live in their own namespace, but if there are multiple extensions with the same option the user can use an "all" option during init to pass those options to all extensions. If a user wants to disable an included extension, they can pass "false" to the namespace of that extension on init.
• events: Optional. A hash of callbacks for deck events.
• keys: Optional. A hash where keys are the keyboard keys (using something like keymaster and values are an object that says what method to call and a brief description of what that method does. The hope is that this will resolve key conflicts between extensions that we cannot deal with using the current each-extension-deals-with-its-own-key-binding approach. It also allows for API expansion to get a list of all the available key shortcuts. And this.

Here is a sample of what the goto extension might look like. I believe the current extend with a method name and function arguments could be deprecated but still used, and removed in a later major release.

Stop officially supporting integrated decks

By integrated decks I mean embedding the deck container into any arbitrary page. The CSS in particular jumps through some hoops to avoid stepping on any styles that may exist elsewhere on the page. It will be simpler all around to expect the deck to be the only thing on the page using a standard boilerplate. If users want to embed decks into a page, they would be encouraged to create them as a separate resource and embed them as an iframe.

Less jQuery plugin, More classes utilizing jQuery

I want to move away from $.deck(...) towards new Deck(...). This would be the first step of a few towards framework agnosticism using the adapter pattern.

Move some extensions into core, move other extensions to external projects

Hash needs to become part of core. It's integral to other extensions and I can't think of a downside to including it. This is already a ticket. This ARIA ticket should also be worked into core and the default extensions. I want to move menu and goto extensions out of the main project into external extensions. I feel they're less useful to the general public.

End support for "complex" slide configuration

When this thing was first created I conjured up some ridiculous use case for non-traditional slide configurations. You can see an example of this in the complex.html fixture in the test suite. Slides that are out of order, nested in reverse, elements that are more than one slide, etc. Nobody utilizes this flexibility and I don't blame them. It's not very useful.

Supporting only the typical heirarchical slide/subslide/step form of presentation may allow for simpler code and some useful API additions (getTopLevelSlides???).

Rework CSS states

Restricting to a normal heirarchy should allow for fewer slide state classes and applying them differently. Right now you may have a deck in the following state:

.slide.deck-before
.slide.deck-before.deck-child-current
  .slide.deck-before
  .slide.deck-previous
  .slide.deck-current
  .slide.deck-next
  .slide.deck-after
.slide.deck-after

I'd like to change a deck in the same state to...

.slide.deck-previous
.slide.deck-current
  .slide.deck-current
  .slide.deck-current
  .slide.deck-current
  .slide.deck-next
  .slide.deck-after
.slide.deck-next

This state application recognizes subslides as what they are, steps, and removes the necessity for the deck-child-current class. It would also allow this issue to be easily solved in core CSS without bolting on the deck.horizon gist/extension mentioned in the ticket.

New Correlated Projects

Probably more work than all of the above changes combined...

Extension Discovery (and more)

The wiki is cool and all, but I'd like to create a real project to track extensions/themes/related-projects and help people find them. Perhaps something in the same vein as Grunt and its plugin page? Perhaps these plugins and themes could be selected, built, and downloaded in a ready-to-go boilerplate zip for the user? If anyone has any suggestions for other useful functions this site could include, I'd love to hear them.

Component Toolkit

There's already a ticket open on this. I imagine this project being CSS only and containing mainly slide layout related styles. This vcenter class is the only one that exists in core so far but I'm excited to sit down and put thought into other layout patterns commonly used in presentations.

CC @infews @mikeharris100 @iros @cykod @barraq @nemec @flavorjones @twitwi

Hello,

I'm working on a HTML presentation with DeckJS and I'm facing an issue with Chrome

http://vjeux.github.com/jsCollaborativePresentation/#title-slide

Chrome 13.0.782.215 m

• If you refresh the page on a slide. The particular slide will be blank after reload.
• Also, if you refresh on the first slide and move forward. After the slide 10 they stop appearing correctly, there are many artifacts.

Chrome 15.0.865.0 canary

• If you refresh the page on a slide. If you move around, you will see that many slides appear on the page, displaced ...

However it works perfectly fine on Firefox, therefore I don't know if it's a bug you can fix.

Those strange artifacts appear to happen when I put more than 10 slides. It does not seem to be a markup problem as they work perfectly when the slides are alone.

Hey,

Have just started using deck.js tonight for a preso tomorrow, and I'm impressed! I've even managed to get some event handling for some ideas I have in there, and no show-stoppers so far, which is great.

However, I must say that having presentational rules bundled in core.css does somewhat bugger up my theming, especially because of the specificity of your rules overrides my basic headings, i.e. .deck-container h1, is always going to trounce my h1 (my slideshow isn't embedded, so why would I need this specificity?)

Any chance you could separate presentation (formatting, padding, etc) and and functional (slide definition, positioning, movement, etc) rules into two different stylesheets?

Thanks, Dave

I use deck for release notes. A couple of users (Mac Pro, Mac Air) report text of multiple slides collapsing on top of each other when either the swipe action on the Mac Pro is used or the Mouse is used to navigate between slides on the Mac Air. Both users running Safari 5.1.4.

Both users also report that keyboard navigation works fine.

Mouse navigation on a PC running Safari 5.1.4 does not appear to be enabled ( I neither set it up, nor exclude it in the files).

Thanks.

I would like to have a feature, where i can press a key and get a version of the presentation, which I can print. Or at least a CSS-File, which can be used, if I want to print the slides. For example, print 6 slides per page (2 columns and 3 rows).

There was a padding (horziontal only) for the .deck-container in the reset css. I feel container should have have this padding by default. It also "breaks" the fit extension.

NB: the "make" changes more (e.g. #ccc -> #cccccc) so I commited only the relevant changes.

When I use the scale extension I can no longer scroll in the menu screen (it acts like overflow:hidden). If I don't include the scale extension, then menu works as desired--menu behaves like overflow:auto

Hello! I am trying to understand deck.js and how to design my own theme. I'd like to design a page with header and footer (like http://imakewebthings.com/deck.js/). To do that, i need to include all the <section> tags inside an <article> or a generic div. But when I do that, the page doesn't work anymore (the arrows disappear and the slide movement too!) Anyone can help me?

Thanks a lot Mari

Hi,

As quickly mentioned on the mailing list, I extended deck.js to allow for interesting animation-like extensions.

An demo of such extension (SVG animations) can be found there: http://home.heeere.com/data/deck-js-demo/examples/svg-animations.html

This pull-request offers the cleaned version of my changes. Feel free to pull it (or not) or to discuss it.

Thanks, Rémi

One nice feature of PowerPoint and Keynote is that the slides are displayed as designed, and do not change depending on the screen size. This can be an issue when connecting to a projector which changes the resolution of the display.

Hi, I am using deck.js for presentations and the default font size is way to small in full screen mode. So I modified the theme as described here (I tried both approaches): https://groups.google.com/forum/#!topic/deckjs/4wo115wdJKo

This creates a problem, however. When I set the default font size for .deck-container to 2em instead of 1.25em, pages are only properly reloaded when I am at the beginning of a section slide. When I slide in a li or div element with some text and then reload, this element is at the top of the screen and h2 heading is not visible.

Does that make sense? I can provide a concrete example if it doesn't.

Thanks!

Hi folks, this is a great lightweight project! Could someone help me figure out why

<dl>
<dt>description term</dt>
<dd>description definition</dd>
</dl>

is not shown as expected: https://www.w3schools.com/tags/tag_dl.asp

Hi, I am trying to include the deck.js (boilerplate.html) in the main web page. So basically include the slides at the bottom of the existing web page how do i do that with the deck.js.... Regards Ranga

Thanks for the clean slide deck.

I noticed on code validation that you use aria-role="navigation" and aria-role="status". The correct syntax for this is actually just:

• role="navigation", or better yest just style a nav element
• role="status"

If you've got more than 16 slides, the menu will not show them all and not leave the possibility to scroll up or down. Tested on up to date FF, Chrome and IE (Win10).