💾 Archived View for ser1.net › post › im-a-slidy-convert.gmi captured on 2024-05-10 at 10:47:34. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-03-21)
-=-=-=-=-=-=-
HTML Slidy is a way of putting slide shows (presentations) on the web. Think of it like OpenOffice Impress or MicroSoft PowerPoint, but more convenient and with less lock-in. Your viewers only need a web browser to view the presentation, and *everybody* has a web browser. Not everybody has MS PowerPoint. Not everybody has OO Impress. Furthermore, if you're on a conference call, it's much safer to use a web presentation than, say, NetMeeting, LiveMeeting, or whatever. In my experience, those are much more prone to network glitches bringing the entire meeting down than a simple HTTP connection. The one way that meeting software is superior to a web-shared presentation is that it's harder to sync advancing the slides with a web presentation.
Anyway, that's not what I was intending to write about. For years, I'd been using S5 for my slides. It works pretty well, but lately I've been using Slidy, and here's why:
1. Slidy is more lightweight. Boy, does S5 have a lot of JavaScript. There are a lot of files, in general, to use S5. Slidy is two files: one JavaScript, and one CSS (not counting image files, of course).
2. Slidy takes advantage of the fact that browsers have scroll bars. Yeah, ideally, you don't have them, but the fact is that it's never perfect, and there's always going to be somebody using an oddball sized screen so that one of your slides just doesn't quite fit. With S5, they'll never see that content. With Slidy, they just scroll.
3. I have experienced less wierdness with Slidy. Maybe it's because it is more simple, and doesn't get as fancy with the JavaScript as S5 does, but I encounter many fewer screwed-up layouts resulting from different browser vendor/versions. S5 was sort of twitchy. Slidy just works.
4. I've found that I spend far less time tweaking the input and output to get it to look right. In fact, with Slidy, it's usually just a matter of breaking lists (or, preferably, removing content), or setting the size on images. With S5, I'd sometimes spend hours tweaking font sizes to try to get things to fit and look right.
5. It's way, *way* easier to style Slidy.
S5 does have better transition support; but I don't use transitions. S5 does try harder to scale content so that it fits on the slide, and when it works, it's nice.
Mind you, I haven't actually written either S5 or Slidy HTML in a long while. I generate all of my presentations from RestructuredText, which is how I like it. There's a tool for generating PDF from Slidy called Prince that I haven't tried (it isn't freeware, and I haven't thought about trying to justify it to Management as a necessary purchase, yet); PDF generation of slides is about the only thing I'm missing.
Other things I've learned: pandoc's Slidy generation is painful, and I've yet to figure out how to coerce it to use *my* style sheets. It appears to utterly ignore the --data-dir directive, and insists on either linking directly to the W3C resources, or using it's own. rst2slidy works pretty well, but there's no real way to insert header images except my sed'ing the generated output (booo!), and docutils is broken in it's handling of images and SVG; it doesn't allow % in height or width, which is supported by HTML (c'mon, read the spec, people!), and it embeds SVG images in
tags, rather than tags, despite the fact that works better (like, browsers figure out the image size from the image itself) and is supported by all modern browsers. Despite these annoyances, it works remarkably well, and these are all easily fixed -- which isn't the case when things go wrong with S5. You can spend hours in the guts of the S5 CSS trying to get things to look right. I know. I have.
So, yeah. I've been using Slidy exclusively for about 8 months, and I'm definitely a convert. I spend less time tweaking it, and it's more reliable.