Posts in the S5 Category

I’ve gotten a few e-mails and comments to the effect that instead of using a Creative Commons license for S5, I should use GPL instead.  One of the reasons given to me was that the Creative Commons licenses are not considered appropriate for software, according to the Creative Commons folks.

My problem is that I don’t really think of a collection of (X)HTML, CSS, and JavaScript as “software”, so the GPL doesn’t really seem to fit.  Yes, the JS is code, and one could argue that it’s software of a kind, but markup?  Presentational hints?  Not so much.  I feel the same way about the Color Blender: it’s not really software so much as a widget.  A fun widget, perhaps even cool to some people, but still not software in the way that BBEdit or NetNewsWire or any given Web browser is software.

My other problem with GPL is that it’s long and stunningly legalistic.  It kind of has to be, and I think that’s great for the purpose for which it’s intended.  To ‘protect’ things like S5 or the Color Blender, the GPL kind of feels like protecting a kitten with the 82nd Armored Division.  What I like about the CC licenses is that they’re easily understandable; even the “lawyer-friendly” versions are compact and mostly understandable.  In perusing the list of licenses over at the Free Software Foundation, I quickly got a headache.  The one license that seemed the closest fit is the Expat license.  But even there, given the way it’s written, I come up against the question: is a confederation of markup, styles, and client-side code really “software”?

So what to do?  Stick with the CC license?  Move to Expat?  Plunge into GPL-land?  Come up with my own variant license based on Expat or something similarly simple?  I’d be interested to hear people’s opinions—especially those of you who have faced the same question, or a similar question, in the past.

I’m still a little bit bemused that it’s even a question, and a little bit dismayed that ours is the kind of world where I really do have to worry about this sort of thing.

• S5 Licensing was published on Thursday, December 2nd, 2004.
• It was assigned to the S5 category.
• There have been forty-one replies.

Okay, S5 version 1.1 is now at beta 1 status.  In the process, I’ve rearranged the S5 sub-site a bit.  The testbed is now in a new location that will let me more easily manage version changes, and also keep test files out of the main directory.  The testbed demonstrates, at least right now, various forms of incremental rendering, including both text and image techniques.

There are some changes to note in 1.1b1:

• The controls div is now a child of the layout div, and is thus no longer structurally confined to the footer.  This makes a few things easier, but it does mean any 1.0 themes are likely to get mangled a bit.  I decided to do this now in order to minimize disruptions.  The structure reference does not reflect this, as it documents v1.0, but will when v1.1 is finalized.  I was able to convert the default theme, I18N, and a new theme to handle this new structure without much trouble.
• I’ve refactored some of the CSS files to make them more compact.  Nothing earth-shaking, but I thought I should mention it.
• The slideshow configuration meta elements have been renamed to defaultView and controlVis, and have slightly different accepted values, but otherwise do exactly what they’ve done since they were added.
• I’ve added an authaffil meta element, with syntax set up to allow multiple authors to be listed.  I’m considering making the value format a little more machine-readable, but we’ll see what you all think first.
• I fixed the Safari bug where it advanced the slide show when opening an external link.  Yay me.

I’m in the process of setting up an archive for ‘official’ S5 versions, so that you’ll still be able to download the S5 1.0 UI folder even when we’re up to 1.725 or whatever.  This will be in place for the launch of v1.1.  Yes, I hear you: use SourceForge!  I’m abstaining for now, because I don’t have time to figure out how to set up a project on their system, let alone how to fix their UI so it isn’t confusing and frustrating.  Mine may not be much better right now, but at least mine’s easy for me to fix (and I’ll get to it soon, I promise).

The other major addition I have planned is to create a set of guidelines for theme packaging.  For example, every theme should contain a file titled 00_head.txt that contains the head-based elements (links and so forth) that should be used in a presentation file in order to make the theme work.  This will make it much easier for presentation authors to use themes without having to understand the ins and outs of the S5 file structure, and for theme authors to only have to package the files they want to change.  Hopefully that will make more sense once I write the guidelines.

And finally, you may have noticed that I’ve stopped superscripting the 5 in S5.  Practically nobody else was doing it, and it was getting to be a pain even for me to type, so I figured I’d go with the flow.  I’ll change the documentation eventually.

So please test out the testbed and let me know if anything goes seriously awry.  If anyone wants to try hooking up the 1.1b1 UI files to their own presentation, I’d be interested in hearing the results.  Remember, though: make sure your presentation file’s XHTML validates!  If you report problems in an invalid presentation, I’m not going to look at it until the validation errors are corrected.  That’s because the DOM routines depend on well-formed markup, and it would be futile for me to try to debug any problems caused by invalid markup.

With luck, we’ll only need one or two beta cycles before 1.1 can go final.

• S5 1.1b1 was published on Thursday, December 2nd, 2004.
• It was assigned to the S5 and Tools categories.
• There have been twenty-eight replies.

Hey, we’re moving quickly: S⁵ 1.1a5 is now up.  The current testbed file uses XHTML 1.0 Transitional, the better to accomodate the “allow external links to open in new window” feature I added with prompting from Peter Murray and assistance from Dave Marks.  I’m thinking about generalizing the routines to just mark any link that starts http://... as an external, window-spawning link, but that to me seems a little too intrusive.  I tend to think it’s better to let the author mark which links should spawn new windows, and which should not.  If I’m wrong, let me know.

Among other bug fixes: incremental slides now wind and unwind correctly, and don’t leave the last point on the slide stuck in the “current” state even when you loop through the slide show more than once.  The show/hide for the controls has a slightly different behavior now, so I’m looking for feedback there.

The last bug I want to squash before exiting the alpha stage is that in Safari, when you click on an “external” link, it still advances the slide show one step.  All other browsers I tested (IE/Win, Firefox) didn’t, as was the intent.  I can’t quite figure out how to fix Safari’s problem, which seems to center on the new hasValue() function.

(singing) Beta slide show, here we come…

• S⁵ 1.1a5 was published on Thursday, November 18th, 2004.
• It was assigned to the S5 and Tools categories.
• There have been twenty-four replies.

Hooray, we’re up to 1.1a4!  The only real change here is that I’ve added a “what do you want to hide, the controls or just the popup menu?” feature.  This is handled with the following meta element:

<meta name="controls" content="hide" />

That will hide all the controls.  The default behavior is “show”, which shows the controls but not the menu.  The testbed file is currently set to hide the controls by default.

Only here’s the problem: the modifications I made broke the system in IE/Win.  It returns the ever-so-helpful message “Unknown runtime error” and a line number that doesn’t seem to make any sense to me, so I’m not sure exactly what’s broken, nor why.  Assistance appreciated. Okay, that problem got fixed with a rename suggested by Michael Moncur.  The problem now is the control menu doesn’t appear when you mouse over the lower right corner, although the controls show up okay.  This may be my fault, but help in figuring out how to make IE/Win consistent with Safari and Firefox is needed.  Thanks. Those of you using Safari or Firefox will see things as intended, at least until the IE/Win thing is fixed.  I’m especially interested in feedback regarding how the controls reveal and hide themselves in the testbed presentation.

I suspect I’m getting close to the end of feature additions for v1.1; at this point, I’d like to clear up any lingering bugs, possibly rework how the default settings are represented in the meta elements (but not their intent), and write up a quick guide on creating and using themes.  I think that will be more than enough.  I don’t want to try to tack on too much at once with each revision.

• S⁵ 1.1a4 was published on Wednesday, November 17th, 2004.
• It was assigned to the S5 and Tools categories.
• There have been fourteen replies.

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:

1. A way to choose whether to show/hide all of the navigation controls, or just the menu. Indicating the preferred behavior via a meta tag 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.
2. 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.
3. 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 s⁵ development.  Feedback is welcome.  Ever forward!

• S⁵ 1.1a3 was published on Saturday, November 13th, 2004.
• It was assigned to the S5 and Tools categories.
• There have been twenty-one replies.

I’ve posted an update to the testbed file that incorporates the new font-scaling routines from Michaël, and also a slightly corrected version of the internal-link slide routines contributed by Henryk Plötz back in the 1.0b2 days.  These routines all seem to work fine, except the internal-link routines don’t seem to work at all in Safari.  I tried several times to fix it, but I can’t figure out the problem.  So fixing that is now on the to do list.

Speaking of which, here’s the current to-do list for S⁵ 1.1, categorized by their importance.  Any of these are, of course, subject to modification, deletion, and so forth.

1. A way to trigger simple in-slide changes by hitting “next”.  For example, having a list of bullet points appear one at a time as the space bar (or other “next” action) is hit, and then moving on to the next slide.
2. The ability to cleanly list multiple authors in the metadata.  I’ll get back to this in just a minute.
3. Better, possibly more dynamic, theme selection.  I don’t know how yet, nor am I sure how it might impact the outline/slide show view toggling.
4. A way to choose whether to show/hide all of the navigation controls, or just the menu.  Ordinarily, I’d say “do it in the CSS!” and you can in fact do that right now… as long as you don’t care that the behavior won’t be quite right in Internet Explorer.  The problem is that I’m not quite sure how to manage this in a fully cross-browser fashion, short of scanning the CSS files for certain rules, and firing JS based on that.  Which, frankly, sounds kind of ooky.  Adding that information via a meta tag doesn’t seem like the right answer, but maybe I’m wrong.
5. A way to indicate the target resolution in the CSS, so that the scripts can use that for scaling purposes (thus making the scaling more intelligent).  I’m not really sure this is needed, and I’m open to being convinced one way or the other.

If there’s anything missing, let me know.  Also feel free to comment on what you think of the above plans.

Now for the metadata situation.  As I understand things, having read RFC 2068, you can have multiple HTTP headers that share a name so long as they’re interpreted as a comma-separated list of values associated with that name.  (Apologies if I’m mangling terminology, but HTTP headers aren’t really my thing.)  So given the following:

<meta name="author" content="Eric Meyer" />
<meta name="affiliation" content="Complex Spiral Consulting" />
<meta name="author" content="Joe Public" />
<meta name="affiliation" content="ConHugeCo Corp." />

…this is an equivalent construction:

<meta name="author" content="Eric Meyer, Joe Public" />
<meta name="affiliation" content="Complex Spiral Consulting, ConHugeCo Corp." />

I find this to be a long way from ideal.  In addition, since commas are the default value separator, if I understand the situation correctly,  I can’t really do something like this:

<meta name="authors" content="Eric Meyer, Complex Spiral Consulting; Joe Public, ConHugeCo Corp." />

…because that ends up as equivalent to:

<meta name="authors" content="Eric Meyer" />
<meta name="authors" content="Complex Spiral Consulting; Joe Public />
<meta name="authors" content="ConHugeCo Corp." />

That’s even further from ideal.  So here’s my current thinking for a way to represent multiple authors and affiliations:

<meta
 name="authors"
 content="Eric Meyer - Complex Spiral Consulting, Joe Public - ConHugeCo Corp." />

Anyone have a better idea than what I’ve proposed?  I’d love to hear it.  As part of said proposal, please keep in mind possible expansion of the information carried in the meta element.  For example, titles might be added, which in my current thinking would go like this:

<meta
 name="authors"
 content="Eric Meyer - Principal Consultant - Complex Spiral Consulting, 
          Joe Public - VP of IF - ConHugeCo Corp." />

It isn’t pretty, but it conforms to my understanding of meta value syntax.  As I say, I’d be very happy to be shown a better way of forming the meta values.

• S⁵ 1.1a2 was published on Wednesday, November 10th, 2004.
• It was assigned to the S5 and Tools categories.
• There have been twenty replies.

I’m working on S⁵ 1.1, and want to keep people involved in moving it forward.  So I’ve put up a testbed slide show file, which is simply a copy of the introductory presentation file that points to a new UI directory.  The current state of things, which I’ll call 1.1a01, adds two new features:

1. An author can indicate whether or not the file should default to slide show or outline view.  The default is slide show.  If you want it to default to outline view, you add:

   <meta name="slideshow" content="no" />
   

   The other possible content value is, obviously, “yes”.  This should be useful to professors who want to present notes in class as a slide show, and then post the same file to the class Web site in outline view.  The toggle key and button will both still flip between outline and slide show views, so you aren’t trapped in one or the other.  You just get to choose how the file will load up.

2. When in slide show view, the font size automatically scales based on the window size.  This means that if you’re expecting 1024×768 and get 800×600, the slides won’t become impossibly long.  Note, however, that this scales text—not images.  I’m not up to that yet, given that I have to think about how to (or even if I want to) handle them.  I’m using an onresize event handler to scale the fonts if you change the window size, as well as firing the scaling function when the slides are first loaded.  In outline view, the scaling is suppressed.

   In adding this, however, I’ve come up against the same problem that prevented font scaling from appearing in S⁵ 1.0: Gecko-based browsers mangle the layout when the font scales.  To see what I mean, toggle the slide view off and then back on.  Text separation, and the widths of inline elements, will not be recalculated when the slide view is restored.  The same kind of thing happens if you change the window size.  Once you’ve settled on a new size or toggled back to slide view, just hit Reload and all is well.  So it seems to be a case of not consistently redrawing element boxes when font sizes change; force them to be redrawn with a reload, and things are drawn as they should be.

   I can’t figure out how to fix this short of firing a reload event in the fontScale() routine, which I’d really rather avoid.  I suppose I could suppress scaling for Gecko browsers on resize (and fire a reload after toggling back to slide view) but I’d like to find a more elegant way to fix the problem.  For that matter, if anyone wants to make my scaling logic more elegant, go for it.  The frustration of cross-browser incompatibilities in manipulating styles came to the fore when I wrote that routine.

There are several ideas and suggestions from the 1.0 release that have yet to be implemented: be patient!  We’re on 1.1a01, remember, and S⁵, for all its promise, remains a “free time” project.  (My editors will no doubt be dismayed to hear that I think I even have free time.)  If I get time, I’ll write up a concrete to-do list so you can see what’s planned.  For now, if you’d like to help, please just focus on the problems I mentioned, or new problems caused by these features that I didn’t find.  Speaking of which, if any of you IE/Mac wizards can figure out what I’ve done that breaks S⁵ in that browser, I’d very much appreciate it.

• S⁵ 1.1a1 was published on Sunday, November 7th, 2004.
• It was assigned to the S5 and Tools categories.
• There have been sixteen replies.

Over the past few days, I’ve gotten a few complaints about S⁵ breaking in one browser or another—IE6 and Safari got the most mentions, but there were others.  As an example, there was a report that the slide show would just stop working after a certain number of slides.  In every case I’ve seen so far, these problems have been caused by invalid XHTML.

The most common validation problem I expect people to run into is with the structuring of lists.  For example, suppose you want two levels of lists on a slide.  You do it like this:

<ul>
<li>point one</li>
<li>point two
   <ul>
   <li>subpoint one</li>
   <li>subpoint two</li>
   </ul>
</li>
<li>point three</li>
<li>point four</li>
</ul>

Notice how the nested list is inside the li element?  That’s correct.  You should never put nested lists between list items on the ‘outer’ list, even though a lot of people have made that a habit.  The only element that can be a child of a ul (or an ol) element is an li.  That’s it.  Anything that needs to be ‘nested’ goes inside one of the list items.

Alternatively, you can put structures after the list, if that’s what you want.  As an example:

<ul>
<li>point one</li>
<li>point two</li>
<li>point three</li>
</ul>
<pre>
...code sample...
</pre>

Nothing wrong with that, as long as you keep the side content inside the <div class="slide">...</div> element.  Or you could put your pre inside the last list item.  It’s really up to you.

Remember that S⁵ stands for “simple standards-based slide show system”.  That’s not just marketing: the CSS and scripts pretty much depend on valid markup structures.  If the markup is invalid, it will very likely lead to confusion and unexpected results.  In other words, violate the standards and they’ll violate your slide show.  There’s a certain poetic symmetry in that, I think.

(And yes, I do know that as of posting, this entry doesn’t validate.  Believe me, the irony is not at all lost on me.  This happened because I haven’t gotten around to fixing WordPress so it strips HTML before inserting the entry title into the title element.  I ranted about the problem a while back… and it will eventually get fixed.  Possibly when I upgrade to the next version of WP.)

• S⁵ Validity was published on Tuesday, October 26th, 2004.
• It was assigned to the S5, Standards, and Tools categories.
• There have been twelve replies.