Posts from 2008

I’m going to follow the lead of the Airbag crew and mention publicly that, as per the decision I reached last March, I will not be attending SXSWi this year.  I thought about posting to that effect a few months ago and decided against it—what, am I supposed to post about every conference I’m not attending?  That doesn’t exactly scale.

But there really is something different about SXSWi.  It’s the annual tribal gathering for our field and a couple of related fields, or at least is the annual tribal gathering who aren’t freaky/insane/hardcore enough to hit Burning Man.  The default assumption is that you will be in Austin in March, which is actually a symptom of the conditions that led me to opt out this year.

I can sum up why I’m not going in just a few quick bullet points (and if you’re going to attend any panels, get very used to bullet points):

• I can’t concentrate above a certain noise level
• I don’t function well in large crowds
• I don’t drink alcohol
• I’m not single

There is a last selfish reason to go, which is to see a bunch of friends and acquaintances I don’t get to see other places.  Only SXSWi has grown so incredibly huge that I didn’t really get to do even that last year.  There were people who were there the whole time I was that I never saw, like Matt.  I don’t mean that I didn’t have enough time to talk with them, either.  I mean that at no point did photons scattered by their bodies land on either of my retinas.

Don’t get me wrong: SXSWi is a huge buzz.  You can get a geek high just standing around soaking up the ambient energy, and you never know who you’re going to run into.  I once shared a cab with Cory Doctorow and Lisa Rein without, I think, any of us really knowing who the others were until halfway through the trip.  The opportunities to meet and greet and get to know people of every kind are just incredible.  Like I said, it’s a tribal gathering.

So there is of course a part of me that’s sad I won’t be there, because the great thing about SXSWi is the people, both those I know and those I don’t know yet.  There’s a much bigger part of me, though, that’s glad I’ll be spending those five days at home with my family instead of feeling frustrated and lonely in a crowd notably bigger than the town where I grew up.

Anyway, if you’re going and especially if you’re going for the first time, I urge you to pay special attention to the wisdom of Mr. Bag:

Want to meet that OMG OMG OMG blog A-lister?! Fine, just go do it. Nobody, and I mean nobody in this industry is so huge that they can’t be bothered to say hello and shake your hand. And that’s it, done.

To which I’d only say “that OMG OMG OMG blog A-lister” should be replaced with “anyone who interests you”.  Blog A-lister, design rockstar, code guru, startup maven, whoever.  Just go up and say hi and spend a few minutes chatting.  It’s totally cool.  In fact, it’s kind of the point.

• South Bypass was published on Friday, February 22nd, 2008.
• It was assigned to the Travel category.
• There have been sixteen replies.

A List Apart #253 brings the issue of version targeting back into the limelight with opposing-view pieces by Jeremy Keith and Jeffrey Zeldman.  (And I love the “Editor’s Choice” on this issue, J. David Eisenberg’s “‘Forgiving’ Browsers Considered Harmful“.)

I’m not going to comment on the views presented; both gentlemen do a fine job.  What I do wish to add, or perhaps to restate, is an observation about everyone interested in, and thinking or arguing about, this topic:

We all care about the same thing.

We all want to advance web standards.  We all want browsers to improve their support.  We all want better and more advanced specifications.  We all want to reduce inconsistencies.  We all want a better web.

The disagreement is over how best to get there given the situation we face now, as well as how we perceive that current situation.  A recurrent metaphor for me is that we’re a large group of pioneers trying to chart the best course through an unknown country, and there is disagreement on which route entails the least risk to the whole group.  Cross the desert or the mountains?  Traverse a swampy delta or a hilly forest?  Move through this valley or that one?

Sometimes what binds us is strong enough that the few differences seem sharper by comparison.  That shouldn’t keep us from remembering what we have in common, and the importance of that commonality.

• Common Bonds was published on Tuesday, February 19th, 2008.
• It was assigned to the Browsers and Standards categories.
• There have been eighteen replies.

It’s not every day I uncover a case involving the botched theft of information about nuclear weapons.

Here’s how it went down: in the infosthetics feed was an entry about a video regarding nuclear stockpiles around the world and the effects of a nuclear explosion in New York City.  The video was produced by Chimp on a Chain for Good Magazine.

That’s a long-standing area of interest for me, so I watched it.  When I got to the New York City portion, something started to bother me beyond the obvious horror of the scenario.  The point of detonation, the explosive yield, the elapsed-time intervals, the radius distances—all seemed very familiar, like I’d seen them somewhere before.  And I had.

They were nearly all taken verbatim from the New York City scenario found at the Atomic Archive.  I could find only two differences.  The first is that the total death toll given in the video is slightly higher than that in the Atomic Archive’s scenario.  Otherwise, all the numbers matched up.

The second difference is really a major error on the part of the video’s makers: they dramatically under-represent the areas of damage.  For example, the ten-second ring’s (found at 2:33 in the movie) radius is labeled with the correct distance (2.5 miles) but the circle placed on the map is much, much too small to be 2.5 miles in radius.  The circle doesn’t even cover the breadth of Manhattan Island, whereas an accurate plot would have it stretch across the Hudson River on both sides into New Jersey and Long Island.  You can see this in part 5 of the Atomic Archive’s scenario, or on a HYDEsim plot of the same scenario.

The video seriously misrepresents the area of damage that would result from such an incident, making it appear much smaller than it would be, and I just can’t fathom how or why they would get that so wrong.  Even assuming they mixed up the meanings of “radius” and “diameter” doesn’t appear to explain it.  The ring distances shown correspond to a three-kiloton explosion at most, not to 150KT.

That’s the botched part.  So where’s the theft?  There is no credit whatsoever given in the video for the material’s source.  There is a reference to the Archive on the video’s page at Good in the “Resources” box, but the material in the video has been used without permission—I checked this with the custodian of the Archive—as required by the site’s policy.  Even if one could argue this is a case of not needing permission on non-profit grounds, attribution is still required.

It would almost be worth subscribing to Good so that 100% of my payment could go to the non-profit of my choice, as the site promises, except I’m limited to their choices of non-profits and none of them appear to be charged with educating magazine publishers or video artists about the niceties of copyright law, intellectual property rights, or even just plain common courtesy.

• Manhattan Problem was published on Thursday, February 14th, 2008.
• It was assigned to the Rants and Tools categories.
• There have been six replies.

I’ve hinted and teased and promised, and I’ve yet to make good on any of it.  I’m sorry.  Can I make it up to you?

Okay, then, here you go: a permanent home for my reset styles.  It takes up residence in a new “CSS” subsection of the Toolbox section of the site, along with my efforts to create a generic set of diagnostic styles.  In the case of the resets, I’ll increment the version number and date whenever I make changes, and probably maintain an archive of previous versions.  Not that I expect that to happen with any frequency, but you never know.

The diagnostics are a lot more experimental and thus aren’t so formal as to have things like version numbers.  If I change anything of specific interest there, I’ll try to write a post about it.  I should get around to writing about the shown-in-page stylesheet one of these days, though I figure anyone can view source and work out the particulars without too much effort.

• CSS Tools: Reset and Diagnostics was published on Tuesday, February 12th, 2008.
• It was assigned to the CSS and Tools categories.
• There have been twenty-one replies.

After I published the latest iteration of the reset styles, Paul Chaplin pointed out that my simplification of the quote-suppressing rules actually broke the intended effect in Safari 2, Gecko variants , and so on.  This happened because I assumed support for quotes: none, and it just isn’t there in most browsers.  Apparently, I was testing IN THE FUTURE! that day.

“Well, no problem,” I thought to myself, “I’ll use content: none instead”.  Nope.  Even in browsers that support generated content, support for the content value none appears to have fallen through the cracks.  Using it completely fails to suppress the generation of content, so far as my testing can determine.  Even more amusingly, content: normal prevents the insertion of quotation marks in Camino (and probably other Geckos), but not Safari.

So we’re back to explicitly forcing the assignment of empty content boxes in order to stop the insertion of quote marks: content: '';.  Oh, joy.  Paul had come to the same conclusion, and worked out a nice little fallback set that reminds me of the cursor trick that gets you a hand-pointing icon in both IE and the rest of the world, only his trick is completely valid.  So I’ll be adding that in, along with some thanks to Paul.

For my next magic trick, maybe I’ll base a reset rule on :nth-child() and see what people invent to simulate the intended effect.

• Non-Quotidian Problems was published on Friday, February 8th, 2008.
• It was assigned to the CSS category.
• There have been fourteen replies.

Ladies and gentlemen, the Cleveland Web Standards Association.  Specifically, its brand-new web site, courtesy a small band of association members who worked together to design and develop it.  It’s a lovely little semantic number, chock full of microformats and member content aggregators.

In case you hadn’t heard about the CWSA yet and are wondering what the group is like, allow me to quote the About page:

The CWSA is an organization grounded on the premise of sharing information in a relaxed atmosphere. We hold monthly gatherings that include presentations on best practices in web development. The gatherings are open to any person interested in web design/development, no matter what their current skill level is.

This isn’t just a social club, though.  We’re not just sharing our skills with each other, but are also working to use those skills in the service of helping others.  I don’t want to steal any thunder, so if you want to find out the details, you’ll just have to come find out for yourself.

We’ll be having our next meeting in a week, 5 February 2008, in our usual space at Tri-C (and many thanks to the college for giving us a home!).  This is definitely a meeting to make, because the topic will be the current and future direction of the association, including deciding the topics on which we want to have presentations and figuring out how best to use the raw talent and enthusiasm of the group for maximal good.  If you’re in the area, you should absolutely come check things out.  If you know someone in the area, kindly pass the word on to them.

• Cleveland Web Standards Association was published on Tuesday, January 29th, 2008.
• It was assigned to the Cleveland and Standards categories.
• There have been eighteen replies.

I’d like to tell you a little story, if I may, from way, way back in 2002.  (The exact date is lost to the mists of time, but the year is pretty solid.)  Like a lot of stories, it’s little bit long; but unlike some stories, it’s true.

As the engineering staff at Netscape prepared a new release of Mozilla, the browser off which we branched Navigator, those of us in the Technology Evangelism/Developer Support (TEDS) team were testing it against high-ranked and partner sites.  On a few of those sites, we discovered that layouts were breaking apart.  In one case, it did so quite severely.

It didn’t take much to see that the problem was with sliced images in layout tables.  For some reason, on some sites they were getting pushed apart.  After a bit of digging, we realized the reason: the Gecko engine had updated its line-layout model to be more compliant with the CSS specification.  Now images always sat on the baseline (unless otherwise directed) and the descender space was always preserved.

This was pretty new in browserdom, because every other browser did what browsers had always done: shrink-wrapped table cells to an image if there was no other cell content.  The only problem was that behavior was wrong.  Fixing the flaws in the CSS implementation in Gecko had broken these sites’ layouts.  That is, it broke them in standards mode.  In quirks mode, Gecko rolled its behavior back to the old days and did the shrink-wrap thing.

We got in touch with the web team at one of the affected sites, a very prominent social networking site (of a sort) of the day, and explained the situation.  We already knew they couldn’t change their DOCTYPE to trigger quirks mode, because that would break other things they were doing.  We couldn’t offer them a simple CSS fix like td img {vertical-align: bottom;}, because their whole layout was in tables and that would throw off the placement of all their images, not just the sliced ones.  All we could offer was an explanation of the problem and to recommend they class all of their sliced images and use CSS to bottom them out, with assurances that this would cause no change in other browsers.

Their response was, in effect:  “No.  This is your problem.  Every other browser gets this right, and we’re not mucking around in our templates and adding classes all over just because you broke something.”

The truth, of course, was that we were actually fixing something, and every other browser got this wrong.  The truth was not relevant to our problem.  It seemed we had a choice: we could back out the improvement to our handling of the CSS specification; or we could break the site and all the other sites like it, which at the time were many.  Neither was really palatable.  And word was we could not ship without fixing this problem, whether by getting the site updated or the browser changed.  Those were the options.

Let me reiterate the situation we faced.  We:

1. Had improved standards support in the browser, and then
2. Found sites whose layouts broke as a result
3. Whose developers point-blank refused to alter their sites
4. And we had to fix the problem

We couldn’t back out the improvement; it affected all text displayed in the browser and touched too many other things.  We couldn’t make the site’s web team change anything, no matter how many times we told them this was part of the advance of web standards and better browser behavior.  Two roads diverged in a yellow web, and we could choose neither.

So we found a third way: “almost standards” mode, a companion to the usual modes of quirks and standards.  Yes, this is the reason why “almost standards” mode exists.  If I remember the internal argument properly, its existence is largely my fault; so to everyone who’s had to implement an “almost standards” mode in a non-Gecko browser in order to mirror what we did, I’m sorry.

We made “almost standards” mode apply to the DOCTYPE found on the offending site—an XHTML DOCTYPE, I should point out.  While we were at it, we rolled in IBM’s custom DTD.  They were using it make their site validate while doing all kinds of HTML-invalid stuff, and they were experiencing the same layout problem.  And lo: a third layout mode was born.  All because some sites were badly done and would not update to accommodate our improvements.  We did it so as not to break a small (but popular) portion of the web while we advanced our standards support.

(By the way, it was this very same incident that gave birth to the article “Images, Tables, and Mysterious Gaps“.)

Now take that situation and multiply it by a few orders of magnitude, and you get an idea of what the IE team faces.  It’s right where we were at Netscape: caught between our past mistakes and a site’s refusal to accommodate our desire to improve support for open standards.

Some have said that Microsoft is in a unique position to take leadership and spread the news of improved standards and updating old sites to its customers.  That’s true.  But what happens when a multi-billion dollar partner corporation refuses to update and demands, under the terms of its very large service contract and its very steep penalty clauses, that a new version of IE not break (for whatever value of “break” you like) its corporate intranet, or its public e-commerce site?  It only takes one to create a pretty large roadblock.

For all we did in publishing great content to DevEdge, proactively helping sites to update their markup and CSS and JS to work with Gecko (while not breaking in other browsers), and helping guide the improvement of standards support in Gecko, we could not overcome this obstacle.  We had to work around it.

Looking back on it now, it’s likely this experience subconsciously predisposed me to eventually accept the version targeting proposal, because in a fairly substantial way, it’s what we did to Mozilla under similar conditions.  We just did it in a much more obscure and ultimately fragile manner, tying it to certain DOCTYPEs instead of some more reliable anchor.  If we could have given that site (all those sites) an easy way to say “render like Mozilla 0.9” (or whatever) at the top of every page, or in the server headers, they might have taken it.

But had we offered and they refused, putting us back to the choice of backing out the improvements or changing the browser, would we have set things up to default to the specific, known version of Mozilla instead of the latest and greatest?  The idealist in me likes to think not.  The pragmatist in me nods yes.  What else could we have done in that circumstance?  Shipped a browser that broke a top-ten site on the theory that once it was in the wild, they’d acquiesce?  Even knowing that this would noticeably and, in a few cases, seriously degrade the browsing experience for our users?  No.  We’d have shipped without the CSS improvement, or we’d have put in the targeting with the wrong default.  We didn’t have version targeting, but we still made the same choice, only we hinged it on the DOCTYPE.

A short-term fix for a short-term problem: yes.  Yet had we not done it, how long would Netscape/Mozilla’s standards support have suffered, waiting for the day that we could add that improvement back in without breaking too many sites that too many people would notice?  Years, possibly.  So we put in a badly implemented type of version targeting, which allowed us to improve our standards support more quickly than we otherwise would have, and it has been with us for the more than half a decade since.

So maybe I’m more sympathetic to the IE predicament and their proposed solution because I’ve been there and done it already.  Not to nearly the same degree, but the dilemma seemed no less daunting for all the difference in scale.  It’s something worth keeping in mind while evaluating what I’ve said on this topic, and whatever I will say in the future.

• Almost Target was published on Thursday, January 24th, 2008.
• It was assigned to the Browsers, History, and Standards categories.
• There have been eighty-two replies.

So yesterday was interesting.  In a whole lot of ways.

As I expected, there were some widely varied reactions (there’s a good list over at Digital Web, if you’d like to taste the rainbow) and many of them were in opposition to the whole idea.  The opposition was fine, but the tone taken by many was not.  Even though I expected some flaming, I admit I really didn’t expect the overall tone to be so vitriolic, and I found it to be profoundly depressing.  I’m not talking to everyone here, but it still needs to be said: if you feel the need to impugn the integrity or intelligence of another person to oppose an idea, you’re undercutting yourself, not your target nor the thing you oppose.  It’s the dialectical equivalent of “considered harmful“.

A number of people said things to the effect of what Roger said: “explain why we’re wrong to oppose this”.  That I cannot do.  I was hoping for opposition, because that’s the only way to really test an idea.  I’m not so arrogant as to think that I alone can account for every variable and forecast the eventual outcome.  I can only explain, as I tried to do, why I think it’s a good idea, and listen to the reasoning of those who think it’s a bad idea.

No explanation is ever complete, of course, so here’s some followup.

I suspect that a good deal of the emotional objection springs from a perception that the proposal is to require all browsers to implement targeting.  Not at all.  Please be clear on this: nobody is saying this should be required in any browser.  It can be interpreted as a requirement for authors, which is a separate issue, and I think one that’s quickly becoming negated as people work through the details.  Not necessarily negated in a way Microsoft would like, but that’s really their problem.  (See, for example, Sam Ruby’s solution.)

One very likely outcome here is that IE does this and all the other browsers don’t.  In a lot of ways, I’d be happiest with that outcome, because it would give us the opportunity to evaluate both approaches in parallel.  Personally, I think other browsers should adopt the same mechanism only if they feel they need it.  So far, they’ve indicated that they don’t.  Fair enough.  IE gets to try its hand at maintaining multiple internal versions, and everyone else can continue as usual.

In that vein, I have to admit that I don’t understand the assertions that this will make life harder on other browsers, that they’ll have to support all the various rendering modes in IE.whatever.  Can someone explain that to me, please?  I’m not saying the assertion is wrong.  I’m saying I don’t understand why that would be the end result.

At a wider level, I think a lot of people are discounting the fact that version targeting is absolutely nothing new in the standards world, let alone the web development world.  Conditional comments, CSS hacks, and the DOCTYPE switch itself are all examples of version targeting.  When I write *+html… I’m doing it because I know IE7, and IE7 alone (at least for now), will see the declarations in that rule.  I did exactly that just the other day, in fact.  There’s a whole sub-set of the current CSS corpus based on figuring out parser bugs to exploit into hacks that are used to feed rules to specific browsers or specific versions of browsers.  We’ve been doing this for years.  I mean, okay, if you’ve recently done client work where you didn’t need any form of detection at all—as in, you quite intentionally used none of the things I just listed—then you can exempt yourself from the “we” in that statement; furthermore, my hat is off to you.  Seriously.  Because I can’t remember the last time I was able to avoid using at least one or two CSS hacks in a project in order to deal with browser inconsistencies.

I’m not going to claim that these mechanisms are universally broken.  In fact, I believe exactly the opposite: they’ve long since proven their utility in an imperfect world.  (The perfect world being the one where all browsers implement all standards correctly and no form of browser detection is ever needed.)  That alone made me reconsider the targeting proposal in a whole new light.

The handling of JavaScript libraries in a world where the pages calling the libraries will determine how the JS is interpreted—that’s definitely something I hadn’t considered.  As I understand it, the problem case is one where a JS library that uses (say) IE9 features is loaded into a page that triggers the IE7 engine.  The library would need to preserve backward compatibility with all the IE versions that could be used.

But isn’t that already the case?  Every library whose source I’ve studied has all kinds of detection, whether it’s feature or browser detection, in order to work with multiple browsers.  I would think that under version targeting, the same thing would be necessary: you do feature detection and work accordingly.  Again, it’s entirely possible I missed something there, so feel free to let me know what it was.

As for the proposed default behavior, where no X-UA-Compatible information gets you the IE7 rendering, I can’t defend that, nor do I have any wish to defend it.  I tried for most of an hour to convince a member of the IE team that the default behavior should be “latest”, not “IE7”, and was unable to make a sufficiently persuasive case—by which I mean a case that overcame the (perceived) needs of the IE team.  My hope is that someone will succeed where I failed.

Because yes, I too want to be able to leave off the meta, leave my server’s HTTP headers alone, and still get the latest and greatest in standards support from IE.whatever.  That’s how browsers have always acted, and it’s what I’m used to handling.  If someone can convince the IE team that doing this would be in their (and their company’s) best interests, then we’ll all be in your debt.  With the growing collection of workarounds, I think it might be possible to convince them that the default behavior we want is going to quickly become the de facto standard, they should go with the flow and make it the default internally.  I don’t know if that will work, but it’s worth a try.

It has to be realized that this may well be the only way for IE to advance its standards support in a reasonable time frame, or at all.  Version targets let them avoid breaking existing sites, especially intranet sites, while fixing and adding their DOM, CSS, and other implementations.  That has to be understood and accepted if the discussion is to be anything more than people talking past each other.  Within the world of IE, they must have a way to uphold backwards compatibility with sites developed under older versions of IE.  Without it, they will largely stop fixing bugs they discover in their standards support.  It really does come down to that.  The fact that their current situation is their own fault is not really relevant to the topic of moving forward.  This is a way forward for IE, just as the DOCTYPE switch was a way forward for a number of browsers (including IE) back at the turn of the millennium.  It may be the best way.  If there’s a better way for them to meet that need, then I absolutely want to hear it.  But remember, “let old sites break” is a non-starter.  You might as well say “let old sites not load at all in any browser”.

At any rate, I’m opening comments on this post, and I do hope there will be reasoned discussion of the pros and cons of version targeting.  As always, I’m going to enforce civility in the discussion.  Disagreement, opposition, objection: all fine, and in fact encouraged.  Flaming: not fine, and will be deleted.

• Version Two was published on Wednesday, January 23rd, 2008.
• It was assigned to the Browsers and Standards categories.
• There have been ninety-four replies.