Posts in the Tech Category

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.

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.

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.

Opera fired a broadside at Microsoft today.  In accompaniment, Håkon Lie posted “an open letter to the Web community” in which he says:

To those of you who build and shape the sites and services we use everyday — and who will create those in the future — I ask for your support. You will be the ones who ultimately benefit by having a Web that works seamlessly and effortlessly across devices, browsers and is equally open to everyone. That new day is just over the horizon…

Yes, it is.  Or maybe it was, until this happened.

Look, the time to file this motion and make this appeal was in 2005, when Internet Explorer had been dead in the water for years and it was genuinely holding back web design.  Then there’d have been a case to make.  When IE7 came out in late 2006, it wasn’t a great leap forward for web development, but it did bring IE more or less in line with where browsers were at the time—which was, frankly, a pretty large leap.  After all, they were doing five years of catch-up with a pretty small team.  Now we have IE8 in development, and there is a real chance that it could push standards support forward in a significant way.

But not if developing the browser becomes more of a liability than just walking away from it altogether.

They can’t do that, you say?  Oh, but they can, and at a corporate level would probably love nothing more than to do so.  With Silverlight, there’s the opportunity to create browser-like internet applications that support no open standards, answer to no external specifications.  The IE team would likely disagree strongly with such a course, but cut funding to the team and there’s little they can do to change it.  If you think web development is horrible now, how about a future where there literally are entirely different browsers to support?  Or a future where the open web is largely shriveled and dead thanks to wide-scale abandonment by the Windows community?

I am not advocating that we hold ourselves hostage to what Microsoft, or indeed any company, might try to do.  We’re already held hostage enough to the glacial pace of the W3C (and Mr. Clarke has some ideas on how to fix that).  What I’m advocating is that rather than attacking the laggard right when he’s showing promise of catching up and being part of the team again, it might be better to help him along, maybe even say a few words of encouragement.  Unless, that is, this attack springs out of some sort of perceived threat—in which case, just say so, and don’t use web standards as a fig leaf.

I wondered, upon having this instinctive reaction unfold, whether I was completely off my rocker.  But then I asked myself what I’d think if, say, Opera or Microsoft or anyone had pulled a similar move against Netscape circa 2001, when Netscape 6.0 was out and causing widespread grief while the programmers struggled to update and fix its standards support.  The answer came back the same.

It’s the wrong move at the wrong time, sending precisely the wrong signal to Microsoft about the importance of participating in development and support of open standards, and I can only hope that it comes to a quiet and unheralded end.

• Bad Timing was published on Thursday, December 13th, 2007.
• It was assigned to the Browsers and Standards categories.
• There have been sixty-two replies.

Two months ago, we had someone essentially spam css-discuss by sending a social networking invitation to the list.  Now, I’m all for making connections, but inviting close to 8,400 people all over the world to join your favorite new social graph seems a bit, well, anti-social.  Further, there was a statement right in the invitation that sending it to someone not personally known was an abuse of the service.  Regardless, it was a violation of list policies, so we booted the offender from the list.  I followed the “never send invitations to this address again” opt-out link and reported the offender via the abuse reporting address.

I very quickly got back a reponse from the team, expressing regret over what had happened and promising to take care of it.  I suggested they domain-block css-discuss.org and webdesign-l.com (you’re welcome, Steve), thanked them for being so responsive, and that was the end of it.  Until a few days later, when I got personally spammed from the same user account.  I reported them again, this time with a bit of snark, and opted myself out.  I didn’t hear a word from anyone.

Of course, as you’ve guessed from the title, the site in question was Shelfari.  And thanks to what I’m now finding out about their practices, it’s quite possible—even probable—that the offender was Shelfari itself.

What we have here is a clear case of bad design causing negative ripple effects far beyond the badly designed site.  In the case of css-discuss, over eight thousand people got spammed through a members-only list they’d joined on the promise of high signal and low noise.  I expelled a member of that community as a result of what a site did for them thanks to bad UI.  I feel bad about that.  Had I known, I might have put the account on moderation until they could be reasonably sure things were cleared up with Shelfari instead of just booting them.  So I’ve tracked down their address and apologized, which seems the only honorable thing to do.

It may also be the case that bad ethics are as much to blame here as bad design.  This is much harder to assess, of course, but the fact that the opt-out action was completely ignored makes me much less likely to chalk it all up to a series of misunderstandings.  Even if the Shelfari team was trying to be good actors and bungling the job, it’s little wonder they’re being hung with the spammer tag (the “Scarlet S”?).  Automatically using people’s address books to spread your payload is a classic worm-spammer technique, after all.

Given all this hindsight, I’m definitely intrigued by the following passage from the mail they sent me on 14 September:

We make it super easy to invite, but some people just send to all, which isn’t really what we want.

In other words, the very thing they’re apologizing for now, the thing that has caused such a recent uproar, was known to them no later than two months ago.  So yeah, no surprise that a whole bunch of folks are not cutting Shelfari even one tiny iota of slack.

Anyway, the bottom line is this: if you’re signing up for a social networking site and they offer to contact people you know or import your address book or things of that nature, be very cautious.  And be doubly cautious if you’re signing up for Shelfari.

• Shelfarious Behavior was published on Wednesday, November 14th, 2007.
• It was assigned to the Books and Web categories.
• There have been five replies.

In an effort to get a handle on my taskflow, I went looking for an organizer application.  So far as I can tell, what I want doesn’t exist, but maybe someone can point me to it.

What I really want is a push queue for documents and other data fragments.  I’ll call it “Q”, both for the obvious phonic match as well as to score a little ST:TNG joke plus make a Cleveland arena reference.  The latter two work because I sort of envision the application as being a very powerful being as well as a large gathering place for data.

The way I envision it, I drag a file onto the main Q window and it’s added to the general pool.  Every item in Q can be labeled, tagged, commented, and otherwise meta’d half to death.  The queue can be sorted or filtered on any number of things—file creation or modification date, Q addition date, file name, containing folder, tags, labels, and so forth.  Also, every item can be assigned a due date.

When I double-click on anything in Q, it opens the original file just as if I’d double-clicked its Finder icon.  (I’m an OS X user, but translate “Finder icon” to whatever the equivalent words are in your OS of choice.)  So really, Q is maintaining a pool of aliases to the original files, plus any associated metadata.  In that sense, it’s like iTunes set to not copy added music to the iTunes Music folder in your home directory.  Yes, some people run it that way.  And like iTunes, the ability to create smart lists based on tags and comments and such would be really awesome.

I’d find Q deeply useful because as new tasks come in/up, I could drag in whatever file(s) relate to those tasks so that I don’t lose track of what I have to do, quickly tag them and set a due date, and continue with whatever I was working on.  There’s room for tons of even more useful features like synchronization across multiple computers, the ability to accept any fragment of data at all as opposed to files, and more, but the core need is a task queue.

To illustrate this with some examples from my recent workflow, I would drag in a copy or two of the IRS W-9 form, a couple of e-mail messages, an invoice, and a Word document containing a set of interview questions.  The W-9s would get tagged by the clients’ names, the invoice would be tagged and flagged, and so on.  The real key here is that they’d be add-sorted by default, so I can work on them first-come-first-served.  Of course, other approaches would be possible with other sorts and filtering.

It seems like, with all the GTD mania floating around, someone would have come up with this solution already, but my searches have so far been fruitless.  I tried a couple of applications that seemed like they might be close to what I want, but they weren’t.  Am I just using the wrong search terms, or is this something that just doesn’t exist yet?

• In Search of Q was published on Thursday, November 8th, 2007.
• It was assigned to the General, Tools, and Work categories.
• There have been thirty-five replies.