Tag Archives: WebKit

MathML+WebKit

If you’re the kind of person who likes to download WebKit nightly builds to tinker with emerging features (and who isn’t?), then you’ll be interested to try out MathML support which is now turned on by default.

MathML is supported server-side in several wiki platforms I regularly deal with (such as Confluence and MediaWiki), and it has always been an important requirement for support from my colleagues in the science community who do any kind of math research (but second place to LaTeX). This is the first time I’ve seen it supported in a major browser platform though. The mathematics community will be very interested in this sort of thing, and I expect at some point in the future we’ll just be embedding MathML into markup and publishing it rather than having to rely on a server-side library to parse it. Yea! 😀 I know it sounds more geeky than usual, but this is pretty cool in my book – especially from an applications perspective.

The only thing more geeky about downloading WebKit nightly builds is getting excited over new XML functionality. 🙂 Also slightly related: both SVG and HTML5 canvas will be supported in IE9, making it doable in all modern browsers when that finally gets released and older versions become rarely used. It will become an increasing trend to represent data in these formats, natively in markup, rather than relying on 3rd party server-side libraries or plugins. Standards eventually win, usually…

In defense of the vendor prefix

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.

RGBa and -webkit gradients: Yes.

When @malarkey asked if RGBa worked with -webkit gradients, my own curiosity couldn’t resist a quick and fugly test to see. Yes indeed, it works:


Screen shot showing green bleed-through on a -webkit gradient div

Waxing Firefox, Waning IE

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.

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.