meyerweb.com

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

S5 1.1a1

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.

16 Responses»

    • #1
    • Comment
    • Mon 8 Nov 2004
    • 0319
    Mook wrote in to say...

    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.

    • #2
    • Comment
    • Mon 8 Nov 2004
    • 0750
    Ken Clarkson wrote in to say...

    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?

    • #3
    • Comment
    • Mon 8 Nov 2004
    • 0832
    Ben Ward wrote in to say...

    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!

    • #4
    • Comment
    • Mon 8 Nov 2004
    • 1038
    jgraham wrote in to say...

    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 an onresize handler the display will be redrawn but otherwise nothing will happen. Of course it’s better to avoid this if possible…

    • #5
    • Comment
    • Mon 8 Nov 2004
    • 1136
    Christoph Wagner wrote in to say...

    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!

    • #6
    • Comment
    • Mon 8 Nov 2004
    • 1138
    Christoph Wagner wrote in to say...

    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 1357

    Warning: 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 89

    I get alot of these on a blank page when posting a comment.

    • #7
    • Comment
    • Tue 9 Nov 2004
    • 0426
    Micha wrote in to say...

    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.)

    • #8
    • Comment
    • Tue 9 Nov 2004
    • 0517
    Michael Guitton wrote in to say...

    Eric, I found the code snippet which doesn’t work in IE5/Mac:

    var ss = document.styleSheets[1];
    ss.addRule(...);

    in FontZero() and FontScale() 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.

    • #9
    • Comment
    • Tue 9 Nov 2004
    • 1149
    Eric wrote in to say...

    I implemented Mook’s suggestion of flipping the body‘s display to none and back to block, 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.onresize event, was what had to do a history.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.

    • #10
    • Comment
    • Tue 9 Nov 2004
    • 1436
    Matt O'Dell wrote in to say...

    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

    • #11
    • Comment
    • Tue 9 Nov 2004
    • 1440
    Eric wrote in to say...

    Matt: In what browser? I don’t see the same thing happening in my tests.

    • #12
    • Comment
    • Tue 9 Nov 2004
    • 1456
    Matt O'Dell wrote in to say...

    I just sent you a screen grab of the browser window. I’m using Firefox 1.0PR

    • #13
    • Comment
    • Tue 9 Nov 2004
    • 2135
    Eric wrote in to say...

    Matt: Found and fixed the problem– my code didn’t cover all cases of toggling between the outline and slide views. Thanks!

    • #14
    • Comment
    • Wed 10 Nov 2004
    • 0809
    Micha wrote in to say...

    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 (?!).

    • #15
    • Comment
    • Wed 10 Nov 2004
    • 1132
    L Rutker wrote in to say...

    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.

    • #16
    • Comment
    • Wed 10 Nov 2004
    • 1150
    Eric wrote in to say...

    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.

Leave a Comment

Line and paragraph breaks automatic, e-mail address required but never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>



Remember to encode character entities if you're posting markup examples! Management reserves the right to edit or remove any comment—especially those that are abusive, irrelevant to the topic at hand, or made by anonymous posters—although honestly, most edits are a matter of fixing mangled markup. Thus the note about encoding your entities. If you're satisfied with what you've written, then go ahead...


November 2004
SMTWTFS
October December
 123456
78910111213
14151617181920
21222324252627
282930  

Sidestep

Feeds

Extras