meyerweb.com

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.

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.

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.

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.

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!

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.

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?

“This page best viewed in…”

If that phrase doesn’t provoke a shudder of horror and loathing, it should.  It’s the battle cry of the Browser Wars, those terrible and ultimately futile years at the end of the last milennium.  It’s the rallying cry of those who would take the open ubiquity of the web and fragment it into a collection of gated communities, where entrance to each is predicated on running a specific browser.

“Your browser is not compatible and must be upgraded…”

All too often, because developers are too fearful or prideful or just plain lazy, they put up unnecessary barriers to entrance.  They prevent people from using their sites based on choice of browser.  Of course there are situations where the experience will be different—nobody expects Netscape 4 users to be able to see all 2007′s pretty CSS effects, just like table-based sites look beyond bizarre in Mosaic.  That’s no excuse for sites that intentionally lock users out just because their choice of browser doesn’t line up with the developer’s expectations.  It’s regressive, short-sighted, and just plain unprofessional.

“This site is for iPhone users only.”

STOP IT.  Stop it right now.

The fact that optimizing pages for an iPhone makes the development of such specialized pages attractive in no way excuses lockout of other users.  I might be willing to entertain the argument if the iPhone’s browser were some specialized non-web contraption.  It’s not.  It’s a full-fledged XHTML+CSS+DOM browser that happens to lag a bit in some implementation areas and won’t run some plugins.

Besides, if you’ve developed a version of your site (or application or whatever) that works well on the iPhone, then why in the name of Tim Berners-Lee would you deny other people that optimized experience?  You might find that they prefer to interact with the site that way no matter what platform they’re using.  You might find that you don’t need a separate iPhone version after all.  The iPhoned version might be the only version you need.

Designers will argue that pages optimized for the iPhone screen will look bad on a desktop browser.  Maybe, and maybe not, but stop preventing your users from making that decision for themselves.  Nobody says you have to convert your whole site to be iPhoney.  But your lockout of non-iPhone users is worse than rude.  It’s stupid.

We finally learned, after much sweat and a fair number of tears, that “best viewed in” is a fool’s errand.  Are we so eager to rush back into that morass and fight the war all over again?

Please.  Just stop.