Change in file structure. Now the ui/ directory will contain only directories. Thus, the default theme and scripts live in ui/default/. The reason for this is so that other themes can be put in the ui/ directory without things getting too confusing. For example, the current beta version has a v11b2/ directory (the beta’s version of ui/) that contains default/ and i18n/. Switching between them does require manual editing of the XHTML file, as I decided to punt on dynamic theme switching for now. This does, however, let an author carry around a single ui/ directory with a number of themes contained inside. That way, he might have four presentations to give, each one with a different theme, but all of them sharing the same ui/ directory.
Another advantage to changing the directory structure is that v1.0 presentations won’t be compatible with v1.1 themes. That’s actually a good thing, since the XHTML structure changed in small but significant ways in v1.1b1.
I thought about further splitting the default directory into “script” and “style” subdirectories, but this seemed like a bit of overkill. However, I’m starting to wonder how to handle things like IE/Win behaviors, which I suspect will be needed before too much longer. Why? Look at the images in the v1.1b2 testbed: they all have flat white backgrounds. I’d like to turn them all into PNGs with alpha channels, and I’d like to have those work as intended in IE/Win. The only way to make that work right now is via behaviors like this one. I’ll want to drop those behaviors into the default/ directory—my leading candidate would actually be IE7, once it gets close to being stable, mostly because it would add quite a lot to theme authors’ CSS toolkits. But all those behavior files could clutter up the directory, for which the easiest fix is to drop them all in a subdirectory… you probably see where I’m going with this.
That’s all for another version, though; v1.1 won’t have any behaviors packaged by default. It’s just on my radar, and I thought I’d toss it out to see if anyone has bright ideas.
A “header” file for themes. You can see an example at v11b2/i18n/00_head.txt. Briefly, this file contains material destined for the
headelement of any presentation that’s going to use this theme. In the case of i18n, the only thing that changes is the
linkelement pointing to
slides.css. Nevertheless, the header file provides all of the
scriptelements that should appear in the presentation file. This should make it easier for an editor program to just grab each block and paste them over the existing block in the presentation file. It will also reduce ambiguity for anyone doing a manual edit to change themes. (Open header file, drag-select, copy; open presentation file, drag-select, paste, save, done.)
Changes to incremental class names. In earlier versions, incremental-display objects were marked with a class of
inc, and any list that should start out already showing the first list item got a class of
psf. I’ve changed those to
show-first. The new names require a little more typing, but they’re much less ambiguous and therefore much more author-friendly. I’m interested to see if anyone has ideas for better names, especially for
As for the issue of licensing, I guess I’m little further along, but not all they way yet. The discussion did help me focus on what I want.
Presentation content should be under whatever license/terms the author desires. I do not want to force all S5 presentation content to be public domain, or GPL’ed, or whatever. If someone wants to give a highly confidential talk using S5, they should be able to put the most restrcitive license in the Universe on the content… but only on the content.
Themes should similarly have their licenses, or lack thereof, determined by each one’s author. If Joe Consultant wants to create a MyCoolCo theme and release it under copyright so that anyone can use the theme for their own presentations but nobody is allowed to re-use his images/look-and-feel/whatever outside the S5 theme, there should be nothing that stops him from doing so.
The S5 system (JS, core CSS, and the way they’re put together) should be forever free to use by anyone who wants to do so. It should be open for future development, in the event that I stop developing it and someone wants to keep going. This would also allow anyone to fork off their own variant on S5 at any time, but that’s okay too.
Here’s where it gets a little tricky: S5 should be able to be incorporated into any other project, commercial or not, without restriction. Attribution to the original source is to be strongly encouraged, but not an absolute requirement. But at no time, and in no way, should use of S5 in a closed environment ever cause a back-flow of restrictions to the original project.
In other words, anyone should be able to use S5 or a derivative work in their for-profit, wholly proprietary, patented software (or in any other circumstance). They can even make modifications, if they like. However, there should be no way for their use of it in a closed system to infect the original S5 source, and if their modifications make it into a future version of S5, the same should hold true. I don’t even know if that’s possible, but it’s in the spirit of the Share Alike terms in the Creative Commons licenses. You want to build S5 support into your $49.95 fully copyrighted and licensed editor? Fine, no problem. You want to extend S5 to do more cool stuff? Also fine, but freely contribute the changes back to the place you got the code in the first place. Don’t try to claim the original project has no right to the additions you made to it, or that the addition of those changes to the original project makes the whole thing yours.
(Not that I think any of you would do such a thing, but I have to think ahead to when S5 catches the interest of someone… well, let’s say less scrupulous.)
In a sense, I want to prevent major infection of licensing terms in both directions. I’m not entirely sure where that leaves me, but I’d like to work it out before 1.1 goes final.