The madness of screens vs. browsers on the mobile web

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:

Make Model Resolution Default Browser Engine*
Amazon Kindle 600 x 800 NetFront
Apple iPhone 480 x 320 WebKit
Apple iPod Touch 480 x 320 WebKit
BenQ M315 128 x 128 Opera
HTC G1 320 x 480 WebKit
Kyocera Mako S4000 128 x 160 Openwave
Motorola Hint QA30 320 x 240 Openwave
Motorola Krave ZN4 240 x 400 Openwave
Motorola KRZR K1 176 x 220 Opera
Motorola RAZR V3 176 x 220 Opera
Motorola ROKR E2 240 x 320 Opera
Motorola SLVR L7 176 x 220 Opera
Motorola V980 176 x 220 Opera
Motorola VE240 128 x 128 Openwave
Motorola ZINE ZN5 240 x 320 WebKit
Nokia 6300 240 x 320 Opera
Nokia 2605 Mirage 128 x 160 Openwave
Nokia N81 240 x 320 WebKit
Nokia N810 800 x 480 Gecko
Nokia N82 240 x 320 WebKit
Nokia N95 240 x 320 WebKit
Nokia N96 240 x 320 WebKit
Palm Centro 320 x 320 NetFront
Palm Treo 680 320 x 320 NetFront
Palm Treo 750 240 x 240 Internet Explorer
Palm Treo 755p 320 x 320 NetFront
Palm Treo 800w 320 x 320 Internet Explorer
Palm Treo Pro 320 x 320 Internet Explorer
RIM Blackberry Bold 480 x 360 Blackberry Browser
RIM Blackberry Pearl 240 x 320 Blackberry Browser
RIM Blackberry Storm 480 x 360 Blackberry Browser
Samsung Behold T919 240 x 400 NetFront
Samsung BlackJack SGH-i607 240 x 320 Internet Explorer
Samsung Epix i907 320 x 320 Internet Explorer
Samsung Eternity SGH-A867 240 x 400 Openwave
Samsung Highnote M630 176 x 220 Polaris
Samsung Omina i910 240 x 400 Internet Explorer & Opera
Samsung Rant M540 176 x 220 Polaris
Samsung Rugby A837 176 x 220 NetFront
Samsung Saga i770 320 x 320 Internet Explorer & Opera
Samsung SPH-Z400 176 x 220 Obigo
Siemens SX66 240 x 320 Internet Explorer
Sonim XP3 128 x 160 Opera
Sony Ericsson C702a 240 x 320 NetFront
Sony Ericsson C905a 240 x 320 NetFront
Sony Ericsson TM506 240 x 320 NetFront
Sony Ericsson W595a 240 x 320 NetFront
Sony Ericsson W760 240 x 320 NetFront
Sony Ericsson X1 800 X 480 Internet Explorer & Opera

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

The woes of CSS color in print typography

Smoking Room/Prayer Room

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.