meyerweb.com

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

Archive: August 2004

Road Chuckles

Over the last couple of months, I’ve spotted and captured a few bits of amusement that I thought I’d share.  Two are truck-based, and the other was found by the side of the road.  Enjoy.

I found this a very creative way to advise motorists on proper driving. This was taken on Interstate 71 just south of exit 151, and not in the Southwest like you might have expected.  (Note to non-Americans: in the U.S., we drive on the right side of the road; thus, slower traffic goes to the right and faster to the left.)

I always figured that when they got here, their transports would be a little more advanced.  Unfortunately, I was without my SPNKR so all I can do is report the sighting.  (This one is more of an in-joke, albeit an in-joke shared with the several zillion people who’ve played Halo.)

Somebody obviously heard about how I drive.  The original picture is going to be Photoshopped to complete the naming just as soon as I can find the time.

Bingo

Standards don’t matter because it’s the applications that matter. (To the legions of people who lay this platitude on me, pretty much on a daily basis, thank you. I wouldn’t have been able to figure it out without you. I would just sit around working on a 500 page spec for its own sake, because that’s so much fun.) But try to scale these applications up, and try to reuse your content, across an enterprise or over the Internet, without standards. Just try. And even if you don’t want to use standards, your customers will eventually make you, because by now they have gotten tired of paying you too much money to rewrite the same content over and over and over again for each new application use, each new platform.

From “Like a Phoenix From the Ashes: X3D and the Rebirth of Reason” by Tony Parisi.  He says it better than I ever could, and what he says is just as relevant to our corner of the Web as it is to his.

A tip o’ the hat to the WaSP (who also recently talked about the Microsoft redesign) for pointing it out.

Antispinward

I’m just throwing this out as a general advisory: if you have any interest in the American Presidential campaign, or in analyses of spin and distortion in general, make it a habit of stopping by Spinsanity.  Or you could subscribe to their RSS feed.  I’ve had to fight the urge to just repost links to everything they write, so consider this a recommendation.  They do a great job of analyzing rhetoric from both campaigns, pointing out inaccuracies in media reporting on politics, taking on books and documentaries, and more.  The non-partisan stance and rigorous insistence on getting to the truth come as a welcome antidote to, well, just about everything else about the campaign.

Recent favorites:

Heck, they’re all good.  Right now, the site’s authors are pushing their new book “All The President’s Spin” pretty hard, which probably lends to the perception that they’re a left-wing group.  I haven’t seen any leftward shift in their posts, though; they’re still taking on both sides and the media itself.

So like I say, if you’ve any interest in these sorts of things, go sign up for the feed or add them to your bookmarks.  The lessons in spin, deception, and media distortion you’ll receive are well worth the investment of your time.

Microsoft Migration

As has been reported in a bunch of places, Microsoft’s home page has been redesigned and uses standards-oriented design principles, eschewing tables and spacer GIFs for CSS-driven layout.  The weight of their home page’s HTML document dropped by almost three-quarters—it’s 27.5% the size of the IE-specific version of the previous design, and 30.5% the size of the non-IE version.  It still uses a few tables for layout (about one-sixth what it did before) and throws some validation errors, but not in overwhelming numbers.  It seems that they’ve even dropped browser sniffing, and are serving the same document to everyone.  Doug has more details, for those who are curious.

I think this is absolutely incredible, and to be applauded.  The Web Standards Project should already have given them a round of applause, in my opinion, and hopefully will do so very soon.  It may seem like odd timing given the recent launch of the WaSP’s Browse Happy campaign, but the Web site and the browser are two very different things.  There’s no contradiction in discouraging use of the latter while applauding the improvements of the former.

In my rounds of the posts and comments about this redesign, I saw a couple of people say things to the effect of “this is nothing important, the markup is still crap, and MS shouldn’t be praised simply for producing less crap than before”.  Um… yes they should.  As far as I’m concerned, any company or other organization that makes a standards-oriented move deserves praise for their efforts.  We might discuss what else they can do to improve further, but to slam someone who’s doing the right thing for not immediately achieving utter perfection (for whatever value of perfection happens to be in vogue at the time) seems like the most counterproductive act I can envision.  Well, besides launching DDoS attacks.  This is a time to encourage them to continue, not give them ample reason to reverse course.

Analogy: if your significant other voluntarily cleans up after dinner, but misses a couple of the dirty dishes, which is more likely to get the job done?

  1. Yell at them for not doing a complete job and storm off.
  2. Thank them for doing the dishes, and gently point out that they missed a couple.  Offer to do them yourself.

I bet the second one works in most cases.  In fact, we could offer to do the “missed dishes” by figuring out fixes for the remaining errors, and offering them for use.

I wish I could say I’d had something to do with their redesign through Complex Spiral Consulting, but I didn’t.  Doug probably wishes he could say something similar with regards to Stopdesign, but from what I can tell he wasn’t involved either.  Mike Davidson is in their area, but since he hasn’t said anything yet I’m guessing that he’s also an observer.  The initial impression is that this was an internally-driven effort, one that has paid off in bandwidth savings, efficient coding, and more.

So I’m taking this opportunity to salute the efforts of the microsoft.com team.  Well done!

Up, Up and Away

I bet you didn’t know that Molly and I have super-powers, did you?

The benefits of using CSS on a regular basis are amazing, really.  I’m hoping to develop telekinesis next.

More Markup

Okay, apparently that wasn’t the rest of the story.  In part, that seems to be because I didn’t express what I was trying to say very clearly.  In others, it’s because people reminded me of points I should have made, or else brought up good points I didn’t address (or consider).  Time for some follow-up.

A few people said “who cares about three/six bytes?”  Me, obviously.  On many pages, such as the archived entry, it’s not going to be a big deal.  On the home page, it will be a slightly bigger deal.  On a monthly archive page, it’s common to see twenty or more dates on a single page.  There we start to measure weight reductions in tenths of a kilobyte.  If I take a similar approach in five other cases, that’s half a kilobyte.  It adds up over time, especially when you get several hundred thousand page views a month.  The difference is even more fractional when using gzip encoding, as I am.  But a gzipped 10.4KB page is still smaller than a gzipped 10.5KB page.  It will always be smaller.  Why not take the improvement, if nothing else is harmed?  (As I believe to be the case here, although obviously not everyone agrees.)

The most common objection to what I wrote is that using b violates “semantic purity”.  I disagree entirely.  span has no more semantic purity than b, in my view.  Both are intended for purely presentational effects.  Neither adds anything to the document’s semantics in a fashion that, for example, strong does.  So on those grounds, the choice is a wash; neither is any better than the other.  The only real difference between the two elements (besides their names) is that b has, mostly by tradition but also by way of description, a default presentational rendering—the text uses a bold font face.

Which leads to the next point, one I forgot to make in the previous post (that’s what I get for writing entries late at night).  As I just said, if you use b, then in a view of the document free of author CSS, the text will be boldfaced.  That’s exactly what I want in this case; in a browser where an h5 isn’t boldfaced by default, and there is no CSS being applied at all, I’d like the date to be boldfaced.  Why?  I just do.  Oh, sure, I could come up with a rationale like it being important to highlight the entry date in a weblog, but the reasons aren’t really relevant.  As the page author, those are the kinds of decisions I get to make.  So given that desire, b has another advantage over span for the case I’m describing.  In cases where you don’t want the text to be boldfaced in a rendering free of author CSS, then b is actually disadvantageous.  There will be inevitable complaints about presentational markup, but in a non-CSS environment, what other presentational influence can I have?  None.

It was also pointed out by a few people that I’m over-classing my markup, since I could easily use descendant selectors to get the same results.  That’s absolutely true.  The classes (title and meta) are more remnants of earlier designs, and have outlived their usefulness.  In the beginning, I used the classes because I thought I’d want to use sub-headings in journal entries, in order to break up long posts.  (Andrei does this quite a bit, as do some others.)  I wanted to be sure that the title and date styles applied only to those particular headings in an entry, and no others.  Since then, practice has shown that I never write entries with sub-headings, so the classes aren’t necessary, and in fact my CSS didn’t even need the classes to be there.  Thus, I’ve taken out the classes.  If I ever find myself wanting to break up an entry into headed sections, I’ll use h6 to do it.  So thanks to those who held my feet to the fire on that point.

Lachlan Hunt pointed out that I could save a lot more weight by using UTF-8 characters instead of encoded character entities.  True.  And if I could get UTF-8 to work, I’d probably try do that, assuming I could be sure the content wouldn’t be mangled in current browsers, a worry I definitely don’t have when it comes to element handling.  Lachlan also mentioned that in a CSS3 world, I could use the ::outside pseudo-element to generate another box for styling, instead of nesting one element inside another.  Yes, and in an XBL world I could just generate the extra box(es).  Until either one or both of those worlds comes to pass, markup is the answer.  In this case, I prefer b to span for all the reasons mentioned earlier.

As you might suspect, anyone who doesn’t accept my earlier assertions about markup semantics isn’t going to agree with my markup choices.  I’ve no problem with that; note that I never said anything even remotely resembling “b is always better than span“.  It isn’t.  Neither is span always better than b, as I’ve discussed here and in the previous post.  By all means, if you have a deep-seated aversion to presentational elements, then don’t use them.  In my world, one avoids using them when a semantic element would better serve the intent.  When there is no semantic need, then I figure you should use whatever works best for you.  Knowing how to tell the difference between these cases is a big step toward really understanding how to use markup efficiently and well.

Markup Missive

In a previous post on heading levels, I used some of meyerweb’s markup as an example.  In that markup, an apparently useless <b> element appeared.  Here’s the markup:

<h4 class="title"><a href="…” title="…">entry title</a></h4>
<h5 class="meta"><b>entry date</b></h5>

In that post, I also said:

And yes, there are b elements in my markup, and I’m doing that on purpose.  I’ll talk about it some other time.

So now it’s time.

The boldface element is actually a holdover from the previous designs of meyerweb.  You can still mess with them on the theme example page, if you like.  The original idea was to provide an inline element as a hook on which I could hang some styles.  For example, if I wanted to put the date in a box that exactly surrounded the date’s text, but no more than that, I’d need an inline box.  Therefore, I could either style the <h5> element to generate an inline box, or I could have an inline element there for styling purposes.

In the first case (inlining the h5), I’d lose the block box that the element generates by default, thanks to the browser’s built-in HTML styling.  That might be okay in some cases, but more often than not it would be a problem.  Inline boxes accept a limited set of properties, and putting an inline box between two block boxes is generally a recipe for funkiness.  So that left me with the second case, that of adding an inline element.  As an added bonus, doing so gave me two elements (h5 and b) to style, if I wanted them both.

Here’s the CSS that applies to the date headings and their boldface elements:

#thoughts h5 {font-size: 1em; line-height: 1em;
  margin: 0 0 0.5em; padding: 0; color: #CCC;}
#thoughts h5 b {font-weight: normal; font-size: 0.9em;}

Although I’m not doing much with the b element, style-wise, what I’m doing is useful.  First, there’s making sure the font weight is normal, and not bold.  All right, that’s not really useful.  Second, the boldface element is used to reduce the size of the date’s font by a small amount.  I use the b element to reduce the size of the font because that leaves the element box of the h5 alone.  In other words, its text box is not reduced, which means it’s consistent with the text around it.  If I ever go back to a design where the date and title are “on the same line” and lined up with each other, as was the case in many of the old designs, I won’t have to do weird fractional math just to make it happen.

Of course, in the current design, that isn’t an issue.  So in a sense, the b element is sort of a vestige from an earlier stage in the site’s evolution, like a markup appendix.  The only difference here is that the b element might become useful again, whereas I don’t think the appendix has much chance of a comeback.

The other expected question is why, if all I wanted was an inline element as a styling hook, I used a b instead of a span.  Simple: the element name is three letters shorter, so for every hook, I’m saving six characters.  If there are, say, twenty such hooks on a page, that saves me 120 characters.  It’s a small consideration, but by such incremental savings are document weights reduced.  “What about semantic purity?” you may ask.  In my view, b and span have the same semantic value, which is to say basically none.  They’re both purely presentational elements, with the difference that span doesn’t have any expected presentational effects in HTML.  So I used the presentational hook that made the most sense to me: b.

If my goal was to emphasize the date, then I’d have used em or strong, but it wasn’t.  I just needed a hook, at least once upon a time, and that was the element I chose as my hook.

And now you have the rest of the story.

A Classic Moment

Last night, Kat and I celebrated our wedding anniversary—a month late, true, but that was the soonest we had enough free time—with a romantic evening and dinner at Classics.  If you visit the restaurant’s Web site, you’ll discover that it plays some loud background music.  It’s relatively tasteful piano music, but still there.  The same is true of the restaurant itself, as it happens.  It wasn’t quite as loud, though, and was performed by a live pianist.  He was pretty good.

Of course, he played all the usual suspects.  About five minutes after we were seated, he started in on a rendition of “Send In The Clowns”.  Kat looked at me and said, “What, do all these guys get the same songbook?”  I tend to think so, although to his credit he managed not to play “Memories”.

Partway through the meal, we asked the server if the pianist took requests.  We were assured that he did, so we requested our wedding song: “The Christmas Song”.  She left to pass on the request and we got back to our food, one of the middle courses in the chef’s tasting menu.  As the next song emerged from the piano, I said to Kat, “Great, he’s still working that songbook.  Now it’s ‘Don’t Cry For Me, Argentina’.”

But as the chorus came around a second time, I suddenly realized something was amiss.  Cocking my head to one side, I re-focused on the music.  There was definitely something off-kilter.  “I don’t think that’s ‘Argentina’ after all,” I said.  Kat, looking puzzled herself, agreed.  It was definitely a song I’d heard before, but I was having trouble placing it.  Then, on the third round of the chorus, my eyes widened.  I looked at Kat; from her expression, I could tell she’d gotten it too.

“I think it’s—” she started to say in an incredulous tone.

“I’m pretty sure you’re right,” I said.  “We have to ask him.”

A few minutes later, we had our chance.  The pianist came over to our table and said he wanted to ask about our request, since apparently he was concerned about the other patrons’ reaction to hearing “The Christmas Song” in August.  He was curious to hear how that got to be our song for a summer wedding.

“I’ll tell you,” I said, “but first I have to ask a question.  What was the song you played just now?”

He was immediately embarrassed, and fluttered his hands as he responded.  “Oh, well, my memory isn’t, I mean one of the servers… it was just a little bit from Star Trek II: The Wrath of Khan.”

Kat and I burst into laughter and shared a high-five.

August 2004
SMTWTFS
July September
1234567
891011121314
15161718192021
22232425262728
293031  

Archives

Feeds

Extras