Posts in the Tech Category

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 S⁵ 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 S⁵ 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 S⁵: 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 S⁵ 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 S⁵ 1.0 and OSF 1.0 are as compatible as possible.  When I start working on S⁵ 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 S⁵ 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 S⁵.  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 S⁵ 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 S⁵ 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 S⁵ 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.

• S⁵ Final Candidate was published on Thursday, October 7th, 2004.
• It was assigned to the S5 and Tools categories.
• There have been sixty-three replies.

You probably know that I’m a long-time Macintosh user, going back to the days of the single-floppy Mac SE.  At one point, I worked in a computer lab that had a “Changing the world, one person at a time” poster on the wall.  Every single one of my books, articles, and other resources has been written or developed on a Mac.  So you can imagine how thrilled I am to be featured in an Apple Pro article.  Not only can you find out a little bit about how I got into this whole CSS thing, but see a picture of me dropping some fat horns on my listeners.

I’ll put this Pro file on the shelf with being made a comic strip character as “ways to know I’ve really made it”.  But you know what really told me I’d arrived?  Discovering that someone had created a Wikipedia entry about me.  It was a pretty stubby page at the time, but its mere existence was enough to drop my jaw into my lap.  Now I find myself wondering if I should edit my own entry to include a full biography and related links, or if that would in some way be incredibly gauche.  (And asking someone else to do it for me would just be gauche by proxy, which is worse.)

It’s an odd thing to be famous, even when the fame is limited to a specific field of activity.  As a matter of fact, I was recently asked to write an article about the “fame game” and I’m still mulling over how to tackle it.  See, when you get right down to it, being well-known is both a reward and a restraint.  When people look to you, there’s a certain set of expectations that gets imposed upon you, whether you want them or not.  You’re supposed to always be right, always be fair, and always be in agreement with whoever’s looking to you.  None of these things are possible.

Nevertheless, I am where I am because I worked to get here (and was lucky), and I’ve no real complaints about the position I occupy.  All told, it’s not a bad thing.  It isn’t even a good thing.  It just kind of is.

So there’s still the question of what I might write about the “fame game”.  As it was posed to me, the editor was interested in my thoughts on “how influential designers and developers must balance ‘responsibility’ to the community with their own need to say what’s on their mind and use their clout to get good things done”.  In many ways, it’s the classic “how do you feel about being a role model?” question.  I’m not entirely sure I’m qualified to answer the question, although I do have some ideas.  I often wonder what the community thinks, though.

So I’ll throw it out to you lot: in your personal opinion, how should influencers balance community responsibility with personal expression—or does there need to be a balance at all?

• Finding Fame and Fortu—Okay, Just Fame was published on Monday, October 4th, 2004.
• It was assigned to the CSS, Interviews, and Personal categories.
• There have been twenty-two replies.

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 S⁵, 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 2 was published on Saturday, October 2nd, 2004.
• It was assigned to the S5 and Tools categories.
• There have been seventy-three replies.

Everyone’s been pointing to the newly restored Mount Saint Helens webcam page, mostly because it’s come back online just as geologic events such as earthquake swarms are occurring in the area.

I’m pointing to it for a different reason.  To see what I mean, view source on the webcam page, or hover your mouse over the webcam image in a modern browser.

Now that’s good alt text.  The title text isn’t bad, either.

• Good Show was published on Tuesday, September 28th, 2004.
• It was assigned to the Standards category.
• There have been three replies.

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.

• Slide Show Beta was published on Friday, September 24th, 2004.
• It was assigned to the S5 and Tools categories.
• There have been fifty-five replies.

Having talked about how to completely rip away all brower default styles in Firefox, let’s consider the bare minimum of styles we’d need to make the Web at least moderately readable.  As it turns out, the primary factor in document mangling caused by taking out the browser’s default styles is the loss of any display information.  In the absence of information regarding what kind of box an element should generate, they’re all made to generate inline boxes.  This is roughly equivalent to saying:

* {display: inline !important;}

Speaking of which, feel free to try that some time on a test document, or as an entry in a browser’s user style sheet.  The result should remind you of the no-defaults trick.

So let’s say we back up the browser’s default style sheets (you don’t want to lose them completely, unless you plan to re-install the browser) and then erase everything in html.css.  Having done that, we can restore a great deal of sanity to the Web by placing the following rules into html.css.

@namespace url(http://www.w3.org/1999/xhtml);
  /* set default namespace to HTML */

html, body, p, div, h1, h2, h3, h4, h5, h6,
ul, ol, dl, dt, dd, blockquote, address, pre,
listing, plaintext, xmp, menu, dir, isindex, hr, map,
multicol, center, frameset, marquee {display: block;}

li {display: list-item;}

area, base, basefont, head, meta, script, style, title,
noembed, noscript, param, noframes {display: none;}

table {display: table;}
caption {display: table-caption;}
tr {display: table-row;}
col {display: table-column;}
colgroup {display: table-column-group;}
tbody {display: table-row-group;}
thead {display: table-header-group;}
tfoot {display: table-footer-group;}
td {display: table-cell;}
th {display: table-cell;}

That rule set will not only cause block-level elements to start generating block boxes again, but it also lets list items be list items, hides the elements we’d like to have vanish, and restores table behavior to table markup.  With those few rules in place, browsing around will be much easier.  It might not be pretty, but it will avoid the extreme wreckage of removing all default styles.

There will still be some notable differences.  For example, paragraphs may now generate a block box, but they aren’t being given margins, so on most sites paragraphs will suddenly not have a “blank line” of separation.  Similarly, heading margins are gone.  Lists don’t have any predefined indentation.  Table cells don’t have default padding, and the “gutter” around page contents has vanished.  Of course, you might see some or all of those things on a site.  If you do, it means that information has been provided by the site’s styles.

In a quick browse of the Web, I found that CNN‘s site was still kind of scrambled by these styles, though certainly not as badly as before.  As an example, a lot of the article sidebars and pictures weren’t floated, which means the float behavior is markup-driven, not CSS-driven.  Why does it matter?  Because in Firefox, align="right" is just a markup hook on which the default style float: right; gets hung.  If that declaration doesn’t appear in the default styles, the markup will have no visible effect.  In other words, no floating.

The home page of The Mozilla Foundation, on the other hand, hung together pretty well, which indicates all of their layout is driven by CSS instead of presentational markup.  This didn’t come as much of a surprise, but it was nice to see.  I was pleased to find that meyerweb’s home page also stayed in decent shape.

So should you add these rules to your style sheets?  Not unless you’re feeling extra-super-mega-paranoid.  The percentage of visitors displaying your site with the default style sheets removed can be safely estimated to very closely approach zero, maybe even touching it.  Besides which, if someone does drop by with all default styles removed, they’ve probably done it on purpose.  If they then send you snarky e-mail about they broke your site that way, feel free to answer them with a polite acknowledgment that they did, indeed, successfully cut their own throat.  It’s not like that’s your problem, any more than you should be bothered that someone “broke” your site with an anarchic user style sheet that suppresses display of lists and paragraphs, or sets all non-replaced elements to use white text on a white background, or whatever.

A more interesting question is whether you should set up a browser to use just those rules as defaults.  I’m giving serious thought to maintaining two copies of Firefox: a normal install, and a development install that’s been hacked to use just the styles I listed before.  It could prove valuable in checking the design assumptions of a work-in-progress, and thus to identify possible weak points in the author styles.  As an example, if I loaded a new design into the development browser and found that lists were completely non-indented, then I’d know I was leaving the list indentation distance up to browser defaults.  At that point, I could decide whether or not that was a good idea.  In some designs, it might be fine, but in others it could be a problem.  Either way, I’d have the chance to consider that question directly, and reach a decision, instead of sailing blindly on, never having thought about it either way.

• Fractionally Restoring html.css was published on Monday, September 20th, 2004.
• It was assigned to the CSS category.
• There have been ten replies.

I was just recently asked if attribute selectors must use quotes around the value.  In other words, are both the following two selectors legal?

a[href="http://www.meyerweb.com"] {font-weight: bold;}
a[href=http://www.complexspiral.com] {font-style: italic;}

“No, they’re optional,” I said with assurance.  And then the doubts started to gnaw at me.  What if they actually weren’t, which might make sense given that you can require the exact match of a space-separated list of attribute values? By this, I mean that if you declare:

div[class="this is a test"] {color: orange;}

…then the selector will match any div element whose class attribute is exactly this is a test, in that order, and with nothing else in the attribute value.  Or so I’ve always been given to understand.  In that case, if you left off the quotes, couldn’t that somehow be confusing to the browser?  Maybe not, but it still bothered me.

So I went digging through CSS2.1, Appendix G and found the grammatical definition of an attribute selector.

attrib
  : '[' S* IDENT S* [ [ '=' | INCLUDES | DASHMATCH ] S*
    [ IDENT | STRING ] S* ]? ']'
  ;

You all understood that, right?  Uh-huh.  Me either.  (This is one of those hostile-to-outsiders posts I mentioned a while back.)

I never liked grammar in school, and I still don’t, but it is sometimes sadly necessary.  So here goes.  When you run down the definitions of the all-caps words (I think those are tokens) you find that IDENT is an identifier, which is sort of a catch-all bin for things like selectors, property names, values, and such.  Fine.  STRING, on the other hand, is a collection of symbols and other fun stuff, again including the non-ASCII range but not the ASCII range.  But then it includes the entirety of Unicode.  I’m not sure how much sense that makes, but whatever.

So the whole point of this is: if quotes around an IDENT are optional, wouldn’t it have made more sense to say this?

attrib
  : '[' S* IDENT S* [ [ '=' | INCLUDES | DASHMATCH ] S*
    [ STRING? IDENT STRING? ] S* ]? ']'
  ;

Or even:

attrib
  : '[' S* IDENT S* [ [ '=' | INCLUDES | DASHMATCH ] S*
    [ '"'? IDENT '"'? ] S* ]? ']'
  ;

It’s the [ IDENT | STRING ] from the original definition that has me befuddled.  It seems like it’s saying you can include an IDENT or a STRING but not both, and since IDENT doesn’t include quotes, that implies that you can either drop in an identifier, or a string with quotes.  Why is this a good idea?  Does it mean that any identifier has to be unquoted?  Does it mean that there’s no practical distinction between a STRING and an IDENT in this situation?  Does it mean that quotes prevent the inclusion of anything useful?  Somebody let me know.

• Grammar Question was published on Saturday, September 18th, 2004.
• It was assigned to the CSS category.
• There have been sixteen replies.

Since a few people asked for it, I’ve created a test file that reproduces the Internet Explorer freeze reported yesterday.  You can find it with the title “Internet Explorer Freezes — BEWARE!“.  If you follow that link with a non-IE browser, you should see a static copy of the “Ten Things To Do…” post, with two differences:

1. I stripped off the theme stylesheet so the masthead graphic isn’t shown.
2. I inserted a warning/explanatory comment near the top of the document.

Under the hood, the main difference is that the style sheets are all embedded in the document, so if you’re so inclined you can download that single page to your hard drive and fiddle with it to your heart’s content.  If anyone can narrow down this problem to a very minimal test case, I’d love to see it.  Refer back to “When Browsers Attack!” for notes on what I discovered.  There may well be more to the story, but if so, I didn’t find it.

I’ll reiterate the warning, in case it somehow wasn’t clear enough: iif you load this document in IE/Win, the odds are very, very, very high that it will freeze Internet Explorer, necessitating a force-quit of the application.  It may also crash Windows.  If you don’t want those sorts of things to happen to you, then don’t load the document.  Clear?  Good.

• Freezer Case was published on Friday, September 17th, 2004.
• It was assigned to the Browsers and CSS categories.
• There have been twenty-three replies.