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
discussion