The Browsers of 2009

January 31st, 2008

In a follow-up to this question I've begun pondering what the most-relevant browsers of 2009 will be. I tend to determine relevance by the question "Is this browser cost beneficial to us supporting it" being answered by a significant number of developers and corporations.

For example, I would probably rate the current, 2008, list as follows (in order of cost-benefit):

• IE 6
• IE 7
• Firefox 2
• Safari 2 & Safari 3 (tie)
• -- common cut-off point --
• IE 5.5
• Opera 9.2

Starting in 2009 I predict that the list will be similar to the following:

• IE 7
• IE 6
• Firefox 3
• Safari 3
• -- common cut-off point --
• Opera 9.5

Not a whole lot changed, but a couple points to consider:

• I wouldn't be surprised if the switch between the dominance of IE 6 and IE 7 finally occurred.
• Firefox 3 will probably be released late spring/early summer - thankfully uptake will be fast (as it has, generally, been with past versions).
• Safari 3 is already shooting way up, Safari 2 will be a thing of the past come 2009.
• Opera will definitely have 9.5 out by then - maybe 10? Although, even if 10 is out, it definitely won't have a market share by next January.
• IE 5.5 will definitely squeeze out it's last remaining % into cost-benefit obscurity.

What's interesting about analyzing the cost-benefit of a browser is that it's done completely differently from straight-up analysis of browser market share. It's really a combination of market share and time that'll be spent customizing your application to work in that browser. Here's a quick chart to represent my choices:

The "Cost" is represented by the % of time that will be spent, beyond normal application development, spent exclusively with that browser. The "Benefit" is the % of market share that the browser has. Note that any browser that has a higher cost, than benefit, needs to be seriously considered for development.

What's interesting about this is that it use to be much-more clear-cut when choosing to develop for IE 6 - it had 80-90% market share so it's benefit was always considerably higher (or, at least, equal to) the time spent making it work in that browser. However, in 2009, that percentage will be considerably less (I'm estimating 35%, to IE 7's 45%) making it far less attractive as a platform. Note that Firefox and Safari, due to their less-buggy nature (and standards compliance) always have a higher benefit than cost, making them an easy target to work towards. Opera is problematic, however. It's, continued, low market share makes it a challenging platform to justify. It's for this reason that major frameworks, like Prototype, have ignored working with Opera up until this point - and understandably so.

Now it's not always a one-to-one trade-off in-between cost and benefit. I think it would even be safe to say that benefit is, at least, twice as important as cost. Ultimately, however, this depends upon the choices of those involved in the decision making and the skill of the developers working on the compliance. Is an extra 4-5% market share from Safari 3 worth 4-5 developer days? What about the added overhead to Quality Assurance and testing? It's never an easy problem - but it's one that we can, certainly, all get better at over time - but really only through hard work and experience.

Tags: browsers

48 Comments on 'The Browsers of 2009'

HTML5 DOCTYPE

January 23rd, 2008

Remember the whole crazy Internet Explorer 8 meta http-equiv hub-bub, yesterday? There was one post in all of that mess that was really, really, important.

To sum it up: Internet Explorer 8 will support DOCTYPE switching for new DOCTYPEs (like HTML5).

“Steve”: Are there any doctypes that do not require this new meta tag to render with the IE8 rendering engine?

Chris Wilson: @Steve - sure. Any unknown (i.e. not widely deployed) DOCTYPE. HTML5, for example.

This really does change any frustration that someone should have concerning the new meta tag. This means that you can write your web pages in a completely standards-based way (CSS, HTML5, JavaScript) and not have to use a single browser-centric tag in order to do so.

For those of you who aren't familiar with the HTML5 DOCTYPE, it looks like this:

<!DOCTYPE html>

You'll note that it's significantly simpler than most DOCTYPEs that you've seen - and that was intentional. A lot has changed in HTML5 in an attempt to make it even easier to develop a standards-based web page, and it should really pay off in the end.

What's nice about this new DOCTYPE, especially, is that all current browsers (IE, FF, Opera, Safari) will look at it and switch the content into standards mode - even though they don't implement HTML5. This means that you could start writing your web pages using HTML5 today and have them last for a very, very, long time.

If nothing else, this should be a good excuse to look through the changes in HTML5 and familiarize yourself with what's in the pipeline for browsers - Internet Explorer included.

I really, really, wish this was made clear yesterday - it would've avoided a whole lot of pain and suffering on the part of the Microsoft Task Force of WaSP and of the Internet Explorer team as a whole. I'm really glad that this is happening, though - the future of standards-based web development still looks quite bright.

Tags: html5, browsers

34 Comments on 'HTML5 DOCTYPE'

Meta Madness

January 22nd, 2008

Wanna know how I can tell that no other browser vendor participated in the creation of the new meta X-UA-Compatible tag? Because it's completely worthless - and in fact harmful - for any browser to implement!

I love this example from the overview article, including Firefox 3 as an example:

What seems to have slipped past the Microsoft Task Force of WaSP (or maybe it didn't and they're just playing coy) is that by implementing this specific feature in any other browser immediately either: A) Reduces its market size of viable web pages that will upgrade to new versions of the browser or B) Forces new versions of the browser to bloat, including backwards support for old-style rendering.

The fundamental issue is that Safari, Firefox, and Opera will all be harmed by attempting to implement this. Anne, from Opera, completely agrees. So, with that in mind, why even the attempt at making this sound like a "generally beneficial standardization issue"? Why go through the song-and-dance? Because if it was called:

then developers would surely, excuse me, shit the bed in frustration over being forced to add markup just to make their web applications render in a standards compliant manner. The comments on the article definitely indicate some level of this occurring already. However, the pretense of cooperation and generally applicability needs to be dropped. It doesn't exist, it's a complete lie, and any indication of general use is a sham. Call it for what it is: A shiv for jamming standards support into future versions of Internet Explorer.

JavaScript and X-UA-Compatible

With that rant out of the way, how will this new meta tag addition effect JavaScript and DOM support in future versions of Internet Explorer? That's the weird part - no one completely knows. Let's look at some randomly-picked issues that are sure to cause a world of fun in the future.

Cross-document issues

Let's say you have a page that's in IE7 mode and an iframe pointing to a page that's in IE8 mode (or vice versa) - and now you communicate across the frames. Now let's assume, for fun, that IE8 also support JavaScript getters and setters.

What happens when you bleed functionality across frames? Or even if you were to try and access functionality that doesn't exist in your engine from another? Who knows! This is positively frightening both from an implementation and user perspective.

Another random item: What happens when you use importNode across iframes that have different DOM versions?

Robert O'Callahan, Mozilla developer, has two blog posts on the subject that are both quite good.

Script Versioning

Up until this point, if we wanted to pick a different version of JavaScript to use we would do something like the following:

This works well in browsers that support it. However, with this new meta tag addition, Internet Explorer is pegging JavaScript versions to versions of their rendering engine. This means that (theoretically) if you wanted JavaScript 1.5 support you'd have to, also, be content with bad CSS support. If you wanted to upgrade to a new version of the scripting engine you'd also have to upgrade your CSS and markup as well. This is completely throwing out any sort of versioning system that already exists for JavaScript and forces users to use this new, inferior, system instead. How completely frustrating.

What I also find interesting is that, previously, Chris Wilson was concerned about implementing multiple versions of a JavaScript engine in order to maintain backwards compatibility. What they're doing now is, effectively, forcing themselves to have multiple JavaScript engines. So either they're gearing up to support JavaScript 2 or they've just lost one of their major qualms with the upcoming specification.

Minor Versions and Security Fixes

A final point that doesn't seem to be accounted for, at all, is the inclusion (or exclusion) of minor browser versions (including things like security patches). Internet Explorer hot patches have been known to cause problems in the past with web page functionality and rendering. However, since there's no way to specify which patches you "like" in this new meta tag scheme you're forced to consume them all.

The end result will be one in which: A) You're either constantly dodging mistaken bullets from the Internet Explorer team as the push out new releases or B) They're not going to do as many, if any at all, updates to the browser out of fear of breaking backwards compatibility. Honestly, I assume that B is far more likely, therefore you can be excited about looking forward to future, static, bug-laden releases of IE in the years to come!

On a whole, I really wish that this process had been done more in the open than it was. I doubt that as many issues, that we're seeing now, would've arrived. I absolutely don't envy Internet Explorer's situation in the matter so, for the sake of the web, let's hope they come up with an acceptable solution.

Tags: javascript, browsers, rendering

40 Comments on 'Meta Madness'

Sub-Pixel Problems in CSS

January 22nd, 2008

Something that jumped at me, recently, was a rendering dilemma that browsers have to encounter, and gracefully handle, on a day-by-day basis with little, to no, standardization.

Take the following page for example. You have 4 floated divs, each with a width of 25%, contained within a parent div of width 50px. Here's the question: How wide are each of the divs?

The problem lies in the fact that each div should be, approximately, 12.5px wide and since technology isn't at a level where we can start rendering at the sub-pixel level we tend to have to round off the number. The problem then becomes: Which way do you round the number? Up, down, or a mixture of the two? I think the results will surprise you, as they did me.

Opera 9

Safari 3

IE 6

IE 7

Firefox 3

Firefox 2

We have three completely different camps here:

• Round the numbers down - Both Opera and Safari round down the widths of all the divs to 12px. This leaves a 2px gap (note the green) to the right of all the divs. If you've ever wondered why your nicely-aligned navigation doesn't fill up the full contents of a container in these browsers, now you know why. On the plus side, at least you know what the width of these containers will all be the same, no matter what.
• Round the numbers up - Both Internet Explorer 6 and 7 round the widths of all the divs up to 13px. Doing this causes the floated divs to immediately wrap, breaking layouts. This is obviously wrong as it causes many safely-numbered layouts to break for no obvious reason.
• Round some numbers up and some down - Both Firefox 2 and 3 mix the rounding of the div widths to 12px and 13px. The mix of rounding is done as to provide an even result at the end (making it flush with the far edge). The obvious side effect is that the divs no longer have a consistent width to them (even though an equal width was specified by the CSS). Additionally, the reported (via a JavaScript computed style call, like offsetWidth) width of the element remains at its reported 12.5px not providing the user with any indication of which way the rounding is occurring. And to add another confusing wrench in the works: The order of which divs have a width of 13px or 12px has been flip-flopped in Firefox 3. This was done to improve efficiency and speed and seemingly little, to no, effect on general web site rendering.

I was talking this over with some Mozilla developers and David Baron explained the situation quite well:

We're trying to meet a bunch of constraints that can't all be satisfied at the same time (the proof is left as an exercise to the reader, though I may have actually written it out once in a Bugzilla comment):

1. 4 adjacent objects of width/height 25% (for example) starting at one edge of a container should end exactly at the other edge; there should never be an extra pixel in the container and they should never be wrapped due to being a pixel to wide

2. objects that are logically adjacent should always touch visually; there should never be a pixel gap or a pixel of overlap due to rounding error

3. objects given the same width should occupy the same number of pixels

4. object boundaries should always (visually) be aliased to a specific pixel boundary in the display (they should never be blurred)

The one [Mozilla] sacrifices is typically (3), except for borders where we sacrifice (1) by rounding the widths to pixel boundaries much earlier.

The especially strange part, in all of this, is that there's really no right, or wrong, here. How this behavior is supposed to play out by the rendering engine isn't dictated by the CSS specification, having it be left up to the implementation to render as it sees fit. Obviously the four guidelines outlined by David, above, could serve browsers well but they are forced to sacrifice at least one of them in order to meet most of them.

The whole situation is quite fuzzy and frustrating - I'm not sure what the best action is, moving forward, but at the very least it's in the open now where we can think about it some more.

Tags: rendering, browsers, css

50 Comments on 'Sub-Pixel Problems in CSS'

Will Memory Leaks Matter in 2009?

January 13th, 2008

Looking ahead a little bit: At the start of 2009, will JavaScript-based memory leaks still be relevant? Will onunload event handler cleanups still be required?

The largest offender has been Internet Explorer 6. Its market share is waning. Serious updates are being force-pushed to help old users. Internet Explorer 8 (beta?) will probably be out before the end of the year.

I'm fully willing to submit that they'll be around for a long time, in one form or another - but just how long? One year? Two? Three? IE 5 is at < 2% and no major JavaScript library supports it. I suspect that we might have to wait until that level before people start to chop off IE6-with-JScript-5.6 support.

Think about it: A year ago the world of Safari was pretty grim, but they gave us Safari 3 and it helped to clear things up significantly. Right now timers can be frustrating in Firefox 2, but Firefox 3 is giving some serious love to clean things up. It definitely appears as if the IE team is becoming serious about moving forward, so what can we expect here?

As I start working on my next book I have to ask questions like this. If I write about memory leaks will it even matter by the time the book is published? (Not saying that the book won't happen until 2009, but that's probably when it'll be on most bookshelves.) Memory management will always be an issue, but memory leaks (as we know them) are surely doomed - it's just the time frame that is unclear. Regardless, I think there should probably be a web-only article on memory leaks, I'm just not convinced that it should be in the book, proper.

Tags: javascript, browsers

11 Comments on 'Will Memory Leaks Matter in 2009?'

Analyzing Timer Performance

December 18th, 2007

A big push of Firefox 3 has been to improve its overall performance (memory, speed, ui responsiveness, JavaScript, etc.). One thing that I wanted to see get a little love was the performance of timers (setTimeout and setInterval). However, in order to make my case, I had to do some analysis.

I built a super-simple test case: Moving a div, one pixel at a time, 100 pixels. I did this using setTimeout, setInterval, and using Mozilla's internal nsITimer interface. I wanted to try and get an accurate reading on a couple things:

1. How long of a delay is there between timer calls?
2. How much fluctuation is there on timer calls?
3. How well do multiple simultaneous timers scale?
4. What is the minimum delay achievable with a timer?

Test Case:

• View test case (defaults to setInterval, 0ms timeout)
• Download the test case code

All charts were rendered using the jQuery chart plugin, Flot.

The Results (OSX):

Key: The horizontal axis is the recursion depth of the timer call, vertical axis is the actual delay between the timer calls - in milliseconds, and the line numbers correspond to the number of simultaneous timers being called.

The graphs are organized as such: (From top left, going clockwise) Firefox 2, Safari 3, Opera 9, Firefox 3.

setTimeout: 0ms delay, 10ms delay, 20ms delay

setInterval: 0ms delay, 10ms delay, 20ms delay

nsITimer: 0ms delay, 10ms delay, 20ms delay

Modified Firefox 3: Now, after having run all of those tests, I went through and commented out the timer filtering code in Firefox to see what the results would be. View full results (from left-to-right, nsITimer, setInterval, setTimeout, top-to-bottom 0ms, 10ms, 20ms delays).

Conclusions (OSX-only)

• WebKit's timer code is the thing of dreams. Their results are as smooth as a baby's bottom. Simply incredible.
• Opera is really messy - all over the place in its tests.
• Firefox 2 is generally pretty stabilized, but has nasty spikes in delay (from where the garbage collector kicks in).
• Firefox 3 has less nasty, long, delays - but has weird dips down to 0-2ms (this should probably be looked into).
• Firefox 2, Opera, and Safari all have a bottom window of 10ms for delays - Firefox 3 is now 15ms, for some reason (this should probably be looked into).
• Once you start moving into the range of 64-128 simultaneous timers, you're pretty much out of luck in most browsers.
• nsITimer can't be beat (for speed) with 1-2 simultaneous timers.
• There's something really wrong with nsITimer in Firefox 3.
• Removing the timer filtering code (in Firefox 3) reveals that there's a significant amount of timer logic located in the DOM code - as opposed to the pure timer code.

As noted above, these tests were run on OSX only. If anyone is interested in producing some results from Internet Explorer, Firefox 2, Firefox 3, and Opera, you're welcome to it. In the meantime, Vlad produced some basic results from Firefox 3 on Windows XP (setTimeout, setInterval, and nsITimer). Note how different they look from the OSX results. It may be a safe bet that some of the above results, and conclusions, may be localized to just the OSX platform.

I'm hoping to spawn some discussion from this, to better figure out which of these issues are actually bugs and need to be resolved (in particular, in Firefox 3). Don't worry, Webkit team, you guys are completely off-the-hook.

Tags: javascript, browsers

11 Comments on 'Analyzing Timer Performance'

Bad Background Browser

December 11th, 2007

The other day I caught this humorous image posted to Reddit, showing a Firefox update dialog popping up over a weather satellite image, live on TV:

I was amused, so I posted it to one of Mozilla's internal mailing lists - which started a renewed flurry of discussion surrounding the update manager. To start with, a bug was filed on this specific issue: don't prompt for software update unless firefox is the foreground application. Second, it was pointed out that a particular fix has already landed in Firefox 3, related to this issue: Software update dialog steals focus / wait for idle before prompting. Obviously, that's a good thing, but only the first step. So in addition to not prompting when the dialog is in the background we now, additionally, have the following bugs which are desired to be resolved:

• to reduce "update fatigue" don't prompt users at all unless they haven't restarted in 48 hours
• silent mode for auto update
• by default, don't prompt users when minor update is downloaded and ready to be installed, just apply on restart
• don't show restart now or later dialog after automatic background download
• make upgrade process smoother and avoid confusing/modal dialogs

Needless to say, this particular issue, while haphazardly amusing, will no longer be a problem in Firefox 3.

One thing that I find to be particularly interesting about this whole situation: The easier, and less painful, it is for a user to upgrade minor releases of Firefox, the more secure the browser is. (If a fix is released for a security problem and the user opts to not upgrade, they choose to remain vulnerable - which is a very bad thing.) Thus, anything that can be done to improve the quality of upgrading is considered to be a security enhancement. Security through improved user experience! I like it.

Tags: mozilla, firefox, browsers, security

10 Comments on 'Bad Background Browser'

Why Firefox 2.0.0.11 Happened So Fast

December 1st, 2007

Prologue: drawImage with broken PNG draws random memory

Prior to the release of Firefox 2.0.0.10 a minor security issue was discovered in the drawImage method in the Canvas API. This particular method takes an image (in the form of an IMG DOM Element), extracts the image data, and puts it into the Canvas at the desired points. If you're interested in seeing what this method does (and aren't running 2.0.0.10) then visit the Mozilla developer demo. The issue was that if the image was corrupted in some way, drawImage would still try to read data from it and display random bits of memory instead (oops).

This was fixed and two attachments were uploaded resolving this bug. However, that's where the issue came in. When it came time to commit the changes, only the first patch landed (by mistake) which caused drawImage to become all wonky. Coupled by the fact that there wasn't an immediate regression test in place to notice the obvious error. (That being said, we're getting much better - going from very few automated tests about a year ago, to tens of thousands now.)

Nov. 26: Firefox 2.0.0.10 is released, Canvas.drawImage method is not working

Canvas users (both web applications and Firefox extensions) start to notice the following error pop up:

uncaught exception: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDOMCanvasRenderingContext2D.drawImage]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: drawImage.html :: anonymous :: line 12" data: no]

The obvious bug is spotted and the patch is landed. The question then became: How serious is this? In a nutshell: Very serious. A number of critical applications were using this functionality to draw parts of their UIs and having this fail made them unusable. Thus, the new question was: How fast can we get it out? The answer:

Nov. 29: Firefox 2.0.0.11 is released, fastest turnaround for a browser, yet.

So that's why you're seeing two browser updates in one week. It was a big mistake, but thankfully it was caught quickly, fixed quickly, and released quickly. And in the end, it'll be a good thing, as I'm sure it'll get some more regression tests landed in the suite.

Tags: security, firefox, browsers

11 Comments on 'Why Firefox 2.0.0.11 Happened So Fast'