meyerweb.com

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

Archive: September 2004

Things That Go Beep In The Night

A couple of nights ago, Kat and I watched most of Toy Story 2 before going to bed.  In subsequent nights, we watched the rest of the movie, and also the original Toy Story, but that’s not important right now.  It was interesting to compare the technical differences between the two, from rendering to animation, but that’s also not important right now.

A few minutes before 5:00am on the morning after we’d watched most of TS2, we were awakened by a cry from Carolyn.  She settled back down within a minute, and as we lay there dropping back off to sleep ourselves, we very clearly heard, coming from somewhere in the house, a quick series of three beeps.

My first thought was the carbon monoxide detector, but it wasn’t loud enough or the right tone pattern (the CO detector just wails in one long earsplitting tone).  My second thought was a fire detector running low on batteries, but again, wrong tone pattern.  The interval between these two thoughts was probably a couple of minutes, because it was very early in the morning and I was stumbling around the house trying to figure out what had produced the sound.

After a tour of the first floor and a quick peek into Carolyn’s room, I went back to bed.  It took a while, since I’d shifted into sentry mode, but I eventually fell back asleep.  We haven’t heard any mysterious beeps since then.

It’s hard to shake the suspicion that our electronic gadgets have started talking to each other at night.  I’m not sure what they’d talk about; how much would a VCR really have to say to a cell phone?  Maybe they discuss difficult philosophcal questions and further illuminate the nature of existence.  Maybe our technosphere has gotten sophisticated enough that a collective awareness has emerged.  If that’s true, then it’s little wonder we wouldn’t have heard about it.  What interest would a global intelligence have in talking to any of us?

Then again, maybe a short-circuit or other unexpected condition triggered some beeps, and that was that.

Standards Savings

Yesterday morning, I saw via somebody’s feed (most likely either Matt or Simon) that Rakesh Pai has published a piece called “The Economics of XHTML”, in which he explores and summarizes many points in favor of moving to XHTML.  As he says, XHTML and semantic HTML are basically the same thing, so when you read the article you should prepend the words “old-style” to the term HTML and “semantic HTML or” to the term XHTML.  Thus, the following paragraph from his article:

HTML files are rather complex. They have so much irrelevant information, it becomes difficult to manage them. XHTML on the other hand, if well planned, will be much easier to manage in the long run due to sheer simplicity of the files.

…should be read (emphasis indicates my modifications):

Old-style HTML files are rather complex. They have so much irrelevant information, it becomes difficult to manage them. Semantic HTML or XHTML on the other hand, if well planned, will be much easier to manage in the long run due to sheer simplicity of the files.

I admit I’m reading a bit into the text, but I think my reading is supported by Rakesh’s statement about the basic equivalence of semantic HTML and XHTML.

Overall, it’s a very good summary of the business reasons to shift to standards-oriented design.  It bothers me not at all that he left out a discussion of CSS in the article, since the focus was purely on the benefits to be gained from improving your markup.  It’s often useful to concentrate on small pieces in detail, so that by the time you’ve looked at the various pieces you have a much better understanding of the overall picture.  I would like to talk about an under-recognized aspect of his first point, which was (again, emphasis indicates an insertion on my part):

Semantic HTML or XHTML will give a definite reduction in amount of space used on the server, which translates to money saved. Large sites will also benefit from the bandwidth savings, though this might be insignificant for smaller sites.

It’s true that smaller sites probably won’t save a lot of money on bandwidth.  This is especially true given that many small businesses pay a flat rate each month so long as their bandwidth is below a certain level.  So sites in that range will likely not see significant reductions in expenses.

What they will see, though, is a faster site.  Okay, actually, that’s what their users will see, but that’s the entire point.  Suppose I said I could sell you a product that would make your Web site twice as fast as it is today.  How much would that be worth?  Maybe not much for a fandom site, but even for a small business trying to sell its products online and disitinguish itself from competitors, a 2x speed booster would probably be worth buying.

The thing is that you don’t have to make a purchase to get this boost (unless you decide to hire a consultant like me to help you migrate to standards-oriented design).  There’s no product to buy.  Along with all the other benefits Rakesh describes—accessibility, ease of maintenance, and so on—a faster Web site is part of the standards package.

How so?  Far and away, the #1 factor in request-to-render time is the raw number of bytes you’re shipping to the user.  If you’re sending a dialup user a 60KB page, then even assuming an uninterrupted, uncongested connection it will take about 15 seconds for the page to render, measured from the time the user requests it.  If you send a 30KB page, it will take half that time.

I’m not just saying that because it sounds true: while I was at Netscape, Bob Clary and I did experiments on the effects of standards-oriented design on request-to-render time.  We saw basically no speed improvement from using standards-oriented design beyond the reduction in page weight—but that was a substantial effect.  Thus, the actual markup you use is basically irrelevant in this arena.  The whole page could be one graphic scan of your brochure, or it could be a press release.  Either way, the more bytes you send over the wire, the slower the site will seem.  True, there are other considerations, like server load, network congestion, and so on.  All of those factors will be eased, and speed improved, if there are fewer bytes per page request.  It’s honestly that simple.

As I’ve been telling clients, this is what makes standards a big economic win: standards-oriented designs are nearly always much smaller than old-style designs.  Usually they’re half the size of old-school pages, although that reduction can vary; Microsoft’s home page size dropped by about two-thirds in terms of the markup weight alone.  With Microsoft’s traffic, they stand to save a boatload of money on that reduction.  They also have a site that’s faster, that feels less bloated, that leaves more of a positive impression on the user.  That’s an important consideration for any company, regardless of its size.  It’s a consideration that’s harder to quantify than reduced costs, of course, but not one that can be ignored.  As Richard Rutter shared, when Multimap went to a standards-oriented design, they didn’t see as much of a drop in bandwidth consumption as they’d expected, although there was a reduction.  What they saw was a dramatic upswing in page views, which meant increased revenue for the firm; in other words, they were able to serve more customers and increase revenue while using less bandwidth than before.

That’s what they call increased efficiency, and it’s a competitive advantage in any arena.

Automated Language Setting

Over dinner this evening, I wondered why it is that bank ATMs always have to ask me what language I prefer.  Why not just encode my language preference on the card’s magnetic strip, so that when I insert the card into the machine it immediately knows what language to use?

It was, of course, too obvious an idea for me to have had it first: Why Not? has a post proposing the same idea just over a year ago.  The followup comments pretty much covered all the related ideas that came up as well.

So while it turns out I don’t get points for having the idea first, the question still remains: why don’t ATM cards (and the ATMs themselves) offer this capability?

Update: I forgot to enable comments, so a few people have e-mailed me to say that Bank of America ATMs do in fact let you set your language preferences, along with several other options.  Apparently these settings only carry to other BoA ATMs, so I suspect it’s data being stored in their database instead of being written onto the card itself.  It would be nicer if the card could carry that information and have it recognized by all ATMs, but I suppose we get these things one step at a time.

On The Outside

Every now and again, I stumble across a weblog post that makes me feel the way I expect random visitors feel about my CSS posts.  I hit one recently titled “No Information Lost Here!” which says, in part:

Anyone who hasn’t been asleep for the past 6 years knows that quantum gravity in asymptotically anti-de Sitter space has unitary time evolution. Blackholes may form and evaporate in interior, but the overall evolution is unitary and is holographically dual to the evolution in a gauge theory on the boundary.

Um, yeah.  I mean, who didn’t know that?  Sheesh!

It’s always fun to come across someone who clearly is expert in a field I know nothing about (although, in a parallel universe where I stuck with my original college plans, I’d understand it) and who is clearly writing for other people in the same field.  It reminds me that much of what I write here is effectively gibberish to 99.9995% of the planet, even though that probably isn’t the case for most of my visitors.  It’s good to hit a weblog where I am, for lack of a better term, an outsider.  It helps preserve perspective.

Even more fun in this case, however, was to note the end of the URL for the post titled “No Information Lost Here!”: 000404.html.

A Labor Day Weekend of Love

This past weekend, I was honored to be a groomsman in the wedding of Jim and Genevieve.  I suspect that I was chosen in part because my height came reasonably close to matching that of the bridesmaid with whom I was paired, but I can accept that.  It was, without doubt, one of the most interesting wedding events I’ve ever experienced.

Not because of the actual wedding itself—no, that was a fairly normal affair, complete with a quick relocation indoors due to a thunderstorm that arrived precisely on time.  It was more punctual than some of the guests, actually.  Similarly, there was the expected folderol with the photographer, who was stressed out and stressed out everyone else in her attempts to get The Absolute Best Bridal Party Pictures Ever.  Nothing unusual there.  We even had the requisite confusion about who was escorting whom, and in what order, to their seats at the very beginning of the processional, despite having rehearsed it twice the night before.

Things actually got interesting a few weeks back, when the bachelor party started with an afternoon of paintball.  That was before the more normal dinner and then visits to a series of, er, gentlemen’s clubs.  (Sadly, I missed that last part since we only had a babysitter until eleven, and Kat was at the bachelorette party being held the same night.  We drew straws, and I was the one who got to come back home early.)  But paintball?  Who starts off a bachelor party with a bunch of guys running around shooting paint pellets at each other?  The last of my bruises finally vanished a few days ago, in fact.  I mean, it was fun and all, modulo the stinging impacts and aches of course.  It just seemed very, very odd.  Especially that we didn’t all gang up on the groom and paste him head to toe in paint.  And bruises.

Then, the night before the wedding, things got more interesting.  At the rehearsal dinner, Jim presented us with our groomsman gifts, something he’d been saying for a couple of weeks he was really stoked about, all while rightly refusing to say what he’d gotten.  All of them were obviously the same thing, and felt through the wrapping paper like a set of Craftsman wrenches or something similar.  Turns out he got us all Victor II paintball guns (excuse me, “markers”).  Seriously.

I mean, I’ve heard of shotgun weddings before, but this is something else altogether.

Apparently, there will be more paintball in our futures.  Kat was really excited, announcing in front of everyone that she hoped there’d be monthly paintball, because she wants me out of the house.  Really, that’s how she phrased it.  I felt so very loved.

Then there was the night after the wedding.  After a well-attended and very tasty barbeque on the shore of Lake Erie, a bunch of us deliberately went to play Whirlyball.  “What’s that?” you ask.  It’s sort of like lacrosse, except the competitors drive around the playing arena in bumper cars.  Seriously.  Go check out the site if you don’t believe me.  I can wait.

Now for the part many of you may not believe: Whirlyball is actually a lot of fun.  Besides the sheer joy of driving around bumper cars for fifteen minutes straight, you’re involved in a game that actually lends itself to some sophisticated strategy and tactics, if you pay attention and have teammates who do the same.  There’s just one thing I really want to know.  Why Whirlyball?  There’s really no whirling in the game unless you get confused by the car’s steering mechanism and start driving in a circle… or, as happened to one player, get the steering mechanism slammed into your groin, causing him to slump over and drive in a small circle for a while, feebly waving his scoop in the air whenever the referee asked if he was okay.  I guess that’s why they tell you to buckle the seat belt low and tight across your lap.

Frankly, more weddings should be as fun as theirs.

To Be Tabled

There’s a faint tendency in my work to operate in threes.  I wrote a theory book, a reference book, and a practical book, for example, even referring them to the three legs of a stool.  (Okay, so I’ve written more since then.)  Hopefully, this will serve as the third of three posts on tables and layout, and not the third of more than three.  I have other things I want to write about that have been delayed, and honestly, I grow weary of tromping the same ground again and again.

Brad Bice pointed out that my example markup could be noticeably reduced in size by doing the following:

div#layout {display: table;}
div#layout > div {display: table-row;}
div#layout > div > div {display: table-cell;}

<div id="layout">
 <div>
  <div>...content...</div>
  <div>...content...</div>
  <div>...content...</div>
 </div>
 <div>
  <div>...content...</div>
  <div>...content...</div>
  <div>...content...</div>
 </div>
 <div>
  <div>...content...</div>
  <div>...content...</div>
  <div>...content...</div>
 </div>
</div>

That brings the CSS approach roughly into line with the weight of the table-based approach, which is good.  That still leaves us with the larger problem that Explorer still doesn’t support the application of table-related display values to non-table markup, so the layout will completely fall apart in IE/Win, which is bad.  I suppose you could script your way around the problem, a la IE7.  I wonder how you’d account for the lack of things like rowspan and colspan, though.  CSS doesn’t offer anything comparable.

There were a few responses to the effect of “what Eric fails to say is that table elements already have a predefined meaning”.  True, I failed to say that, mostly because I didn’t think it was important to bring up.  I think it’s fairly safe to assume that if you’re worrying about any of this stuff, then you’re going to try to use semantically appropriate elements when you can.  However, if you accept that there are times when a grid layout system is needed, then you have to accept that need will override any concerns about defined element meanings.  In other words, the defined semantics of table markup are important, but they aren’t important enough to block the use of table markup when it’s needed for layout purposes.

Some would say that if you can’t accomplish your design without violating markup semantics, then you should create a different design, one that doesn’t require the use of table markup.  That’s one of those “you can choose any color you want as long as it’s black” arguments that just make me sadly shake my head.  There’s no argument that will change that kind of thinking: it rejects reality in favor of internal consistency.  If that works for you, great, but I can’t operate that way.  We’ll just have to agree to disagree.

Then there were the responses that ran something like “okay, so tables are necessary for a few things, but for almost every type of Web design you don’t need to use tables”.  Yes.  I said that.  I said it several times, in fact, in different ways.  Maybe that was a mistake.  So, if I may, allow me to summarize the points I’ve apparently been obscuring over the past few days.

  • In the vast majority of Web design cases, you can accomplish your layout without the use of table markup, and you can do so in today’s browsers.  This applies even to most layouts that appear to be grid-based at first glance.
  • There are a few cases, very rare ones, that require grid-driven layout where all the grid pieces line up both horizontally and vertically, both side to side and top and bottom, and the contents of the pieces have dimensions that cannot be predicted in advance.
  • At the current stage of the Web’s evolution, such layouts require table markup if you want the design to work as intended in Explorer as well as more recent browsers.
  • The table markup used in such designs can and should be very light-weight, and use CSS for presenting all of the visible content within the table.  The table itself can also be styled using CSS for the most part, although row- and column-spanning still has to be done at the markup level.
  • From this point on, anyone who uses these posts to claim that I’m saying tables should always be used for layout is either not paying any attention, has an agenda to promote, or both.  Probably both.

Fin.  I hope.

CSS Gridlock

I mentioned in my post that the only CSS grid layout capability is styled tables.  Then I said that the only “pure CSS” grid layout approach being to apply table-related display values to non-table elements.  In one sense, I said the same thing twice, but in another sense, I contradicted myself.  When I read the post again, I decided that a little clarification was in order.

So let’s say that you have a deep burning desire to create a grid-based layout without using any table markup.  Suppose this layout is based on a 3×3 concept, where the pieces all need to have their horizontal and vertical edge line up with each other.  To do that, you’d need styles and markup like the following:

<div id="layout">
 <div class="hgroup">
  <div class="cell">...content...</div>
  <div class="cell">...content...</div>
  <div class="cell">...content...</div>
 </div>
 <div class="hgroup">
  <div class="cell">...content...</div>
  <div class="cell">...content...</div>
  <div class="cell">...content...</div>
 </div>
 <div class="hgroup">
  <div class="cell">...content...</div>
  <div class="cell">...content...</div>
  <div class="cell">...content...</div>
 </div>
</div>

Then, to that markup, you’d apply the following styles:

div#layout {display: table;}
div.hgroup {display: table-row;}
div.cell {display: table-cell;}

So there you go: a grid layout that uses absolutely no table markup by applying table display roles to other elements.  And the point is…?

Frankly, I don’t think there is one.  Because let’s be honest, given a choice between the markup in that previous example and this next one, I think the next one is not only easier to read, but it’s lighter in markup weight.

<table id="layout">
 <tr>
  <td>...content...</td>
  <td>...content...</td>
  <td>...content...</td>
 </tr>
 <tr>
  <td>...content...</td>
  <td>...content...</td>
  <td>...content...</td>
 </tr>
 <tr>
  <td>...content...</td>
  <td>...content...</td>
  <td>...content...</td>
 </tr>
</table>

Not to mention the table will work in IE/Win, whereas the “pure CSS” version I detailed won’t.  That kind of puts a damper on any enthusiasm I might have summoned for it.

In CSS terms, the reason a table works the way it does is that the browser itself applies the following rules from somewhere deep within its codebase:

table {display: table;}
tr {display: table-row;}
td {display: table-cell;}

I know, tables have existed for longer than CSS, but my point isn’t that CSS makes tables possible.  What I’m saying is that that’s the CSS way of describing a table and how it functions.  If you want elements that effectively bind together and affect each other’s height and width, then table-related display values are the only game in CSS Town.

Is that enough?  It doesn’t feel like it to me, but on the other hand, any grid-layout system would have to do basically the same things.  For example, suppose we invented a set of properties and values to describe a grid layout.  They might look something like this:

div#layout {display: grid-layout;}
div.hgroup {display: grid-layout-group;}
div.cell {display: grid-layout-box;}

…for which we could simply substitute the table values mentioned earlier, and get the same result.  Why reinvent that particular wheel, especially when the new wheel would take even more years to be adopted?

There are only bigger problems lurking in related proposals.  A common request is a way to set the height of one element to equal another element.  Here’s the problem:

div#one {height: element(div[id="two"]);} /* totally bogus CSS-like example */
div#two {height: element(div[id="one"]);} /* DO NOT TRY THIS; IT WON'T WORK */

An infinite loop!  Yay!  Now what?  Furthermore, assuming you have a way to break the loop, which of the two elements in question will be the one that’s actually used to set the height for both?  There’s nothing in that set of rules that says that the taller of the two should win out, so you might end up with the two element set to the height of the shorter of the two.  What are the odds that’s what was desired?  (Non-zero, but pretty darned small.)  Then again, it might be the taller of the two.  Or maybe they’ll set to the average of the two elements’ content heights, so you get one too tall for its content and one that’s too short.

And this is a simple case, one that could probably be fairly easily resolved.  The complicated cases are where real trouble sets in, because you can get runaway situations where two (or three or more) elements keep triggering growth in each other, heading for infinity as fast as your rendering engine can calculate it.  If you allow value expressions—another common request—then it gets even worse.  For example:

div#one {height: element(div[id="two"]);}    /* see previous warning */
div#two {height: expression(element(div[id="one"])+25px);}

Ruh-roh, Raggy.

You might say, “Well, if any author is dumb enough to do that, then they get what they deserve.”  Only the author doesn’t get it, the reader does.  If you come across such a page, your (height-linking and expression capable) browser will freak out, maybe even crash.  Hopefully the developers made sure to add infinite-loop checks to prevent such nastiness, but are you sure they’ll manage to catch every possible case?  Without standing in the way of legitimate iterative processes?

And so we come back full circle to the present, where the only real choice for grid-dependent layouts are tables.  They should always be simple tables, employing a bare minimum of markup and styling the cell contents with CSS.  You can do that easily enough by ID’ing the cells, and writing your CSS accordingly.

And remember: this is only necessary for grid-dependent layouts.  Most layouts don’t fit that description, as I said in the previous post.  The only one that comes to mind at this moment is CNN.com, which has all those various boxes that need to line up just so (in the current design, anyway) even though there’s no guarantee of how tall or short they’ll be from one hour to the next.  They use tables to get those boxes to line up, as well they should—really, as well they have to, because there’s nothing else they could do outside of creating an all-Flash site.  But for the vast majority of sites, as Doug said, there’s no reason to use tables for layout.

Sliding Faux Columns

A while back, in the summary to his article “Throwing Tables Out The Window“, Doug asserted:

There’s no longer any reason to use tables for layout, nor is there reason to maintain multiple versions of a site solely for different desktop browsers. Throw the tables out first. Trust us, they’re not needed anymore.

At the time, I remember thinking that I agreed with him for about 90% of design cases, but that there was that nagging 10% that still seemed to require tables.  That would be the cases where elements have to have the same visual height, regardless of their content height, and the layout is not fixed-width.  (Fixed-width cases can be easily handled using Dan Cederholm‘s Faux Columns.)  The classic example is a liquid two-column layout containing a sidebar and main-content column, where the sidebar has a different background than the main content, and that background has to be as tall as the main content—and, conversely, the main content’s background has to be as tall as the sidebar’s if the sidebar is taller.  There are ways to get this to happen using non-table markup, but it usually involves at least as much markup as using a simple table, and is less stable in older (NN4-era) browsers.  If  you go to three columns, all of which must match each other’s heights, then things get really wacky.

So I eventually got around to asking Doug about those cases, and it turned out he’d been mulling an idea similar to one I’d had but never pursued.  We tossed messages back and forth, hammering away at his idea, and eventually christened it ‘Sliding Faux Columns’.  Doug writes about this technique his recent post, Liquid Bleach.  Here’s the basic idea in a nutshell, quoted from Doug’s post:

The trick is to create an ultra-wide background image (or two images for 3-column layouts, thus the Sliding-Doors-nature of the technique). The image is partially opaque, and partially transparent. It gets tiled vertically inside the parent container, just like Dan’s Faux Columns technique. The opaque portion of the image should match percentages of the column it helps create, so that it can be positioned with an identical background-position value. This allows the transition from opaque to transparent to become the axis point for the background’s position.

Amazingly, the technique appears to work in IE5/Win and later.  IE5/Mac has some problems, and while the problems were vaguely familiar ones we never did manage to figure out how to work around them.  More recent browsers, like Safari and the Gecko family, seem to handle the technique just fine.

While we were working on the concept, I threw together some test cases.  They aren’t up to the usual css/edge standards, which is why you won’t find a link on the main css/edge page.  I’m putting them out in public because they might be interesting to anyone who wants to play with a boiled-down version of the technique.  Note that the super-wide images are only needed if you’re trying to fill a color or pattern into the background of the column(s).  If you just need a vertical separator, then an image as wide as the separator (say, one pixel) is all you need.  The CSS works out to be exactly the same in either case.  It’s just a difference of a 3000-pixel-wide background image versus a one- or two-pixel-wide image.

The markup isn’t exactly pretty: it requires a couple of wrapper divs just to set up the column backgrounds/separators.  This isn’t more markup-heavy than a table constructed to serve the same layout goals, but then it isn’t a whole lot less heavy either.  Personally, I remain agnostic on which is a better approach.  Bending a table to layout purposes isn’t clean, but to my eye, neither is constructing a couple of 3000-pixel background images just to get the effect a simple three-cell table can allow.  You’re hacking your way around limitations in CSS either way you go.

This brings me to a question I often encounter: “Why doesn’t CSS have a grid layout capability?”  It does: styled tables.  That’s pretty much it, but it’s there.  Until CSS gets grid-layout functionality that isn’t table-centric—the only “pure CSS” grid layout approach being to apply table-related display values to non-table elements, and boy, does that ever make a lot of sense—and that functionality is widely supported, then tables are the best grid-based layout system available in the (X)HTML+CSS space.

Before the purists warm up their flamethrowers and the CSS haters start to crow that I’ve done a Bush-style flip-flop, note that I said it’s the only grid layout system available.  The designs that absolutely require such a system are that 10% I was talking about earlier.  Most other designs don’t need a grid system, and so don’t need tables for layout.  The current Wired News design is one, the new Chevrolet site is another, and meyerweb is still a third.

As Doug has proven with Sliding Faux Columns, it’s possible to cover a good portion of those sites that would normally need a grid system without table markup.  That’s certainly interesting, and in one sense it’s quite useful in that it details the hoops through which one has to jump to make this sort of thing happen with CSS.  When you get right down to it, though, I’m feeling very ambivalent about which I’d prefer to use: Sliding Faux Columns or a simple table to set up the columns.  I suspect probably the latter, in my personal case.  The great thing is that now we have a choice for those kinds of designs.

For the small percentage of designs that really do require a full grid system, though—and I really have seen only a few in all my years of surfing the Web—tables are your only realistic choice.  I wish CSS had addressed that point in years past, so that we’d have some hope of support at present.  It’s always struck me as one of the biggest missed opportunities of CSS.

September 2004
SMTWTFS
August October
 1234
567891011
12131415161718
19202122232425
2627282930  

Archives

Feeds

Extras