Posts from 2008

You probably don’t need me to tell you about today’s issue of A List Apart, but just in case you hit this entry in your feed reader before reaching the ALA feed, head on over.  If you have anything to do with web development, there’s news of a coming change that you absolutely need to read.

I know there will be many people who disagree with my take on version targeting.  As did I, at first.  Originally I wasn’t even going to be part of this ALA issue but as I argued with Aaron about it on the ALA editorial board and started to shift my perspective, we realized that having someone document that thinking process would be valuable.  So I did.

Already I’ve seen a lot of negative reactions to the idea, and they remind me of my initial reactions.  That’s not to say that my views are more advanced, nor that everyone will eventually come to the same way of thinking.  It’s entirely possible that after due rational consideration, many people will come to the conclusion exactly opposite my own.  I still thought it might be useful to share my thoughts on the matter as someone who has been concerned about browser compatibility and standards advancement for a very long time now.

Comments are closed here, but discussion is open at ALA.

Update: I wanted to point to some other material about this topic.  I’ll probably keep updating this as time goes on.

• Compatibility and IE8 — a post by Chris Wilson about the challenges faced by browsers when advancing standards, and the particular situation experienced in the IE7 deployment.  You don’t have to agree with the conclusions, but understanding the problem is important.

• The versioning switch is not a browser detect — this is vitally important to any hope of useful debate on this topic.  I tried to clearly make the same point in my ALA article, but reiteration doesn’t hurt.

• Broken — Jeremy objects to the default behavior.  I actually agree with him, and made that case at length with a member of the IE team.  I couldn’t make what I wanted square with their requirements, and came to see that I couldn’t, and was deeply saddened by it.  I sincerely hope that Jeremy, or indeed anyone, can succeed where I failed.

• That Red-headed Monster Next to You? Yeah, that’s Anger — no, I didn’t link this because of the hair-color reference.  I’ve been deeply disheartened by the overall tenor of the reaction.  Disagreement is fine, in fact welcomed; but the level of vitriol, name-calling, and outright personal attacks came as a rude and unwelcome surprise.

• Targeted was published on Tuesday, January 22nd, 2008.
• It was assigned to the Browsers, Standards, and Writing categories.
• There have been nine replies.

I wasn’t going to do it.  It would take too long, draw too much energy and attention.  Too many other things needed to be done first.  But it tasked me.  It tasked me!

So: here’s a browser timeline built out of a table.  I’ll say it now: this does not work in IE6 and IE7.  I’m not sure it’s possible to do, at least not cleanly, given the markup I used.  I’ll explain what I mean in a bit.

In order to structure this data, a table seemed to make the most sense, although even it wasn’t perfect.  There really wasn’t anything that seemed an exact fit, to be honest.  Definition lists didn’t really fit the bill (is a browser defined by its release dates?).  Plain old (un)ordered lists were a little better, but not enough.  In the end I just kind of ran with the idea that time sat on one axis and browsers sat on the other axis—like a table.

Given that decision, I needed to decide exactly how to group the data.  After a moments’ thought, I decided that I wanted to group the release dates by browser instead of by year.  Given the way tables are structured, that means every row corresponds to a browser, each data cell in the row represents a year, and the contents of each cell are the versions released in that year.

So here’s an example of a table row:

<tr title="Internet Explorer for Windows">
<th scope="row">
   <img src="icons/msie.png" alt="Internet Explorer for Windows" />
</th>
<td class="y1996"><p title="August 1996">3.0</p></td>
<td class="y1997"><p title="October 1997">4.0</p></td>
<td class="y1998"></td>
<td class="y1999"><p title="March 1999">5.0</p></td>
<td class="y2000"><p title="July 2000">5.5</p></td>
<td class="y2001"><p title="August 2001">6.0</p></td>
<td class="y2002"></td>
<td class="y2003"></td>
<td class="y2004"></td>
<td class="y2005"></td>
<td class="y2006"><p title="October 2007">7.0</p></td>
<td class="y2007"></td>
<td class="y2008"></td>
<th class="end"></th>
</tr>

(And yes, that’s drawn straight from the example, with no simplification and very minimal formatting.  I really wanted to pare the markup down as far as I could.)

The other choice was to have each row represent a year, and each cell represent a browser.  The non-graphical Wikipedia timeline has each row represent a month, not a year, but same general idea.  I totally understand why the Wikipedia timeline is top-to-bottom: it’s much, much easier to update and have render within the Wikipedia layout.  A new month is a new row in the table.  Easy peasy.  Fair enough, but I’m not here to do what’s easy.

Then there was the question of how to structure the version numbers within each year.  I resisted using ordered lists because in most cells there would be only one version number, and there’s nothing in the world of semantic markup that rubs me the wrong way more than a one-item list.  So I went with paragraphs.  I don’t particularly like that either, but short of inventing my own elements and writing a new DTD to support them, I couldn’t come up with much better.

One thing I’m still uncertain about is my decision to title the dates while having the actual content be only the version numbers.  Would it be better to put the dates into content and wrap distinct elements around the date and version numbers?  I’m honestly not sure.

Anyway, having settled on that structure, I had to answer the question of what to put on which axis in the layout.  Should I put the axis of time across the top, as I did originally; or down the side, as in the non-graphical Wikipedia timeline?  Put another way, should the timeline layout be horizontal or vertical?

I went with horizontal.  For whatever reason, I have a strong preference toward timelines scrolling left-to-right, not top-to-bottom.  Yes, even though it invokes that dread abomination, the horizontal scrollbar.  As it happened, given my structural decision, the same effect occurs even in an “unstyled” state.  If I’m just looking at the table with no author styles applied, I see the browsers down the left and the time across the top, proceeding from past to future from left to right.  That might seem convenient from a final layout point of view, except for the fact that I ended up completely ripping the table apart and, in effect, reassembling it with positioning.  This wouldn’t have been necessary had browsers allowed table cells to become containing blocks when they’re set to position: relative.  But they didn’t.

Frankly, I don’t have room here to go through all of the techniques I used and decisions I made.  Doing so would probably require a very long article, or else a very small book.  I did want to spotlight a few things:

• In keeping with my desire to minimize the markup, I cut way back on classes.  In fact, the only classes I use indicate which year a cell represents, such as y1999, and end to indicate that a cell is at the end of a row.  (I could have dropped all those classes as well, but chose to keep them for reasons too varied to explain here.)  The paragraphs containing the version numbers, as an example, are completely unclassed, nor do they have IDs.  And yet I was still able to position them appropriately within each year.  How?  Check the markup sample to see if you can figure it out; I’ll give the answer later on.

• I used ems for the sizing of just about everything, so this should be extremely tolerant of changes in text size.  The icons get a bit weird at extreme deltas, but I’m willing to accept that.  Anyway, we all may have full-zooming browsers within a year or three and will leave text-zooming to history.  The nice thing about using ems here, though, is that no matter which flavor of zooming you have to hand, the timeline will accommodate you.

• I came across at least two things that were of “is this a bug?” interest.

  1. Assigning position: relative to table cells failed to make them containing blocks for absolutely-positioned descendant elements, as I mentioned before.  Changing their display to block allowed them to be containing blocks, but completely shattered the table layout—elements have to have a display of table-cell to act like table cells.  That makes sense, but the lack of containment when relatively positioning the table cells did not.  Turns out that’s permissible as per CSS2.1: 9.3.1: “The effect of ‘position:relative’ on table-row-group, table-header-group, table-footer-group, table-row, table-column-group, table-column, table-cell, and table-caption elements is undefined.”  Oh well.

  2. Where two elements overlap and both have :hover styles, only the “topmost” (the element higher up on the Z index) of the two gets its hover styles, at least in the browsers I tested.  The handling of hover styles has been an area of debate in the CSS community for quite a while—the CSS2.1 specification does a remarkable job of defining hovering without ever explaining how it should or shouldn’t work—but this single-event model seems unnecessarily restrictive after all these years.

• Speaking of bugs, I ran into an apparently insoluble problem with Explorer: its allergies over the combination of display and table markup.  Yes, I know, I built bar graphs out of table markup, and that worked fine (even in IE6).  Not so here.  In fact, I couldn’t even get the table element to generate an element box once I’d positioned most of its descendants and converted them all to display: block.  I mean, no matter what I did, it would not show anything.  No height, no width, no borders, no nothing.  I can’t even figure out what’s happening to the display role of the cells, most of which position but some of which still act like they’re cells.  I think.

  Anyway, I was able to get IE7 to recreate 99% of the layout but couldn’t stop the overlap of the table and the following text (“Sources”, et cetera) without throwing in an extra div after the table and using a CSS hack to set its height in only IE7 so as to force the text below the timeline.  No thank you.  So I took the hacks out.  I admit I’m disappointed this doesn’t work as it should in IE7, but I have to remind myself that the fact that it even got close (and it did) is reason for hope.  And if anyone figures out how to fix the layout problems in IE7 (I tried zooming and relatively positioning the table element; neither worked), please let me know how you did it so I can update the CSS and credit you.

  Were I to change the markup to nested lists or divs or something, I suspect it would all come together just fine in IE7.  Not IE6, though… for reasons I’ll explain momentarily.

  Update: Sam Rayner pointed out that an adjacent-sibling-based rule targeted at IE7 would provide a decent fix for the overlap, so I added it in.  The above commentary still stands, except now we have a way to work around the major oddities.  Thanks, Sam!

• One of the requests for the original timeline was to have an indication of actual dates and browser names.  Yeah, that’s not going to happen with images.  In this version, I was able to use title attributes to add in that kind of information, revealable in tooltips.  It also seemed like an accessibility win, although I’m not sufficiently expert in that field to know whether titles on things like table rows and paragraphs would really help.

• Regardless, that’s the answer to the question I posed earlier: instead of using classes, I selected elements based on the contents of their title attributes.  So, for example, I place all of the August releases within their respective years by declaring #timeline p[title~="August"] {left: 62%;}.  For another example, I dropped IDs from the table rows, and used the title information instead.  This is an extra reason why the layout fails in IE6 and earlier: no support for attribute selectors.  I suspect IE6 would do okay with the layout if I’d used classes (and non-table markup) instead, but the goal here was to flex my creative-code side and push the envelope to its edges.  So to speak.

  This approach did make my CSS a bit longer.  Selecting on attribute values can be a longer-winded process than on class names, which tend to be compacted to the point of being cryptic.  On the other hand, using attribute selection allowed the markup to be a lot simpler, which is a benefit when adding browsers and new release data to the timeline.  Which, I should note, is now a whoooole lot easier than when I was scaling down JPGs generated from PNGs that I’d saved out of Keynote after using it to draw the dots and lines and such.

No doubt you’ll have noticed that the structured timeline looks different than the graphical one.  I believe I could have recreated the original’s look, but I kind of like this one better.  It’s more interactive, certainly, and having those descending lines (between the top of the timeline on the release dots) might clutter things up too much when looking for information to hover.  If you get what I’m saying there.

I’ve also considered that it would be possible to do a dependency timeline like the SVG-based timeline available on Wikipedia.  Doing so would require an entirely different markup structure; there, nested ordered lists make all kinds of sense.  Once that’s in place, the rest shouldn’t be terribly challenging to work out.  Tedious, perhaps, but not challenging.  But don’t expect me to do it any time soon: it would take too long, and draw too much energy and attention from other things that need to be done.

• Structured Timeline was published on Monday, January 21st, 2008.
• It was assigned to the CSS category.
• There have been forty-five replies.

Herewith I present the latest in what can only now be called a series of travel-tip posts.  (The first one, published a couple of years back, was about avoiding jet lag, if that’s of interest.)

I recently came upon a way to while away the lonely hours of a long plane flight and thought I’d share.  Two words: commentary track.  More specifically, listening to the commentary track (or tracks) of a movie you’ve already seen and enjoyed.

How is this better than just watching a movie?  Well, because you’ve seen the movie, you don’t really need to watch it: you can just listen to the commentary.  Thus, you can crank your laptop’s screen brightness down to “off”, thus saving some battery power.  Which you’ll need, thanks to the power required to drive the DVD.  If the commenter says, “Ooo, look here at this bit of the screen”, you just pip the brightness up enough to see what’s going on, and then crank it back down after.

Of course you can rip the movie with the commentary audio track to your hard drive to save the battery even more.  Also, if you’re willing to live without visual reference, you can rip the audio track itself and listen on an iPod.  But honestly, how many of us will go to that level of effort?  It’s a lot easier to bring along a single DVD and pop it into the laptop.  I also like this approach because plane flights are one of the few times when I have enough enforced downtime to get through a whole commentary.

Of course, if you’re lucky enough to be on one of the newer planes with grounded power outlets, your power worries are moot.  Still, when you have five or six hours ahead of you, a good commentary track or three is a good way to make the time pass more quickly.

• In-Flight Commentary was published on Saturday, January 19th, 2008.
• It was assigned to the Travel category.
• There have been four replies.

Way back in March of 2007, I moderated a SXSW panel called “A Decade of Style”.  As part of the introductory material, I created a browser-history timeline in Keynote, spread across two slides.  I’d always meant to throw it up on the web for general edification and reference purposes.  So I finally have, in a slightly simplified visual format (the original had a parchment-like background and so on).

In the end, the web form of this is pretty simple, even though it wasn’t simple to produce.  It’s just a series of images, one per year.  I have in mind a way to do it without the images, which would be nice, as that way the information would be accessible to the blind.  Right now, all the images just have empty alt values, I’m sorry to say.  Besides which, creating the same timeline out of structured content would be a fun challenge, albeit one I really don’t have the time to tackle right now.

A few notes:

• Internet Explorer has two lines, one for Windows and the other for Macintosh.  I did this because their release schedules often had little or nothing to do with each other.  The other browsers represented typically release cross-platform on or about the same day, and so each got a single line.

• The temporal resolution is one month.  In other words: no, I didn’t attempt to place the vertical connector bars so they correspond to the specific day of the month a browser was released.  In many cases, I don’t have that information—just the month and year of release.

• I was interested to discover that the “quietest” years in the timeline were 1999, 2002, and 2004 1999 and 2002.  (My earlier belief that 2004 was quiet was due to my having the wrong year for the release of Netscape 7.2.  Um, whoops.)

• Because the timeline was created for a session about CSS, the timeline starts in 1996 and doesn’t include pre-CSS browser versions.  I may extend it backward at some point, although that introduces interesting questions like whether or not to include Mosaic, Viola, Cello, and so forth; and whether to extend it all the way back to 1989.

• Yes, I’m missing browsers such as Konqueror and iCab, not to mention the whole forest of Gecko spin-offs like Camino and Flock.  Again, there’s the question of which browsers to include and which to omit.  This was dictated partly by perceived market share, but mostly by good old-fashioned laziness.

I’ll do my best to address any suggestions for improvement, though this is kind of a side project and so commands a comparatively small share of my attention.  Still, even if it never changes again, I’m happy that it’s finally out into the world.

• Browser Version Timeline was published on Wednesday, January 16th, 2008.
• It was assigned to the Browsers and History categories.
• There have been twenty replies.

I’ve been pondering reset styles over the past few months, and come to a bit of a shift in my thinking.  Here’s the result of that thinking.

html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
	margin: 0;
	padding: 0;
	border: 0;
	outline: 0;
	font-size: 100%;
	vertical-align: baseline;
	background: transparent;
}
body {
	line-height: 1;
}
ol, ul {
	list-style: none;
}
blockquote, q {
	quotes: none;
}

/* remember to define focus styles! */
:focus {
	outline: 0;
}

/* remember to highlight inserts somehow! */
ins {
	text-decoration: none;
}
del {
	text-decoration: line-through;
}

/* tables still need 'cellspacing="0"' in the markup */
table {
	border-collapse: collapse;
	border-spacing: 0;
}

The small changes involve a paring down of the possible quotation around blockquotes and qs.  Before, I was explicitly pushing in empty generated content boxes with content: "", but there was no need.  A simple quotes: none; takes care of suppressing any automatic quotation marks on those elements.

The much bigger change, the shift in thinking, is the removal of the inherit values in the first rule—the ones that wiped out any boldfacing, italicizing, or font variants in browsers other than Explorer.  (You can see them in the “reloaded” post.)  I know, I know, I already defended that practice:

[The inherit] effects, as seen in my development environment, will still serve the purpose of reminding me to build up the styles I actually want, and not use the browsers’ defaults as a crutch. There is the possibility of my forgetting that (for example) IE/Win italicizes em when I don’t want it to, but that’s something I’ll catch during the browser testing phase.

But over time, I’ve come to realize that this is more than just a throwaway development tool.  It really is the beginning of a baseline style sheet.  (Or can be.)  Things like boldfacing and italics are some of the most obvious textual effects readers will see, and to have reset styles that treat them inconsistently across browsers doesn’t make sense.

Of course, browsers might treat elements differently when it comes to boldness and decoration and such.  But unfortunately, without inherit as a viable solution (due to the lack of support in Explorer), we’re stuck accepting browser defaults.  This is one area where defaults are pretty well consistent across the board, so it’s a small risk to be taking.  And this certainly doesn’t preclude anyone from adding to these styles to create their own reset that explicitly handles elements like em and strong.

Which leads me to why I explicitly set ins and del.  In some browsers, inserted text is underlined.  This leads to confusion, because most people expect underlined text to be a link.  I decided to explicitly switch that off and leave a note about it, much as I did with :focus styles.

And why am I not zeroing out deprecated elements, like center?  Because they shouldn’t even be in the markup.  The way to handle deprecated elements is with something like Marco Battilana’s Big Red Angry Text, not silently neutering them.

Comments and suggestions are, as ever, welcomed.  I’m going to shift the end result to its own URL, as I promised I would long ago, so that there will be a permanent home outside of the various postings.  Hopefully that will happen before the week is out.

• Resetting Again was published on Tuesday, January 15th, 2008.
• It was assigned to the CSS category.
• There have been one hundred eighty-eight replies.

Or, how to not appreciate your existing customers.

Back in April of 2001, I was preparing to start work at Netscape.  I’d be working from home, so I needed high-speed access, and DSL was my best option.  Eventually, I decided on Earthlink.  It took a bit of effort, as there were some physical problems along the line to my house, but they got worked out and once the line was provisioned (whatever that means), I was up and running.  Nice speed, too.

So last week, I decided to find out how my rate—unchanged since I started almost seven years ago—stacked up to current rates.  It turns out I was a bit high, paying $49.95 a month for a service that would cost a new customer $34.95 a month, once their introductory monthly rates lapsed.  And I noticed that doubling my speed should cost $39.95 a month.

So I called up Earthlink to get my rates (both data speed and monthly fee) adjusted.  Guess what happened?  Yep: roadblocks.  First I was told that those were rates for new customers.  I pushed back, and was told that because I’d been a customer for so long, they were willing to adjust my rate to $39.95.  For the doubled speed?  Oh, no, for my existing speed.  If I wanted to go to the higher rate, it would be $54.95 a month.

My pointing out that this was grossly out of line with their current rates had no effect.  I assured them that I was more than willing to skip the introductory rates and just go to the base rates.  Didn’t help.  I could pay $39.95 a month for a service that should cost $5 less, or upgrade to the better service at a rate $25 higher than it should be.

Annoyed, I hung up and resolved to take my business elsewhere, as I’d warned them would be likely.  I did some digging and discovered that AT&T/Yahoo! DSL would cost $34.99 a month for twice the data rate I’d been getting at Earthlink with no term requirements—I’m not locked into it by an initial contract.  I like that.  I called them to find out how long it would take, and found out that DSL service has come a long way in seven years.  They provisioned the line remotely in three days, not the three weeks it took local technicians back in ’01.

So I’m up and running at 6M/768k in three days with no fuss and no term obligations, and best of all, my monthly cost has dropped $15.

Of course, when I called up Earthlink to cancel, they were suddenly able to offer me the rates I’d asked for before, plus they’d even throw in a month for free.  Too late, I told them.  I’d already tried and failed to get the regular current rates, and I’d invested the time and energy to find an alternative.  I wasn’t going to walk away from that just because they had belatedly decided to play fair.

It still amazes me that companies haven’t figured out that customers will make tracks if they’re treated badly.  And given the ease with which service can be established these days, if my new provider causes me trouble… well, I can always go elsewhere.  Or even go back.

• Access Switch was published on Tuesday, January 8th, 2008.
• It was assigned to the Personal category.
• There have been twenty-two replies.

I know it was only yesterday that I mentioned the opening of registration for An Event Apart New Orleans and the other 2008 shows, but there’s already more to share: later that same day, we announced the speakers for the other three shows of 2008.  Incredible lineups, every one.  We’re beyond excited.  Check ’em out!

• Speakers Galore was published on Thursday, January 3rd, 2008.
• It was assigned to the An Event Apart and Speaking categories.
• There have been four replies.

The new year is here, and to celebrate, we’ve announced details and opened registration for An Event Apart New Orleans, to be held April 24–25, and opened early registration for the other three events of 2008:

• Boston, June 23–24
• San Francisco, August 18–19
• Chicago, October 13–14

Now you can pick the show that best fits your schedule, fiscal year, or both, and book your seats early.

One of the things we’ve always striven to create is top-notch events for (as the motto goes) people who make web sites—covering design as well as code, architecture in addition to scripting, the big picture along with the nitty-gritty.  Focusing on that vision served us and our attendees very well in 2007, and it continues in 2008.  Just check out the list of speakers and topics for New Orleans:

• Andy Clarke, author of Transcending CSS, presenting “Underpants Over My Trousers”
• Aaron Gustafson, co-author of AdvancED DOM Scripting, presenting “Progressive Enhancement with JavaScript”
• Robert Hoekman Jr., author of Designing the Obvious, conducting “On-the-Spot Usability Reviews”
• Cameron Moll, author of Mobile Web Design, presenting “Good vs. Great Design”
• Brian Oberkirch, Publisher of Like It Matters, presenting “Kick it Like Pelé”
• Jason Santa Maria, designer at Happy Cog, presenting “Good Design Ain’t Easy”
• Dave Shea, co-author of Zen of CSS Design, presenting “Living, Breathing Design”
• Stephanie Sullivan, co-author of Mastering CSS with Dreamweaver CS3, presenting “Design Challenges, Standards Solutions”
• Jeff Veen, design manager at Google, presenting “Designing the Next Generation of Web Apps”
• Aarron Walter, author of Building Findable Web Sites, presenting “Findability Bliss Through Web Standards SEO”

And, as always, your hosts:

• Eric Meyer, author of CSS: The Definitive Guide, presenting both “The Lessons of CSS Frameworks” and “Debug / Reboot”
• Jeffrey Zeldman, author of Designing With Web Standards, presenting both “Understanding Web Design” and “Web Standards: The Return of the King”

You can get more details on the New Orleans event page, including descriptions of the sessions and details on how to get the special room rate at the conference hotel, the Hilton New Orleans Riverside.

While we don’t yet have speaker lists nor schedules to announce for the other three 2008 shows, we’re working to finalize them and hope to have at least some information out shortly.  I can already say that all the shows are at the same high level, though of course each event has its own unique flavor.

Those of you who attended one or more of our shows in 2007 (yes, we did have some repeats!) may be wondering if the shows will be the same, especially since we’re returning to some cities we visited last year.  The answer there is “not at all”.  Every show of 2008 is a mix of new and returning speakers, and we’ve done our best not to repeat speakers within a given city between 2007 and 2008.  The exceptions are myself and Jeffrey, of course, but we’re both doing new talks this year.  Simply put, if you loved AEA in 2007, we’re pretty confident you’ll love it even more in 2008.

• An Event Apart 2008 Lines Up was published on Wednesday, January 2nd, 2008.
• It was assigned to the An Event Apart and Speaking categories.
• There have been five replies.