Structured Timeline

Published 10 years, 1 month ago

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" />
<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>

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

  • Published
  • Categorized under CSS
  • 45 responses so far

  1. That really is quite a feat Eric. Congrats and thanks for all your hard work!

    Could we possibly have different icons for the Windows and Mac versions of Internet Explorer though? Having a single icon for both is rather confusing unless you check the title attribute or the discontinuation date further along.

    I’ll have a bash at sorting the IE7 layout bug but if you’re having trouble I highly doubt I’ll be of any help.

  2. Is there a reason you used a quite old Firefox icon? It’s probably from version 1.0 or older. You could use this one :)

  3. No good deed, eh, fellows?

  4. Wow, this is beautiful!

    Thanks not just for doing it, but also writing about how you did it in such detail. It’s like having a bonus episode of “Eric Meyer on CSS.” ;-)

  5. OK, the best I can do is:

    table + h3 { margin-top: 21em; }
    table { position: absolute; }

    Adding those two lines in your hacks area should bump the text down below the table in IE7 alone without needing to target it with conditional comments or use extra markup.

    Hope that helps.

  6. Beautiful! I love it.

    I thought about using title attribute for the dates on the SVG timeline too, but didn’t bother once I noticed that browsers didn’t display tooltips for the elements like HTML does.

  7. Nice one!

    I took my own shot on a timeline too for my resume. I’ts generated out of hidden form input’s that have either a value of one date or a date period and link to a specific part of the document. MooTools is used for the DOM searching and building.

    check it out if you like:

  8. Thanks, Sam! I incorporated the adjacent-sibling rule (using *+html #timeline + h3 to target IE7) and the overlap is gone. I got too hung up on the fact that the table wasn’t generating a box and forgot that it was still in the markup and selectable. Duh me!

    I’ll update the post in a few minutes.

  9. Magnificent! Thank you.

    I have two picky comments:

    1] the hover for IE 7 gives the year as 2007, instead of 2006.

    2] with the sideways scrolling I lost track of which browser was which. Maybe it would be useful for the hover to also mention browser?



  10. […] of CSS fame has created an extraordinarily cool browser timeline, but be sure to read his full blog post about it first. Here’s a brief extract: here’s a browser timeline built out of a […]

  11. No problem, glad I could help!

  12. I like! a lot. Only thing I’d suggest…is shortening the width so a person doesn’t have to move waaayy “off screen”. Maybe a wrapper with a #snackwrap { overflow: scroll;} or something. Then the source info below the table is still in view and easier to get back to.

  13. Impressive! Thank you.
    Found one small detail: IE7 is placed on Oct 2006 but the tooltip says Oct 2007.

  14. I updated the icons (having pulled clean PNGs from Wikipedia) and fixed the title information on IE7 to say “October 2006”. Thanks, all.

  15. Thank you, Meyer. Your CSS on this table will be something that I will study and from which I will learn.

    Not to be considered critiques, but two questions.

    1. Why no caption?
    2. A table length of this size, would it be practical or prudent to break it into three – four year sections to accommodate width?


  16. Eric, can you explain this:


    I thought the star hack was dead? –

    This appears to target IE7 only since 6 doesn’t support the + selector, right? I prefer to use the IF IE statements myself.

  17. Yes, Neal, the star hack is dead; long live the star hack.

    The one I’m using targets IE7 only, as you inferred, as IE7 believes there’s an element that precedes html. IE6 might also have believed this, but since it didn’t support adjacent-sibling selection, there’s no way to be sure.

  18. Great job, using only css! Have you seen the Simile timeline? All Ajax, maybe you should join forces to combine the best of both worlds.

  19. Eric\’s Archived Thoughts: Structured Timeline |…

    HTML time lines, with a bit of CSS…

    Assigning position: relative to table cells…

  20. Groovy. Excellent hover effects. And what’s that lovely font you’re using for the links?

    Now if only I saw an Omega sign like the one for Netscape next to IE. :-)

  21. Browser History Timeline…

    Simplicity at it’s best :) Nice… and all this structured time was done using a table ;)

    Information is decent enough, just hover the time versions, and you’ll know the month :) Actually if you’re good enough, you can guess what month it is by l…

  22. […] at retesting but ultimately achieves a very straightforward, standards compliant and very cool Structured Timeline purely using html and css. I love […]

  23. Thacker:

    1. A caption seemed redundant given the summary. Certainly one could be added.
    2. I find that timelines really only work for me if they’re contiguous; breaking them up into separate sections gets me lost in a hurry. I’d sooner rotate it to run top-to-bottom than break it up. But that is, I fully acknowledge, a personal view.

  24. Chrisfont: 1em Cochin, Georgia, serif;.

  25. Eric, the star in *+html is the doctype, that’s why if you insert a comment between the doctype and html you can use this *+*+html to target IE7.

    I definitely going to be an interesting year for browsers with 4 alpha/beta all being worked on and coming out like IE, FF, Safari and Opera. Viewing your graph this has never happen before.

    I have been working on stats from 2005 to now that I have for two of my genealogy sites. Considering the typical visitor I can see that site visitors don’t update there browsers or still use Netscape 4 (like half a percent). I will send a link to you.

    BTW, to take care of IE7 change your font size from em to 100% on the body.
    font: 100% Cochin, Georgia, serif;

    then the table will not overlap the source (even when zooming). For IE6 this will do the trick.

    * html h3 {
    margin-top: 20em;
    * html #timeline thead tr {

  26. I know, Alan. That’s why I said “IE7 believes there”s an element that precedes html“—because the DOCTYPE is not an element.

    Thanks for the font-sizing suggestion. I’m not going to use it in this demo, though, because if anything triggering the font-change bug in IE will stress-test my em-based layout skills beyond what one would generally expect.

  27. Outstanding! Haven’t had to pick my jaw up like that since the Jedi Secrets bar graph demo @ AEA Boston.

  28. Eric, I sorry,. I read that part over and over and I thought parent instead of sibling.

    I don’t understand. Doesn’t 1em equal %100. The same as line-height:1; equal line-height:100%;. The problem with the page in IE7 is due to the font size em on bug. Are you triggering it on purpose?

  29. […] Meyer constructed a browser timeline built out of a table, and how he went about coding the html and css. Nice work. Tags: CSS, Firefox, HTML, IE, […]

  30. […] Structured Timeline (tags: gr2dic) […]

  31. Wow, that’s really quite stunning! I’m late to the party and am trying to get up to speed with CSS, and I love the examples on your site.

    I do have a question that I realise is a bit off-topic, but I’m trying to ensure that I got a handle on industry best practices. You have included the *+html IE7 hack on your site, but to quote Tantek Celik, ‘a hack should target ONLY older/frozen/abandoned versions of user agents / browsers.’

    Now that we know about IE8 multiple rendering engines, does his rule no longer apply?

    Love your O’reilly book by the way, it is never more than an arm’s length away on my desk and completely dog-eared.

  32. […] move onto a well-formulated (yet opinionated) response here, then bring it home with latest from here (the next few entries correspond as […]

  33. […] Eric’s Archived Thoughts: Structured Timeline – Um, 1993? 1994? 1995? And where’s the new IE8 meta tag? […]

  34. […] Here’s how he did it […]

  35. […] the * hack is dead, long live the * hack — Using * html was a fairly well known CSS hack that caused a rule to be set in versions of Internet Explorer 6 and below, but did not work in Internet Explorer 7 or any other A grade browser. During a discussion Eric Meyer’s update of his Browser History Timeline he revealed that a new form of the * hack lives on in Internet Explorer 7 through the use of the adjacency selector (because IE7 sees the DOCTYPE as being adjacent to the html element). While CSS hacks are very bad in theory, they are very useful in practice. […]

  36. […] CSS Structured Timeline […]

  37. […] here’s Eric Meyer’s CSS for “building a structured timeline out of a table.”    As you mouse over the timeline, the row changes color, and it looks like table items could be […]

  38. […] CSS Structured Timeline<br/> […]

  39. hey how can i embed this on my web page?

  40. Did you have a CSS way of generating the table at ?

  41. […] Structured Timeline — Eric Meyer’s table approach to timelines. […]

  42. […] but it is still as useful today as when it was written. He also managed to convert a table into a nice timeline using only CSS . This demonstrates the power and flexibility of HTML and CSS in creating charts and […]

  43. […] but it is still as useful today as when it was written. He also managed to convert a table into a nice timeline using only CSS . This demonstrates the power and flexibility of HTML and CSS in creating charts and […]

  44. Hey Eric,

    Great timeline tool, very impressive! You may have forgotten all about this project by now, but in case not…have you tried the timeline in IE9 and if so, are you aware of why all the rows are stacked on each other outside the table?

    I think it has something to do with the differences between how IE and other browsers interpret relative vs. absolute positioning. But I’m no CSS expert…I was just hoping to utilize your timeline since it looks so nice but I cannot get it to work with IE9.

    Thanks in advance

  45. IE9 doesn’t work indeed. but you can use the ‘ compatibility mode’ then it works.

    hopefully someone with CSS skills can fix this. chrome and FF do work perfectly !

    thanks Eric for this nice coding ! :)

Leave a Comment

Management reserves the right to edit or remove any comment, especially when abusive or irrelevant to the topic at hand. HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <em> <i> <q cite=""> <s> <strong> <pre class=""> <kbd>

Comment Preview

If you're satisfied with what you've written, then go ahead...