Almost Target
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:
- Had improved standards support in the browser, and then
- Found sites whose layouts broke as a result
- Whose developers point-blank refused to alter their sites
- 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.
