Posts in the Browsers Category

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.

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.

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.

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.

In response to my post about Camino and Firefox, Simon and Smokey Ardisson sent along the following:

• AsceticBar by (who else?) Jon Hicks Stuart Morgan removes all the icons in Camino’s Bookmarks bar without killing them off in the actual Bookmarks menu.  Exactly what I wanted.  Thanks to Smokey for pointing it out, and Hicksy Stuart for writing it!

• A Firefox extension that fixes its last-tab behavior in OS X when “always show tab bar” is turned on.  This was contributed by Simon in a comment on Bugzilla bug 348031, and once I installed it, I found Firefox much easier to tolerate.  I hope that this gets permanently fixed in a future version of Firefox, but until that happens, we’ve got the extension to paper over the problem.

My heartfelt thanks to both gentlemen for their pointers and efforts!

• Browsers Boosted was published on Monday, September 17th, 2007.
• It was assigned to the Browsers category.
• There have been two replies.

A while back, I got fed up with the memory leaks of Safari, but found Firefox to be a bit too poky for everyday browsing.  Also, I can’t even find words to describe my seething hatred of Firefox’s insistence on keeping a blank window open when I close the last tab in said window.

So I started using Camino as my default surfing browser.  Firefox is still my web development environment, of course; I just seethe for a moment when a blank window occurs and then keep going.  Life in Camino has been a mostly positive experience, but there are a few things that really irk me.  I’m wondering if the (Lazy)web can help me fix them.  To wit:

• The form autofill routines latched on to some early mistakes of mine, and now just will not let go (for example, my name gets filled into the e-mail field and vice versa when commenting on WordPress blogs).  I want to fix this.  Where do I find that information?

• Safari has an autofill feature I really like, which is that it remembers every input ever made for a given field on a given page, and uses them for autocompletion.  For example, it remembers every blog post title I’ve ever input through it, which helps me avoid duplicates.  Is there a way to get or add something similar for Camino?

• Is there a way to turn off all favicons, including the default green diagonal bookmark, in the Bookmarks bar, but leave them in the Bookmarks menu?  All I can find is browser.chrome.favicons, which seems to kill all favicons everywhere, and doesn’t seem to turn off the green guys (unless I did something wrong).

Camino hasn’t been all pain, certainly.  I absolutely love its state restoration feature, for one.  And once I got into about:config and flipped a few settings (such as disabling “Delete” as a back button equivalent), and ran the shell command to get inline URL autocompletion (as documented most of the way down this “Hidden Preferences” page), I was much more satisfied with my Camino experience.  I’d just like to get it the rest of the way there, if I can.

• Tweaking Camino was published on Friday, September 7th, 2007.
• It was assigned to the Browsers category.
• There have been thirty-two replies.

While kicking around some ideas at the CSS workshop I led in London, I ran into some interesting problems with :empty.  If you’re not up on what that one does, it’s a way of selecting elements that have no children, including text.  To quote the formal definition:

The :empty pseudo-class represents an element that has no children at all. In terms of the DOM, only element nodes and text nodes (including CDATA nodes and entity references) whose data has a non-zero length must be considered as affecting emptiness; comments, PIs, and other nodes must not affect whether an element is considered empty or not.

So kindly consider:

*:empty {
   padding: 0.25em;
   outline: 1px dashed red;
   background: yellow;
}

We (re)discovered something very strange right there in the workshop: given the preceding rule, Firefox applies it to the body element—which is, quite clearly, not empty.  You can check out the fun on my bare *:empty test page.  From there, we realized that if you prepend a body to the selector, yielding body *:empty, the problem vanishes, as you might expect.

As it turns out, this is a known bug in Gecko.  It’s been known for about 18 months, in fact.  So that’s why I was confused by Firefox’s behavior.

The other problem is that :empty in Firefox matches img elements, whether or not they cause an image to successfully load.  You can see this happen on the same test page.  While it’s true that img is an empty element, it’s still bringing in content, so from a common-sense point of view it seems that :empty ought not to match.

In re-reading the description from the specification, though, I can’t justify my common-sense interpretation—an img element has neither element nodes nor text nodes, so far as I’m aware.  The same is true for form inputs, even text inputs that have pre-filled value text; but not for textareas that have pre-filled content text.  But then br elements should also be selected by this rule, and they apparently don’t get matched at all, as the test page shows.  Bwuh?

Well, maybe it’s a bug.  What concerns me here is that the definition of :empty basically requires that things like images and inputs always be selected, which strikes me as kind of useless.  After all, if I wanted to select all images, I’d write img into my selector; ditto input for inputs.

My thinking is that the description should change to state that application of :empty is restricted to non-replaced elements.  Alternatively, it could be redefined to only apply non-replaced elements and to empty replaced elements that don’t either cause something to load or have values associated with them.

Which seems a better solution to you, and why?  Or, if you see a better approach than either of those, what is it?

• Running on :empty was published on Friday, August 17th, 2007.
• It was assigned to the Browsers and CSS categories.
• There have been twenty-three replies.