When Can I Use has posted a nice browser usage table, which includes mobile browsers and a breakdown by browser version. Compared with the browser market share analysis at Wikipedia, the numbers do line up quite well for the major categories, although there are some interesting discrepancies when you get down into the weeds.

I love looking at statistics and seeing what jumps out at you. What I see from these numbers today, here in September of 2011, is this:

• IE is only 39% of browser market share now. Remember ten years ago? Yeah, times have changed.
• Chrome is doing quite well. It’s going to overtake Firefox at this rate. 21% – that’s amazing.
• Going by the When Can I Use analysis, if you combine Chrome, Safari, iOS, and Android, you have about 29% market share for WebKit browsers.
• If these trends continue, and I see every indication that they will, Google Chrome will become the dominant browser platform sometime in the first half of 2012.

Fascinating. I’m going to need to make more popcorn.

PPK has written a thoughtful post titled CSS vendor prefixes considered harmful, and in it he outlines the case of why browser vendors should cease use of the vendor prefix condition.

I sympathize with the case, but the very opening example we have a problem: border-radius. When varying corner values are involved, vendor implementation consistency breaks down:

-webkit-border-top-left-radius: 10px;
-webkit-border-top-right-radius: 30px;
-webkit-border-bottom-right-radius: 40px;
-webkit-border-bottom-left-radius: 20px;
-moz-border-radius-topleft: 10px;
-moz-border-radius-topright: 30px;
-moz-border-radius-bottomright: 40px;
-moz-border-radius-bottomleft: 20px;
border-top-left-radius: 10px;
border-top-right-radius: 30px;
border-bottom-right-radius: 40px;
border-bottom-left-radius: 20px;


I’d say vendor prefixes are an unfortunate but necessary construct until things are a bit more solidified – at the very least between browser vendors, and ultimately as written in a W3C recommendation.

What I think is important though is that developers do include the expected latest draft code of CSS3 at the end of their declaration blocks. Shipping code, both from the vendor perspective as well as the web developer perspective speaks volumes. If IE is going to drop vendor prefixes and is going with the latest draft examples, then good on ‘em.

IE continues it’s downward spiral as the browser dips below 69% at the expense of Firefox and the WebKit-powered duo of Apple Safari and Google Chrome. The breakdown as paraphrased by TG Daily:

Net Applications released updated global browser market share numbers today, indicating that IE is losing users at an accelerated pace. The browser’s share dropped from 69.77% in November to 68.15% in December. Most rivals were able to pick up a portion of what IE surrendered. Firefox gained more than half a point and ended up at 21.34%, Safari approaches the next big hurdle with 7.93% and Chrome came in at 1.04%, the first time Google was able to cross the 1% mark. Opera remained stable 0.71%, but it is clear that the Norwegian browser cannot attract any users IE loses.

This is no surprise. Taking into account the seasonal fluctuation towards home users in December which point to higher “non-corporate” platforms and browsers, this is still a landmark statistic and shows that if the gradual decline continues, 60% and 50% are not that far off in the future. As the trend for Firefox and WebKit to rise at the expense of IE has been continuing for some time now. What surprises me are a couple of things though, specifically:

1. The rate at which IE is losing overall market share: While I predicted a decline in market share over the long term, I didn’t think I’d ever see it declining at the rate it is currently declining on a month to month average. It just seems steep to me.
2. Opera adoption: I thought that more people would pick up Opera – at least I thought they’d have 2 or 3 percent by now. They are by far the most deployed browser on the mobile web, but nobody knows it really because they could care less what browser is being activated from their baked-up phone UI, and it’s unlikely that they use it much (which is the fault of the phone vendors – Opera Mobile by itself is great.) I like Opera. It’s not my default browsaer, but I find myself using it from time to time for certain things. Certainly for print and presentations, and also it’s handy mobile web dev in Small Screen mode.

I wonder how much of those Safari numbers are being driven from iPhone and iPod Touch users? What is also interesting in these metrics is the inclusion of Google’s Chrome browser, which again is based on the WebKit core that Safari is founded upon. Chrome broke 1%, and at the same time they have begun recommending against IE and in favor of Firefox and Chrome for Google Gmail users. This is an interesting coup attempt to grab their Gmail base still floundering on IE6, and it is even more noteworthy that IE7 was not mentioned as an alternative. I am betting Chrome will be a major contender a year from now, and the overall WebKit market share might even approach Firefox’s levels. What is probably safe to predict is that IE will continue to lose out to Firefox and WebKit-based browsers and I would not be surprised at this point if the rate of increase in adoption of alternative browsers began to accelerate in 2009 towards these platforms.

It is nice to see strong lines of diversity returning to the browser market. The benefit will be for better browsers and stronger support overall for web standards.

This evening as I was doing some research on mobile web development, I got myself on a tear about the wild differences we face as web developers regarding screen sizes and default browser installations, and came up with this:

*Some service providers will opt to use a different browser than the ones listed here.

It is interesting to note the diversity on these fronts. Screen sizes are all over the map, and the browsers here are not the usual suspects we see on the desktop. As for browsers, while it is certainly possible on many of these platforms to install a different browser (Opera being the usual choice), most users don’t bother. Regardless, Opera is the dominant player in this space, with significant marketshare owned by all the other actors on the mobile stage. As I research this topic, the WebKit engine proves to be the vast trendsetter and it is interesting to see how many platforms besides the iPhone are picking this one up. And trends show that this landscape is evolving rapidly as mobile capabilities increase and users begin surfing the web on their mobile devices with greater and greater frequency. ABI Research sees web browser installations on smartphones expanding from 130 million in 2008 to 530 million by 2013. The mobile web is a vastly unexplored frontier in web design and we should start seeing more and more attention getting paid to this aspect of the online world.

Update: Amazon Kindle’s Basic Web is based on NetFront – table updated to reflect this.

As I was working through some documentation on styling CSS for print recently, I came across an oddity. Colors that I was specifying in my print styles were not getting represented properly at print time. Specify a nice shade of gray for some text? Maybe want to ghost print something very lightly on the printed page. No – not in Firefox. In fact, any shade of gray comes out as black in Gecko browsers. This behavior is only slightly more intelligent in Safari and IE7, but in all cases the user agent makes an assumption about what color of text constitutes being “too light” and then defaults to a darker shade of pale that is handled inconsistently across the various browsers. Printing font colors appears to be a messy situation.

Now the reason why the browser vendors have made this assumption is clear: Printing light text on what is almost always white paper is largely unreadable. Furthermore, printing in pure black, devoid of any complex color mixing, can make printing much faster, because the printer doesn’t have to mix in any red, green, or blue ink and can focus on getting the task done. But what is maddening to the designer trying to achieve accurate color representation in print from their web pages is that all of the major browsers assume that they are smarter than the designer, and recolor the text based on their own inconsistent algorithms. Actually, that may be assuming a bit much on the part of the browsers – sometimes the results defy logic.

To investigate further, I created a testing page. This page runs through some of the various color gamuts and creates a list entry for a number of color variations. The results are surprising… Here are some findings:

• Safari 3: Between rgb(0,0,0) and rgb(107,107,107), things appear fine. But then there is a breakdown between rgb(108,108,108) and rgb(127,127,127) where the text will randomly jump to a light gray – equivalent of rgb(199,199,199). For lack of a better term, I call this area “The Dead Zone,” and we will see it again soon. At rgb(128,128,128), the text color then jumps to black and as you ascend the values towards an expected white color, Safari yields a progressive amount of additional lightness to the text until it finally winds up at around rgb(171,171,171) where it should be 255 for all values.

  The Dead Zone also occurs in the red, green, and blue colorspaces. If you fix red at 127, about halfway between the minimum value of 0 and the maximum value of 255, we get a dead zone between rgb(127,100,100) and rgb(127,127,127). Same ratios happen starting at rgb(100,127,100), and at rgb(100,100,127).

  Finally, Safari renders rgb(0,255,255), rgb(255,0,255), and rgb(255,255,0) inconsistently from their adjacent color values.

• Gecko browsers such as Firefox, Camino, and Flock print the entire gray space in black. (Exception: Firefox 3 will actually print the color exactly right – see below.) You cannot specify a light gray such as rgb(127,127,127) or anything else. It will always default to pure black whether you like it or not. If you fix a color bucket at 0, you will get semi-accurate color for the rest of the gamut, but the other color combinations will trend towards black text the lighter it gets.

• In Opera 9, gray shades render accurately up until rgb(185,185,185), and then higher values default to black. In the points tested, the same conversion to black happens after values higher than rgb(127,211,211), rgb(255,156,156), rgb(87,255,255), rgb(209,209,0), rgb(193,193,127), and rgb(177,177,255).

• IE7 never gets any lighter than rgb(108,104,102) for grayscale, and the rest of the color spaces don’t seem to allow anything lighter than a midrange hue equivalent to around 110 for any given value.

• One last thing about Gecko browsers: The marker (the little bullet to the left of each list item) will display the correct color value in print, even though the text itself won’t match! Underlines/Overlines/strikethrough will match whatever color the text is though. So at least here you can see what the color was supposed to be…

• The exception as mentioned above is Firefox 3. Firefox 3 has been tested to print the colors exactly as you see them on screen, and is the only browser thus far that works this way in a predictable manner.

The conclusion I draw from all of this is that color in CSS print typography is woefully inconsistent, and I do recommend defaulting to black text in most cases simply because it is so problematic to predict what color you will actually wind up with in print. If you need color, go with a darker shade and test your print output in the four major modern browsers (IE, Safari, Firefox, Opera) to see what you can get away with.

Please feel free to try the test suite for yourself and let me know your findings in the comments or via a pingback.

Downloaded Firefox Three Point Oh this evening and I must say I’m impressed. Last check was a few beta revisions ago, and this is much improved in the one area I am most concerned with: stability. I have been running it all evening and she’s been perfectly stable so far.

PPK has posted a quick roundup of the current browser state of affairs today. Seems we have beta 2 of IE8 due out in August, which is good because I don’t want to deal with it until then. Of course Firefox 3 is out and looking fabulous, and a Firefox 3.1 alpha is now available with alleged full CSS3 selector support. Safari 4 is a developer preview, and Opera 9.5 is already live.

So the great news is, things are not stagnant – things are moving forward at a lovely clip. IE6 is soon to be ancient history – two revisions old – and the rest of the browser market is vibrant and embracing standards and innovating on coolness all around.

Gruber has noted that when you hit the Firefox 3 page you get a comparison with Safari if you’re on Mac, and other users seem to be getting the IE to FF comparison.

Most of my essential plugins are working great. There is a Firebug 1.1 beta available on the releases page if you’re missing that. ScribeFire and the del.icio.us plugins seem to be fine and really the del.icio.us plugin wins in the most improved category. Still no HTML Validator yet for Mac, but I’ll be watching the skies on that one…

OK back to to practicing…

Thanks to @mrsnap and @bikracer for turning me on to Flock. It seems to like my favorite web developer extensions, namely the Web Developer Toolbar and Firebug, and the social network features are a bonus. I was getting bummed out by Firefox’s incessant crashing, and this browser seems faster, more stable, and has some really interesting features. The user interface is a bit cluttered, although I’m doing it no favors by adding so much cruft on top of it, but other than that it seems pretty fun to use so far.