meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Archive: 'S5' Category

S5 Primer Online

For those who aren’t sure how to tackle creating an S5 presentation, I’ve put a basic primer online.  In addition to explaining the basics of an S5 presentation, it links to a ZIP archive of a “blank” presentation, so you can use that as the basis for any presentations you create.

I’m planning to write in the near future a short guide on how to switch themes.  It isn’t quite as simple as it first sounds, mostly because of the possibility that an author would create a theme package containing only the files that need to be replaced, instead of everything that usually goes in the ui/ directory.

Like it says at the end of the primer, let me know if anything’s missing or unclear.

S5 1.0

Okay, folks, here it is: S5 version 1.0.  In addition to a few minor tweaks to make the system more robust, I’ve created a couple of themes to add to the ones Martin Hense created.  I have links to them all on the new S5 Themes page.  Share and enjoy.

One of the more notable tweaks is that the URL of slides.css is now read by the JS at document load, and used from then on.  Thus, you can point to a slides.css that’s in a different location than the rest of the UI files, if you so desire.  Another change is that the introductory slide show now contains some images, including one that maps out the file structure.  These were added so that new users would have some inkling of how to put images into a slide show.  There may of course be other ways of accomplishing the same task.

There were a number of good ideas and code contributions, but they were also too last-minute to be included in v1.0.  I’ll add them to a “to do” list for v1.1.  As to the suggestion that the project be moved to SourceForge, it’s certainly an idea I’ll explore further.  I don’t know enough about SF to know how such an arrangement would work; I only ever go to SF to download stuff, and find the site to be somewhat annoying in that it’s never immediately clear to me what I’m supposed to download, not to mention finding detailed information about whatever I’m downloading seems much harder than it should be.  For now, I’ll keep S5 local to meyerweb.  It can always be migrated over to SF later on, if that turns out to be a good idea.

There are still limitations in the system.  For example, if the slide show assumes 1024×768 and your window is 800×600, then you’re likely to have content cut off by the footer.  So edit the CSS to assume 800×600 (the easiest step is to lower the font-size of the body element).  Or set things up so that scrollbars will appear on the slide content if it overflows the slide.  You get the general idea, I think: this is very much a DIY-type system, at least for now.  The JS works, and the core styles help it work, in a cross-browser fashion.  Anything after that is up to the theme author.

There may one day be routines that automatically scale text, or dynamically break up slides, in order to solve the clipping problem.  There may also be features that let you trigger animations by hitting “next”, let you easily integrate SVG content, allow the use of the navigation menu in Opera Show, permit dynamic theme selection, and so on and so on.  For now, we have a good standards-based slide show system, one that should suffice for a great many people.

And my deepest thanks to all those people who have contributed, directly or otherwise, to S5, including those who made suggestions I haven’t yet folded into the system.  You have made, and will continue to make in the future, S5 better than I ever could have made it on my own.

S5 Final Candidate

Thanks to the efforts of many people, the slide show system I’ve been working on is just about ready for prime time.  Thus, I hereby dub it S5 and place it into Final Candidate status, complete with documentation of the markup format and a map of the files that are used for an S5 presentation.

There is one thing I’ve found that needs to be addressed before exiting the FC stage, and that’s the handling of slide titles that contain markup.  If you look at the slide show S5: An Introduction, the navigation menu entry for the title slide is ” 0: Snull: An Introduction”.  It should be ” 0: S5: An Introduction”.  I know this has something to do with walking the DOM tree and collecting the appropriate bits, but I’ve yet to figure out how to do that efficiently.  Assistance, as always, is appreciated.

There are a few limitations that will exist even after S5 goes to v1.0.  These are summarized on slide 8 of the introductory slide show, but I’ll explain them in a little more depth here.

  • Only one author can be listed in the metadata — This limitation is largely inherited from OSF 1.0.  Mark Schenk and I have talked about ways to get around this limitation, but have agreed to postpone fixing it until later; for now, it will be better if S5 1.0 and OSF 1.0 are as compatible as possible.  When I start working on S5 1.1, I’ll come back to this, and will probably kick around some ideas in public for your comment.  But that’s for later.
  • Links from within a slide to another slide will probably fail — Henryk Plötz created routines to fix this limitation, but I don’t have time to analyze and understand how they work before going to v1.0, and I’m very much against just dropping things into the JS unless I understand what they do, and how they do it.  I expect to get this functionality into S5 1.1.
  • The navigation controls are limited to the footer — This is in some ways a matter of convenience, and also a matter of consistency.  If the controls are known to be in the footer, then theme authors can write their CSS accordingly.  I may—and note I say may—relax this restriction in a future version of S5.  For now, it stands.  (Update: by “limited to the footer”, I mean it’s limited in a structural sense.  You can still visually place the controls anywhere CSS will allow.)
  • Slide content is expected to be static and atomic; that is, there is no capability to trigger dynamic slide content by hitting the “next” command — It would be nice to allow a slide author to trigger a slide animation (or whatever) by just hitting a “next” key, the way Powerpoint does.  It’s probably easy to do.  It won’t make it into 1.0.  So the expectation is that any given slide is a set of text and/or images, and that when you advanced you go to the next slide.  Of course, an author can still embed a Flash file or a QuickTime movie or an animated GIF or whatever.  There just isn’t the ability to click the mouse button or hit the space bar and have new content revelaed on the same slide.
  • Fonts are not scaled based on display resolution and available pixels; manual CSS editing is required — Again, largely a matter of convenience.  I tried dynamic font scaling and discovered that Firefox had major problems with what I’d done.  I’ll worry about it in a later version.  For now, if you create your slides assuming 1024×768 and find yourself in an 800×600 projection environment, you’ll have to edit the CSS directly to change the font size (and anything else that has to be changed).

There’s one other limitation I didn’t put on the slide, but I’ll briefly cover here.  As yet, it is not possible to embed all of the CSS and JS into the presentation file (that is, the XHTML file) and have the system work as widely as it does when they’re external.  The culprit again was Firefox, although it’s as likely that the real culprit is how I scripted things.  For that matter, it will never be possible to have complete standalone S5 files for any presentation that includes images or other external resources, because IE/Win doesn’t support data: URIs.  (Okay, never unless this capability gets added to IE/Win.  Don’t hold your breath.)  I do intend that a future version of S5 will allow the embedding of the CSS and JS.  Version 1.0 will not.

One other note: to keep things more consistent with OSF 1.0, I altered the S5 format to use h1 elements for slide titles, whereas before they were h2 elements.  I’ve also dropped the currentSlide, header, and footer divs into a layout div.  You can get a more detailed look from the reference.

All right, I think that’s enough from me for the moment.  Please try out the introductory slide show (also available as a ZIP archive), check over the documentation, and let me know if you find anything broken (fixes always welcome!) or incorrect.  Other feedback on the documentation, or on the content of the slide show, is also welcome.  Suggestions for new features or ways to fix the known limitations are not prohibited, but they will be shelved until after version 1.0 goes to final release.

Slide Show Beta 2

Thanks to the help of several contributors, the simple standards-based slide show system I put into public beta status, and which I may well end up calling S5, is almost ready to go final.  At its core, it seems to work consistently in Internet Explorer (both platforms), Firefox 0.9, and Safari 1.2.  I’ve also scripted things so that the system works in Opera 6 and up, basically allowing those browsers to fall back to using Opera Show.  This allows the slide show’s behavior to be consistent with what Opera Show users already expect, which seems like a good thing.

There are two things that don’t work as I’d hoped.  The first is the “click anywhere to advance a slide” feature, which is broken in IE/Win.  It throws a JavaScript error about the target that doesn’t make sense to me.  The second is the show/hide of the menu in IE/Mac, which I just cannot get to work.  If anyone can figure out how to make those work, let us know in the comments; otherwise I’ll just prevent IE from running that code in the final version, which will of course mean a reduced feature set in those browsers.  I’m not going to lose a lot of sleep if that happens, but I’d rather have the system be feature-consistent across browsers if possible.

(Update: if you downloaded the archive between 1421 EDT and 1504EDT, grab it again.  I initially forgot to update it with the new files.  Sorry!  It’s fixed now.)

Slide Show Beta

Not many people know about it, but several major version numbers ago, Opera introduced a feature called Opera Show.  This feature allowed you to invoke a projection-medium display mode by hitting a single key.  (They’ve since introduced a similar single-key invocation of a handheld device.)  In this mode, any style sheets that applied to the projection medium were used to present the document.  It was a lightweight form of Powerpoint—not as powerful, perhaps, since it was best suited to showing a slide show of static pages, but definitely useful.  Many of my talks over the last two years have used Opera Show.

The great thing is that with one (X)HTML document, you can have a slide show, a printer-friendly version, and a screen presentation.  I put markup and CSS examples right there in the document, ready to be printed, and simply hide them in the slide show.  In some cases, I printed out the file for handouts, and then used the exact same file for the slide show.  It was very, very handy.  It was also browser-specific… and when Opera 7.5 for OS X came out, it introduced a problem: the banner ads showed up even in slide shows.  I didn’t really feel like buying a Web browser just to make my slide shows neater—if I were going to spend money on a presentation solution, I’d be much more likely to buy Keynote.

About the same time, though, Tantek Çelik was using a slide show system he’d cooked up, one that was nominally cross-browser.  It used CSS, JavaScript, and a single HTML document to create slide shows.  Here’s one example of a slide show using his approach.  I liked what he’d done, but when I dug into the guts I found that it had certain limitations I didn’t like.

(Aside: Apparently Steve Champeon has been using a similar slide show system for a while—here’s an example—but it has many of the same things I didn’t like about Tantek’s approach, such as explicitly ID’ing each slide in the markup.  My script assigns IDs dynamically, thus freeing you from having to number the slides in the markup and thus making it much easier to rearrange or insert slides.)

So I took Tantek’s idea and expanded on it, making it more flexible on the markup end and adding some features.  I’ve run into some stumbling blocks, though, and so in the best tradition of the LazyWeb, I’m turning to you folks for assistance.  Here’s the latest test file, and here’s an archive containing the test file and its associated files.  At the moment, the best (as in “most like what I expect”) rendering of the slide show is in Firefox, although it may seem a bit sluggish.  Other browsers have one or more problems; these are documented in the test file.  My goal is to bring Firefox, Explorer, and Safari together in terms of how they act.  Opera is secondary because I currently plan to hide all of the stuff I’m doing from Opera, and let it handle the slide show via the built-in Opera Show.  It won’t have quite the same functionality, I admit, but it will be good enough for me to call it done.

Note that the test file itself contains a bullet-point explanation of what’s going on, and lists the bugs I’ve yet to squash.  If you’d like to help squash them in return for credit in the source code, go crazy.  If you’re more in the “I want to use this” crowd, then you might want to wait until the system exits beta.  How will you know when that happens?  First, I’ll announce it on meyerweb.  Second, it will be given a jazzy name of some kind (thus causing the name of its directory to change).  And third, the word “[BETA]” won’t be plastered all over the test document.

Most of my current bugs are DOM and JavaScript related, although there’s a presentation problem in IE/Win that I frankly just haven’t had the energy to tackle.  Note that I’m willing to use detection methods in the JS to make the features work, but I am not willing to serve up browser-specific style sheets.  Call me a purist, but I just can’t bring myself to go there.

I’ll leave comments open for people to share information on bug fixes, or suggestions for ways to go about fixing them.  Also, if you run into a problem not listed in the slide show, you can leave a comment.  NOTE: I don’t care if the slide show feature doesn’t work in NN4.x, because I’m planning to hide all CSS and JavaScript from that browser before this exits beta.  That means NN4.x users will see a perfectly straightforward HTML document, not a horribly mangled attempt at the slide show.

My appreciation for whatever assistance people can provide.

August 2014
SMTWTFS
July  
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Archives

Feeds

Extras