S5 1.1a1
Published 20 years, 1 month pastI’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:
-
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
contentvalue 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. -
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.
Comments (16)
For the Gecko resize bug, a workaround is to set body‘s display to “none” then back to “block”. Basically forces everything to be recaculated, so things go sane again.
It’s still pretty broken though – that and I wasn’t sure whether the reload you mentioned is this, or something else; so you probably knew this already.
I’d like to use a package like this for presentations that include SVG, under Firefox only if that’s the only way it can be done; it’s then possible to include little live demos within the slides, using some javascript and possibly XBL. I haven’t had any luck getting SVG to display when simply included in html, but it doesn’t seem to take too much (replacement of two innerHTML() calls, mainly) to apply S5 to xml. I’m groping pretty blindly on this, so any suggestions appreciated.
Also: am I alone in wanting a print version that looks pretty much like the slideshow version?
I’m actually a little curious about the ‘text scaling’ bug. I started playing with s5 a week ago but found that text could be comfortably scaled by just using the browser (Firefox) text resize functionality.
Is the aim of this bug to make that process completely transparent and automatic so as to avoid minor manual labour like this? Or is the bug actually something much larger that I’ve missed?
As regards image scaling: Why not leave that up to the author? Including some classes that can be added to images for dynamic sizing with height or width as 90% (for instance) and allow the browser handle the aspect automatically.
I’m extremely impressed with everything so far though, and look forward to the progress. Here’s to free time!
If you want to hack around gecko bugs you might be able to take advantage of https://bugzilla.mozilla.org/show_bug.cgi?id=258917. If you call something like
history.go(0)in anonresizehandler the display will be redrawn but otherwise nothing will happen. Of course it’s better to avoid this if possible…Well, i think its bad, that if i resize to 800*600 I can’t read the whole text, because it’s covered by the slide’s title.
Firefox 1.0 RC2 on Windows
But keep the nice work going!
And a, uhm, wordpress bug here:
Warning: Compilation failed: nothing to repeat at offset 0 in /home/httpd/vhosts/meyerweb.com/httpdocs/eric/thoughts/wp-includes/functions.php on line 1357Warning: Cannot modify header information - headers already sent by (output started at /home/httpd/vhosts/meyerweb.com/httpdocs/eric/thoughts/wp-includes/functions.php:1353) in /home/httpd/vhosts/meyerweb.com/httpdocs/eric/thoughts/wp-comments-post.php on line 89I get alot of these on a blank page when posting a comment.
Regarding Gecko’s “bug”, I’d suggest to try the old NS4
window.history.go(0)trick as jgraham did. If it doesn’t work, maybe you should implement a rudimendary style switcher to set predefined font sizes upon resize events (?) The style sheets would then be triggered when window inner witdh and height would met a given fence (e.g. 800×600, 1024×768, 1280×1024, 1600×1200, etc.)Eric, I found the code snippet which doesn’t work in IE5/Mac:
var ss = document.styleSheets[1];ss.addRule(...);
in
FontZero()andFontScale()subroutines.If you write something like:
document.createStyleSheet();document.styleSheets[document.styleSheets.length - 1].addRule('body','font-size: ' + newSize + 'px !important;');
… it works back again (?!). This is kind of puzzling. In this particular CSS configuration, it seems IE/Mac fails to add rules to an existing style sheet.
Of course, you wouldn’t want to add styles sheets ad infinitum so we’ll need to figure a way to add and remove rules from the dynamic stylesheet we just created. I’m a little busy right now so I’ll come later on this topic unless someone would write the necessary glue code for IE/Mac.
I implemented Mook’s suggestion of flipping the
body‘sdisplaytononeand back toblock, and that seems to have done the trick. There’s a brief flicker after resizing, but it’s nothing to get upset about for the moment. For now, a fix has been demonstrated, and that’s good enough. Later, I can root around for other style changes that will cause the same effect sans blink. If that hunt fails, I’ll accept the blink.The various suggestions of forcing a reload didn’t work out because the font scaling, which is fired by a
window.onresizeevent, was what had to do ahistory.go(0)call in order to trigger the reflow. But a reload is interpreted as a resize, so an infinite loop of reloading was set up where the reload fired an onresize event, which ran the scaling code, which fired a reload, which…Ben: a big part of this is to make the process transparent, and to work in all supported browsers. IE/Win, for example, doesn’t allow font scaling if the font size is set in pixels, as I expect will happen with many themes. In fact, the only reason the keyboard text-scale function worked is that the intro slide show’s theme sets the body font size in pixels, and everything else in ems or percentages, and you were using a Gecko browser. A theme that did a lot of font setting and element sizing in pixels would scale badly, whether via the keyboard or the scaling routine I’ve created.
Michaël: I’m not so concerned about adding rules ad infinitum; some of the existing code already does that. I also don’t expect users to do a lot of resizing of the window– none at all, actually, in 99% of cases. The major point of this is to allow dynamic rescaling if the target resolution isn’t what the theme author expected, so that if your 1024×768 show ends up in an 800×600 environment, the slides should at least be readable.
By the way, I was taking a look at your slide presentation, and you must have just recently added the outline CSS file to make the outline look pretty also. Unfortunately the h1 border element is transfering to the slide show presentation, therefore placing it a 2 pixels out of the top section. Just FYI
Matt: In what browser? I don’t see the same thing happening in my tests.
I just sent you a screen grab of the browser window. I’m using Firefox 1.0PR
Matt: Found and fixed the problem– my code didn’t cover all cases of toggling between the outline and slide views. Thanks!
Eric, here’s a refactoring of your font scaling code that solves the IE5/Mac problem you spotted and doesn’t add stylesheets ad infinitum:
function fontSize(value)
{
if (!isIE) {
var obj = document.getElementsByTagName('body')[0];
obj.style.fontSize = value;
} else {
if ('undefined' == document['s5ss'] + '') {
document.createStyleSheet();
document.s5ss = document.styleSheets[document.styleSheets.length - 1];
}
document.s5ss.addRule('body','font-size: ' + value + ' !important;');
}
}
function fontZero() {
fontSize('1em');
}
function fontScale() {
...
var newSize = Math.min(Math.round(vSize/vScale),Math.round(hSize/hScale));
fontSize(newSize + 'px');
}
However when resizing the window several times in a short timespan, I noticed it would sometimes miscalculate the font size. Maybe IE5/Mac needs a few microseconds to update the current window dimension properties (?!).
Fonts scale down to small with small viewports. Remember that some projectors are 640×480. On viewports with a height of less than 452 (might be 451px) the ø, < < and >> display improperly.
Tested in FF 1.0 and IE6 on Windows.
Michaël: Thanks. That’s right along the lines I was considering, but hadn’t yet managed to figure out how to make work. I’ll be working on adding your code today, along with some suggested code from the 1.0 days that didn’t make it into the final version.
L: I tried viewing the testbed file in a 640×480 window and the text was still quite readable, so I’m not sure why it turned out too small for you. As for the controls exceeding the footer at smaller font sizes, that would appear to be a fault in the theme’s CSS, one that wasn’t revealed until the scaling routines were added. I’ll worry about that part later.