Posts in the Tools Category

S5 1.1a1

Published 20 years, 1 month past

I’m working on S5 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 S5 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 S5, 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 S5 in that browser, I’d very much appreciate it.

More Tools

Published 20 years, 1 month past

For those who are interested, I’ve added some new stuff to the Tools page, in addition to reordering it just a little.  The first addition is a URL decoder/encoder, something I’ve needed from time to time when trying to unravel encoded-JavaScript bookmarklets.  I’m sure every other developer in the world has created his own version of this tool at some point; well, here’s mine.  The second new toolbox entry is for users of NetNewsWire 2: a small collection of themes.  There are three as of this posting, each with a very, very different aim—one artistic, one historical, and one technological.

Hopefully I’ll have more to add to the S5 portion of the toolbox in the near future.

  • More Tools was published on .
  • It was assigned to the Tools category.
  • There have been no replies.

S5 Validity

Published 20 years, 1 month past

Over the past few days, I’ve gotten a few complaints about S5 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 S5 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.)

S5 Primer Online

Published 20 years, 2 months past

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

Published 20 years, 2 months past

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

Published 20 years, 2 months past

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

Published 20 years, 2 months past

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

Published 20 years, 2 months past

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.

Browse the Archive

Earlier Entries

Later Entries