Posts in the Browsers Category

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.

“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.

• The Veteran’s Charge was published on Wednesday, August 8th, 2007.
• It was assigned to the Browsers, Rants, Standards, and Web categories.
• There have been eighty-nine replies.

Because the world needed another browser/platform combination to test, Apple has released a beta version of Safari for Windows.  Why?  Arguably, it’s to make sure that Windows developers have access to the browser in the iPhone, so they can make sure that their Web 2.0 sites work on the iPhone without having to buy new computers.  (Though this also robs them of the primary justification for getting an iPhone on the company dime.  Haven’t they suffered enough, Steve?)  On that note, I hope this new foray will expand the pool of people contributing ideas to Greg‘s post about cool new apps for the iPhone.  (There’s already a truly brilliant idea in there, albeit with a name I can’t use here due to readers behind content filters.  Who’s going to make it happen?)

It will also be interesting to see if the presence of another highly standards-compliant browser (joining Firefox and Opera) on the Windows platform spurs more Windows-based web developers to pressure Microsoft to maintain their momentum on the issue, so as not to see IE fall behind all the competitors.  As you might expect, I certainly hope so.

Remember: this is a beta!  There’s going to be weirdness.  PPK, for example, ran into layout problems that may or may not be related to the video card in one of his systems.  Other people are reporting crashes; though many of them are reporting crashes on CNN‘s site, which crashes my OS X copy of Safari from time to time.  Interesting to see that kind of cross-platform crash consistency.

The beta’s certainly worth checking out if you’re interested, but—as with the IE7 betas—do not start reworking your site to address layout problems in this beta.  Report them to the WebKit team instead.  When the final version (or a feature-frozen RC version) is released, it’ll be time for testing, charting, and possible reworking.

Interesting times indeed.  If you’ll excuse me, I have to go make some changes to my browser-release timeline slides.

• Windows Safari was published on Tuesday, June 12th, 2007.
• It was assigned to the Browsers category.
• There have been forty-three replies.

A week or so back, the shattered remains of a wasps’ nest appeared in our driveway.  Despite the fact that it’s clearly vacant—even wasps know when it’s time to find new digs—I still tread carefully whenever I walk past, avoiding them out of some latent respect for the threat they once contained.

You’d think I’d behave in a like manner in the rest of my life, but no.  For example: I recently spoke well of the IE team and their efforts.  Kind of an obvious goof, really, but I’d hoped for a different outcome.  It’s the incurable optimist in me.  And when I say “incurable”, I mean that in the sense of “disease that can’t be purged from my body and will no doubt one day kill me”.

While the enraged buzzing took many forms, the comment that seemed to distill the bulk of people’s anger was this:

“How am I supposed to trust a smiling face of some developer at Microsoft when the company as a whole was charged with being an illegal monopoly not too long ago?”

Because one is a person, and the other is a corporation.  I realize that American law moronically (and, in a certain sense, unlawfully) equates the two, but they really are distinct concepts.

You can dismiss my attitude as the biased perspective of someone who personally knows members of the IE team.  That would be a major miscalculation, because it’s those personal relationships that make my observations different than what you’ll find elsewhere.  Think what you will of Microsoft, but there are actual people working on IE, and they’re by and large people who care about the same things we care about.  They are part of this story.  If you think they’re minor nodes in a monolithic collective consciousness, then boy, do you ever have a lot to learn about how large organizations function.

Allow me to draw an analogy, if I may.  While at Mix 06, I was talking with one of the senior IE team folks about improving standards and the browser market.  He said to me, “So what is it the Web design community wants?”—as if there is a single such community, and it always speaks with a unified voice on all matters.  Does that sound like the Web design community you know?  Does that even sound like any arbitrary collection of five Web designers you know?  (Aside to WaSP steering committee members: feel free to take a ten-minute laughter break.)

So why do we assume that Microsoft, a company with tens of thousands of employees working in hundreds of teams and units, would be any more unified?  Sure, the PR department speaks with a single voice.  To take that as representative of every Microsoft engineer is like ceding all authority for your thoughts and opinions on Web development and design to the Web Standards Project.  Anyone volunteering for that?

Not me, thanks.  Not even when I was a member, back towards the end of the last millennium.

This is what I said to him, by the way, except I compared the Web community to Microsoft, with all its subunits and competing voices and priorities and goals.  He got what I was saying instantly, even though it let him down a bit.  His job would be easier, after all, if the Web design community were a unified collective.  It’s certainly less mental effort to think of “the other camp” as being a Borg-like hive, isn’t it?

A few people accused me of being lulled into missing the Great Looming Threat of Microsoft’s non-standards efforts.  For example:

“…Microsoft spent those years planning and building WPF, to lure Web developers into its proprietary and patent-protected embrace. And that should have you most concerned.”

Been there, done that, got the T-shirt, wore it threadbare, and repurposed it as a cleaning rag.  I was openly expressing precisely that concern back in October 2003, which as you may recall was near the middle of said years.  The aggregate response of the community was a disinterested shrug.  This was largely true whether I posted publicly or talked to people one on one, as I’d done in several cases in the months before October 2003.  The only place I found any similar concern was with some folks at Macromedia, thank you very much.  Everyone else seemed to think I was on crack.  So sorry, but I pretty much wore out my concern back then.  You can have it now.

Besides, over time I’ve come to see WPF (as it’s now called) as being very much like Flash, which it clearly wants to supplant.  Despite all these years of Flash being very widely installed, and all the years of Flash being able to do XML data exchange with servers to cause dynamic updating of pages—you know, like Ajax does—the Web has not become an enormous Flash application.

I thought the most interesting observation was this one:

“Dave Shea pointed out… a few months ago that one reason [for IE7] may be that Microsoft, in developing things like live.com, are finally having to eat their own dogfood, struggling to get things working on their own browser, and that as such there may have been internal pressure to get things up to scratch.”

That makes a certain amount of sense, though I’m not about to accept it as the sole reason for IE7’s development path or even its existence.  I think there were a whole lot of factors that drove IE7 into being, and standards support was honestly pretty far down on the list.  I, for one, am deeply grateful that the IE team seized on the opportunity to build better standards support into the browser, whatever the internal rationale they used to justify it to the higher-ups.

I’m also impressed with the CSS and other advances in IE7, and with how the IE team is managing the development process to accommodate the needs of Web developers and designers.  They didn’t have to do any of that.  After all the crap they’ve had dumped on them the last decade or more, they have every reason not to care about what’s best for the Web.  Despite this, they still do.  Recognize and respect that, if nothing else.

• Praise IE, Go to Jail was published on Friday, April 14th, 2006.
• It was assigned to the Browsers and Standards categories.
• There have been thirty-three replies.

Over on IEblog, Markus Mielke has a great IE7 post with screenshots of a CSS Zen Garden-inspired layout showing off fixed positioning, PNG alpha channels, arbitrary-element hover, and so much more.  There are those who have called for its inclusion into the Zen Garden, but as Dave points out, it would break in IE6 and so couldn’t qualify as an official design.  Oh, the irony.

Getting back to Markus’ post, he has this to say near the end:

…we are now layout complete with the release of the MIX build – we don’t plan to add more layout features or drastically change layout behavior. This gives web developers a chance to test and prepare your pages for Vista Beta2 and the final release of IE7.  There are still bugs and missing features (display tables, generated content to name a few) we would have liked to do for IE7 but based on your requests to have some lead time to test your pages we need to lock it down now to be able to ship IE7.

So there you go: no more CSS functionality will be added to IE7.  Anything that isn’t there, like CSS table properties and the like, will have to wait for a future version.  As has been publicly stated, though, we won’t have to wait five years for the next version.  There’s no solid guarantee of how long or short a wait there will be, but Bill Gates himself said that new versions would come out more frequently.  The IE team reiterated this.

So will current bugs in IE7’s CSS handling be fixed?  I give that a solid “maybe”.  Markus has left the door partway open by saying that there are no plans to make drastic changes to layout behavior.  That could mean that if a bug fix only causes minor changes, then it might get in.  On the other hand, it could mean that unless existing behavior causes massive problems (or crashes), no bug fixes will be taken until after IE7.  Personally, I wouldn’t count on it, but I’ve been wrong before.

Then, in the same post, Markus drops an entirely new bombshell:

The good news is that we are in the progress of building up a public bug database where you can submit your issues, track their progress and see when we internally fix an issue – Al is going to post about this soon.  Your participation will help us greatly to improve IE and also help us to prioritize what bugs to fix for the next releases.

Sweet fancy Moses—a Bugzilla for IE?  There was no mention of this within my earshot at Mix 06, so I’m as surprised as anyone else.  Did I fall down a rabbit hole and quaff a bottle labeled “DRINK ME”?  If this is a dream, I don’t ever want to wake up.

The Redmond-haters will claim that this is just a lot of catch-up, played years late, and amounts to little more than aping what Mozilla and other browser makers have been doing—better standards support, a tabbed interface, open bug databases, and so on.  It happens that they’re right, but what’s wrong with that?  The IE team has looked over what happened while they were in hibernation and is emulating the best of it.  That’s not lame, that’s smart.  And it should have other browser makers a little bit worried.  A lot of their success has been due to Microsoft’s complacency.  They’re going to have to be a lot sharper and more nimble now that the 800 pound gorilla is actually awake and paying attention to its surroundings.

No, I don’t think IE will wipe everyone else off the map, but I do think the browser space is getting a lot more interesting.  What makes it particularly interesting is that the competition is not going to be over who can add the coolest non-standard geegaws, but who can deliver the best product based on the same standards as everyone else.

I’ve wondered what that would be like ever since I got seriously into standards back in mid-1996.  I almost can’t believe that there’s a chance I’ll get to find out.

• IE7 Improvements and Bug Tracking was published on Thursday, March 23rd, 2006.
• It was assigned to the Browsers and Standards categories.
• There have been thirty-six replies.