Hurley's World

Yesterday I was visited by a browser tester’s worst nightmare: when testing BlackBerry WebKit I found I made a mistake in my touch event research. I have to re-do all these tests in all browsers because my current results don’t take one variable into account.

That variable is preventing the event default. While writing my test page I left out the return false at the end of the test event handler, simply because I didn’t think of including it. The test results seemed fine, so I didn’t notice the mistake for months and months. (Meanwhile I added a setting for preventing the default.)

Last week I received a BlackBerry Torch (9800) which runs the brand-new and long-expected BlackBerry WebKit browser. I put it through all the motions, but quickly found out that the touchmove event didn’t work as expected. In my test page it fired only once, but the scrolling layer example worked fine, even though it depends on an continuous stream of touchmove events.

Fortunately the browser people at RIM are very helpful. When I sent out a plea for help I got an extremely useful reply within hours: BlackBerry WebKit fires only one touchmove event if the event’s default (scrolling the page) is not prevented.

I hurriedly added a return false and lo and behold: the generic test script reported dozens of touchmove events. In addition, it did not report any mouse events any more.

When I did the new test in other browsers it turned out that some of them, too, suppressed mouse events. I’m certain about the iPhone, and I’ve seen the behaviour elsewhere, too. However, I need to fully describe all browsers’ behaviour both with and without default prevention. Hence the need for re-tests.

That means that my BlackBerry WebKit report will be delayed: I don’t have all the data available yet. Suffice it to say for now that it’s an excellent browser, supporting every single mobile feature I currently test for.

BlackBerry WebKit scores perfectly in the viewport tests, with the single exception of screenX/Y event coordinates. That’s enough to put it in the top spot in this series of tests, relegating the iPhone (3.1) to place #2 and Symbian WebKit to #3.

In addition the browser has good documentation; and that’s something the other browser vendors can learn from.

BB WebKit’s performance can still use some work; it’s slightly slower than the other top browsers when it comes to dragging layers, repainting the page after a zoom, and similar processor-intensive jobs. I assume RIM is aware of these problems and is working on them.

Incidentally, performance is the reason BB WebKit is so strict in not firing more than one touchmove event without default prevention. It turns out that a natural touchmove action (dragging your finger across the screen) not only scrolls the page, but also any iframe or div with overflow: auto in the page. Other browsers have not implemented this universal scrolling; probably because of performance worries.

In any case, BB WebKit deliberately restricts the number of touchmove events if the web developer doesn’t clearly state it wants to take over the interface by returning false to suppress natural scrolling. If the browser had to handle a lot of touchmove events in addition to natural scrolling it would become too slow.

That’s understandable, and it’s possible that other browsers do something similar. None of them restrict the touchmove events to only one, but it may be they fire more touchmove events when the default is prevented. That’s one of the things I have to test.

Anyway, I made a mistake, and now I have to pay for it by retesting the event cascade in all browsers. Such is a browser tester’s life.

Over the weekend I created a mobile market overview in the form of a sortable table. I hope it gives you some insights; it certainly did for me.

For a complete overview knowledge of the current market share stats is necessary; fortunately Tomi Ahonen provides the latest. My table doesn’t yet contains these stats; I still have to figure out exactly how to display them (not to mention making time to implement a new feature).

Anyway, take a look and let me know what you think. And if you have some extra facts, please provide them.

I have updated the mobile browser page. It now contains 18 browsers, and in addition I added some lists about which browser runs on which OS, and which device vendor uses which OS. However, I need your help in making the list exhaustive.

I have now firmly decided to test and describe only those browsers that run on one or more of the ten smartphone OSs (Android, bada, BlackBerry, iOS, LiMo, MeeGo, Phone 7, Symbian, webOS, Windows Mobile). There are just too many other OSs, but they’re either feature phone only, or they’ve fallen out of the race.

My question to you is to review the list and rack your brain for more data.

1. Do you know if a browser runs on one of the smartphone OSs but is not yet mentioned in my lists?
2. Do you know if a device vendor sells one of the smartphone OSs but is not yet mentioned in my lists?

If you do, please leave a comment with a useful link (to the browser vendor’s homepage, or to a news item that mentions device vendor A selling smartphone OS B).

Thanks.

jQuery announced the jQuery mobile project, which aims at bringing jQuery to mobile browsers. All mobile browsers; not just Safari iPhone and Android WebKit.

Still, bringing the library to all mobile browsers is a rather tall order, since there are so bloody many of them. Therefore John Resig has spent a lot of time with mobile phones (I know all about that, so I admire his persistency) and has produced a first serious stab at mobile browser grading.

jQuery’s approach differs slightly from Yahoo!’s, in that it has A-, B-, C- and F-grade browsers.

1. A High Quality. A high quality browser with notable market share. A must-target for a mobile web developer.
2. B Medium Quality. Either a lower quality browser with high market share or a high quality browser with low market share. Depending upon your capabilities you should work to support these browsers, as well.
3. C Low Quality. Typically an extremely low quality browser with high market share. Generally not capable of running modern JavaScript or DOM code.
4. F Failing. A barely-functioning browser. Even though it has some market share you should avoid developing for it completely.

Safari iPhone 3+, Android WebKit, Dolfin, Opera Mobile 10+, Symbian v5 (which I call Symbian WebKit 2), BlackBerry 6.0 (the WebKit-based one), Palm WebKit, Firefox, and the MeeGo MicroB browser (Gecko-based) are the A-graded ones, and I agree.

I hope other libraries will follow suit. In fact, Dojo and YUI are already doing so, although I’m not sure exactly where they are right now. (Pointers very welcome.) Ext.js has completely moved to mobile and has been renamed Sencha. My personal beef with Sencha is that they only support iPhone and Android; their examples do not work on Dolfin (Samsung bada), while that browser also supports the touch events. But that’ll change

Of course I fully support all these moves. My support will likely take the form of continuing to report on the mobile browsers and their odd quirks; that’s what I have been doing for the first generation of libraries, and that’s what they still need most.

The Fronteers 2010 conference has announced two new speakers: Jake Archibald of the BBC’s Glow library, and Stoyan Stefanov of Yahoo!

Thus the speakers’ list is continuing to grow, and the conference is becoming more and more worth your € 375. What are you waiting for? Order your ticket now!

On Tuesday Jason Grigsby challenged the conventional view that media queries are all we need to make a website mobile-friendly. Although he’s right when he points out some serious problems, I do not think that media queries are the “fool’s gold,” as Jason says. The message seems to be more that media queries alone are not enough to make your sites mobile-friendly. An additional component is required.

To recap briefly, this is a media query:

.sidebar { float: right; width: 250px; } @media all and (max-device-width: 600px) { .complicatedFunctionality { display: none; } .sidebar { float: none; width: auto; } }

The media query asks whether the width of the device is 600px at maximum. If it is, the special styles are executed. This usually comes down to hiding advanced functionalities that do not make sense on mobile or take too much bandwidth, while it can also be used to change the site’s grid from horizontally oriented to vertically oriented; for instance by placing a sidebar not right of the main content, but below it.

Technically, the .complicatedFunctionality and .sidebar declarations are added to the style sheet only when the query returns true, i.e. the device is less than 600px wide.

Now this works. Better still, media queries are the ideal way of adapting your design to different screen resolutions. Still, they are not the be-all-end-all of making your website mobile-friendly.

Jason identifies two main problem areas:

• It’s all very well to hide, say, an advanced mapping application on mobile, but if you use only media queries the browser will still download the scripts associated with the application.
• Even though images might be hidden from mobile browsers, or low-source ones should be used, the browser still downloads the full-source variants.

In other words, media queries do not stop the browser from downloading assets that will not be used on a mobile phone. And with bandwidth at a premium, this is a serious problem.

He concludes:

CSS media queries are a tool, but they are not a silver bullet.

I mostly, but not entire agree. Media queries are silver bullets when it comes to pure CSS. Restricting the width of your site, moving sidebars and main navigations elsewhere, media queries can do all that and more.

The trick, however, is that a pure CSS approach is not enough. In addition we need a JavaScript that also reads out the media queries and uses the data to decide whether to download the complicated mapping script, whether to download the low-source or the full-source images, or possibly none.

As far as I know there is no direct access to media queries from JavaScript. You can’t read out whether the example media query above has fired or not.

JavaScript pairing

Fortunately, there is a pretty safe way of using JavaScript in conjunction with media queries. It turns out that all browsers I tested so far have paired the width and device-width media queries with the values of document.documentElement. clientWidth and screen.width, respectively.

This is a general rule. All mobile browsers that support media queries exhibit these pairings. It’s hard to believe, but I haven’t found any exceptions yet — and rest assured that I searched for them, because I could not believe that it would be this simple. And I will continue to keep an eye on this and report problems as soon as I find them.

One caveat, though: although the pairing exists in all browsers, some browsers report incorrect values for document.documentElement. clientWidth and screen.width. However, these browsers will also fire media queries based on these incorrect values, so the net result remains that both media query and script are executed, although at the wrong time. See the viewport compatiblity table for the gory details.

Therefore, if we want a JavaScript component that fires when the example media query above is triggered, we simply do:

if (screen.width < 600) { // don’t download complicated script // use low-source images instead of full-source ones }

I think it’s best to reverse the script logic:

if (screen.width >= 600) { // download complicated script // swap in full-source images for low-source ones }

If you want to use width instead, do this:

@media all and (max-width: 900px) { // styles } if (document.documentElement.clientWidth < 900) { // scripts }

Thus it is quite possible to pair a JavaScript routine with your media queries, and use it to decide which assets you should and should not download.

When these scripts are added to media queries, we’re a whole lot closer to making one website that reacts to a mobile (or rather, a narrow-screen) environment both in its CSS and in its asset management.

Months ago I concluded that “HTML5” means whatever you want it to mean. This week, Jeffrey Zeldman and Jeff Croft took up the discussion, with Tantek Çelik and Bruce Lawson commenting.

Tantek Çelik said:

However, [the test site HTML5test.com] has one very big problem.

It tests things that it claims or implies are HTML5 (or conflates them as such) that are not actually part of HTML5.

Bruce Lawson said:

And what really makes my old-timers’ blood boil is people calling CSS3 or patented Apple CSS-extensions HTML5. The work of the Web Standards Project was incredibly successful in making people aware the structure and style are different. There’s an even greater separation in HTML5.

Jeff Croft said:

Sometimes we just need a word to rally behind. And put in job descriptions. And claim we “support” (another word that is mostly meaningless). It’s a language thing and a human psychology thing.

Needless to say, I agree with Jeff Croft here. There are several points that merit our attention:

1. It’s already too late. “HTML5” has taken on meaning as a marketing term and is being used as such — not least by the browser vendors. Any opposition is pointless.
2. Bruce’s argument would carry more force if the HTML5 spec hadn’t habitually blurred the line by inserting behaviour into what’s supposed to be a structure spec. Besides, any web developer is able to see that the <section> element, a -webkit-transform and Web Workers belong in different layers.
3. The HTML5 spec is changing constantly, and time and again features are yanked out of it. No doubt that makes sense from a spec-producing point of view, but the problems of spec writers should not dictate what web developers do. We just want to use cool new stuff and sell it to our clients.

I’m sorry, but I just can’t be bothered to once again rise to righteous fury about minor semantic points. Explaining the separation of structure, presentation, and behaviour was very important in its day (hell, I was the first to discuss separation of structure and behaviour back in 2004), but the concept was accepted by the web development community long ago, and I don’t see the use “HTML5” as a broad term contributing to its decline.

And I don’t care whether something is in a document called “HTML5” or not. What matters is what the browsers support, provided they communicate with W3C in the process. (And everybody is very serious about that nowadays. Whatever else happens, we won’t slip back into a Browser War. That danger has gone forever.)

But it seems one more round of pointless semantic purity discussions is called for, and many will rise to the occasion. Not me, though.

Let’s move on, shall we?

On 21 and 22 October the first Front Trends conference will take place in Warsaw. I will be speaking there; I’ll talk about JSON over SMS and other exciting marriages of web and mobile.

Tickets are inexpensive, not to say bloody cheap. € 198 to see a lot of good speakers (Douglas Crockford, Tantek Çelik, Dmitry Baranovskiy of Rafael.js, plenty of others) is not expensive.

So if you’re in the neighbourhood, why not join us in Warsaw? As of this writing there are still tickets available.

Here are four interesting mobile articles that caught my eye in the past 24 hours:

• Your mobile app is spying on you. About the danger in free apps.

  The study also found that a large proportion of apps contain third-party code with the capability to interact with sensitive data in a way that may not be apparent to users or the developers of the apps themselves. The third-party code is generally used for advertising or analytics. The project found that 47 percent of free Android apps included this third-party code, while 23 percent of free iPhone apps use it. Third-party code represents a security risk because it is difficult to update (and patch a vulnerability) on a global basis. Apple changed its terms of service for the iPhone recently because of its concerns about what third-party analytics and other companies were doing with private data.

• Nokia’s JavaScript Peformance Best Practices. Contains a lot that was taken from Steve Souders’s research and common knowledge, but also a few things I’ve never heard before. I’d really have to do an evaluation of some of the practices. Also contains a few ugly-but-necessary tricks for Symbian WebKit (S60).
• Also from Nokia: Introducing Ovi Browser Beta for Series 40. Nokia, too, has produced a mini-browser that relies on a server for the actual rendering and sends out the fully-rendered page, just as Opera Mini does. Now I need to lay my hands on an S40 device so that I can test it.
• From Bruce Lawson at Opera, finally, comes Mobile-friendly: The mobile web optimization guide with useful tips and tricks for making your website mobile-friendly.

  [...] mobile users are in a hurry; they're on the go and want to perform one specific task and then finish. A common example cited is that of a restaurant site. The mobile user wants to find the location, the menu and the opening hours so, the argument goes, the mobile site should contain this and nothing else.

  This is a good argument, but it's only half true. If it were 100% true, what would be on the "full" website? Presumably, a movie of the decor, some atmospheric music, animated representations of the house special dishes, and a downloadable menu in some fancy font. The fallacy here is that users of desktop computers are not task-focussed and have time to waste on an immersive branding experience.

In the mobile browser space all the advanced browsers are based on WebKit. That’s fine — WebKit is an excellent rendering engine — but if all browsers were based on WebKit I would start to worry about a monoculture. At least some browsers should be based on other rendering engines, as far as I’m concerned.

The only serious mobile candidate for “other rendering engine” is Opera. But I’m starting to wonder whether it can keep up with the WebKit browsers. With the recent release of Samsung Dolfin Opera Mobile has firmly dropped from third-best to fourth-best mobile browser on my list.

The problem is not that Opera isn’t innovating. It is. But I’m starting to wonder about the direction that innovation is taking.

Witness the recent release of Opera Mobile 10.1 beta for Symbian (on my 40th birthday; thanks, guys). I went through the press release, which highlights the following changes:

• Geolocation is now supported (although it doesn’t give the coordinates in my test page). That’s cool; it’s definitely something that’s extremely important on mobile.
• Vega graphics library and Carakan JavaScript engine. That’s fun to have, but I’m not sure if it’s the most important step Opera could have taken right now. I’ll get back to this.
• Various improvements to the user interface.

And that’s it, according to the press release. (border-radius is supported, maybe some other stuff too, and there will be some bug fixes here and there, but I haven’t yet studied it sufficiently to give you a full list.)

Relative importance

Nowadays all desktop browsers are innovating like mad in their JavaScript engines. For about a year and a half or so, significant improvements in JavaScript speed have been the Holy Grail of browser making, and every new release of every browser now routinely claims to be the fastest browser available.

(So routine has this claim become that I do not believe any of them any more. Besides, as far as I can tell they’re all testing JavaScript Core speed, while the biggest bottleneck is the speed with which DOM changes are made.)

Now on desktop this is a very important development. On mobile it’s also important, but I feel there are several other topics that are even more important than JavaScript speed, and that Opera is ignoring these topics.

Point is, a super-fast JavaScript engine is relatively worthless if you can’t properly set up a JavaScript-heavy interface. And the very first requirement for a JavaScript-heavy interface is that you always know exactly what the user is doing, so that you can react to his actions naturally and great UX is born.

It’s in the latter part of that equation that Opera Mobile has serious problems. I feel that, while innovating in JavaScript engines, Opera is forgetting basic mobile functionality without which a fast JavaScript engine is pointless.

Touch and viewport

There’s a reason I started my foray into mobile browsing by studying the touch events and the viewport dimensions. These two functionalities are absolutely vital to building compelling mobile interfaces.

The touch events allow us to follow exactly what the user is doing to the touchscreen. Without these events you can only detect whether the user clicks somewhere. That is enough for some interfaces, but others will definitely want to react to more subtle actions from the user.

The viewport dimensions are important for knowing how much of your site the user is currently seeing on his screen. An example will clarify why this is important.

I’m currently working on a little side project that involves writing the perfect JavaScript touch-scroll interface. This presupposes the touch events: without them it’s absolutely impossible to create a compelling UX.

However, I want several scrollable areas on the same page, and with that comes the problem of deciding when to allow a user to scroll. If the user has zoomed in and sees a little bit of one scrollable area on the edge of his screen, it makes sense not to scroll that area when he touches it, because it might confuse him. Instead, we should wait until the scrollable area covers most of the screen before allowing a scroll action. My prototype with this behaviour works pretty intuitively.

However, in order to know whether the scrollable area is on the screen I must be able to read out the dimensions of the visual viewport. I need to know which part of the page the user is currently viewing, compare it to the scrollable area, check their coordinates, and decide whether the user is allowed to scroll. That’s something that few browsers support right now.

Android and Samsung support the touch events, but not the visual viewport dimensions. Symbian, BlackBerry and IE support the visual viewport dimensions, but not the touch events. All other browsers, including Opera Mobile, support neither. So this script only works on the iPhone, which is the single browser to support both.

So this interface, which I feel is an example of a mobile-specific UX, will not work on Opera Mobile, regardless of the speed of its JavaScript engine. That’s what I mean when I say that I’m wondering about Opera’s direction of innovation.

Opera Mobile simply must support the touch events and the viewport dimensions.

Zooming

But Opera Mobile has an even larger problem, and that is zooming. Basically it has the worst zooming functionality of any mobile browser I tested. It seems Opera ignored the emerging standard for touch-based zooming, and instead created its own system. That’s fine, as long as the system works. But it doesn’t.

So what exactly is wrong with Opera’s zooming? Basically everything.

Two levels

Opera has only two zooming levels: in and out. Initially you see the entire page, just as on all other mobile browsers. When you zoom in, however, you go to one single pre-defined zooming level, and once you’ve arrived there your only option is to zoom out again.

This behaviour is not unique to Opera Mobile. Many other second-tier mobile browsers, such as Symbian WebKit on touchscreen Nokias, or IE, have only two zoom levels.

But there are two other characteristics that make the Opera zooming experience uniquely lousy.

Pre-emptive narrowing of text

Opera kind of pre-emptively narrows your text into columns that fit snugly in the screen when you zoom in. Although that’s excellent behaviour to display when the user actually zooms in (as Android does), doing this beforehand makes no sense and has the ability to destroy your page’s graphic design.

Here’s my compatibility master page as it should display on mobile (Dolfin on Samsung Wave). Note that the text in the table stretches all the way from left to right, as it should:

And here is the same page on Opera Mobile 10.10 (Nokia N97). Here the text in the table is narrowed to the width Opera is going to take later on, when you zoom in:

In this particular case I don’t mind much, but this feature has the ability to completely destroy a well-designed page. As far as I know you can’t do anything against this effect and will have to accept the damage it does to your page.

Single tap

But by far the worst feature of Opera’s zoom is the user interaction. On touchscreens an industry standard is emerging for zooming. You either pinch-zoom or you double-tap. Some browsers don’t support pinch-zoom, but the double-tap works pretty well, too.

However, Opera in its wisdom uses not a double-tap but a single-tap interface. Tap once when zoomed out and you will zoom in on roughly the area you tapped on.

This is terrible. In order to understand why, take a look at my Touch test page. It’s fully zoomed-out:

This is how I designed the page: I want it to be usable even fully zoomed-out. Thus I can load the page, hit Record, and record an event sequence of my choice.

But what happens in Opera Mobile when I hit Record with a single tap in order to start recording? It. Bloody. Zooms. In! That makes my test page much harder to use.

To be fair, Opera Mobile 10.10 does not zoom at all in pages that have a <meta viewport>, as my test page has. That solves this particular issue, but I feel it’s still a stop-gap solution. All other browsers do allow the user to zoom in on a <meta viewport>-enhanced page. (Some even allow you to zoom out.)

Opera’s problems

Concluding, Opera Mobile has a serious zoom problem that must be addressed in addition to the touch event and viewport dimension problem.

I feel that addressing these issues is more important than yet another faster JavaScript engine or yet another UX upgrade. Besides, as long as zoom remains lousy the UX can be upgraded only so much. Zooming is a fundamental part of the mobile UX; without it many other innovations just don’t make sense.

So in order to remain relevant on the highest tier of mobile browsing, Opera will have to concentrate on three things:

1. Fix zooming: double-tap interaction, many more zoom levels, no pre-emptive narrowing of text columns.
2. Support the touch events.
3. Allow us to read out the viewport dimensions.

I more-or-less expect the busy engineers in Oslo to be working on these problems, and I assume that the next major Opera Mobile upgrade will bring significant improvements here.

If it doesn’t, I’m afraid Opera is out of the race for the top spot. That is not necessarily bad: it could always forget about the top tier and instead concentrate on the low-end smartphone market. Right now Opera Mobile is available only for Symbian and Windows Mobile, and on those operating systems it’s the best available browser.

Without a serious upgrade of mobile-specific functionality ruling this second tier is the best Opera can hope for. The top tier will be WebKit-only.

This is just in: Google seems to be taking steps to allow operator billing. If that’s true it’s huge news.

Note from the outset that the article doesn’t say in so many words that operator billing is coming, although it certainly gives that impression, and plenty of publications translate it as such.

The basic idea of operator billing is very simple: if you want to buy an app, or access to online content, the price is automatically added to your operator bill (or, I assume, deducted from your pre-paid account).

Now I’m not a mobile billing specialist by any means, but I still want to give you an idea of what we’re talking about. If I make any technical mistakes, please correct them in the comments.

The billing process

Just yesterday I made my first Android Market purchase, and although the process was relatively smooth, I still had to fill in all my credit card stuff, make mistakes, being told off, etc. Besides, when I tried to do the same a few months ago, the Android Market rejected my credit card. Why? Probably because the Dutch market wasn’t active yet — but I thought of that only much later. At the moment I was pretty pissed.

Now with operator billing I wouldn’t have all this hassle. I’d just click on whatever I want to buy, give a one-time confirmation “Yes, I do want to spend € 2.39 on this” and be done. When my next operator bill comes around, the € 2.39 will be added to it.

In addition, operators can verify your identity through your SIM card, without you having to do anything. No more hassle with credit card numbers. (In fact, the only parties that have a lot to lose from operator billing are the credit card companies. Expect resistance from them; they’ll probably say it’s unsafe or something.)

Thus operator billing is by far the most user-friendly way of making mobile purchases. That’s what makes it so important. Besides, it also opens up the mobile marketplace to those that do not have a credit card.

A question of identity

However, Google’s rather vague announcement does leave some questions unanswered. No doubt that’s because Google is still figuring out how to answer those questions. But let’s review them anyway:

• What do I have to do in order to make a purchase? A one-step system is within reach; I hope it will be implemented.
• How will my identity (and thus my bill) be verified?
• How will the various parties communicate?

The last question is probably the most important one. If I want to make a purchase through operator billing, there are three parties involved: me, the selling party, and the operator. Somehow, the selling party has to connect to the operator to figure out exactly who I am, and to make a request to put € 2.39 on my bill for my purchase. In addition, the operator has to pay that money (maybe minus a fee) to the selling party.

The JIL 1.2 API gives us some clues as to how this system is going to work. This API, that will eventually be implemented in Vodafone 360 phones as well as, one hopes, many others, has two properties that are meant specifically for operator billing (p. 16):

Widget.Device.AccountInfo.phoneUserUniqueId Widget.Device.AccountInfo.phoneOperatorName

Thus, when purchase times comes around, the store has some grip on your identity. It will have to send off a communication to the specified operator stating that user with unique ID X wants to make a € 2.39 purchase.

The operator will have to make some effort to verify this information; after all I might be able to hack a phone to send false unique IDs. Thus the operator will probably send me an SMS “Are you sure you want to purchase product X for € 2.39?“ Once I reply to that SMS the purchase is made and downloading can commence.

Still, I hope that the process will become even more user-friendly. The same JIL specification defines a way to send an SMS from a widget. Thus, if I want to purchase something the system could automatically generate an SMS for me and send it off to the operator. Thus the operator will be able to verify my intent by comparing my unique user ID with the SIM card through which the SMS was sent. If they match the purchase is made and downloading can commence.

That’s one step less, and thus more user-friendly. Hell, if it’s implemented correctly I don’t even have to switch to my SMS application. (The operator still has to tell the store “Purchase made, proceed with download.” But a proper system will not bother me with the details.)

Unfortunately the JIL 1.2 spec does not yet contain the methods that will be used for actual payments, nor the exact workflow. Besides, it’s unclear which operators Google is talking to right now. Probably US-based ones, and of those only Verizon is part of the JIL consortium. The others might use other APIs. (Come to think of it, so might Verizon. One never knows.)

Future expansion

Let’s close on a positive note and assume that a system roughly similar to what I describe above will actually be in place in two years or so. Apart from the increased user-friendliness of the purchasing process, what will it bring?

The basic answer is Long Tail. Increased user-friendliness and the scrapping of the requirement to own a credit card may entice more consumers to make a mobile purchase. That would be good.

The real benefit will lie with developers, though. In theory, the system could be set up so that individual developers who offer one or two apps for download on their own site can also use it.

Thus the requirement to offer your wares through one or more app stores might also be scrapped. That could be especially important to cross-platform apps such as W3C Widgets. Whichever phone with whichever operator ends up at the developer’s site, they can all make a purchase, provided they support widgets.

One more nail in the app stores’ coffin would be the opportunity to make in-app purchases; say some articles from a news site or a few new levels for your game. Operator billing is explicitly meant for such purchases, too. And if we can use operator billing in our apps, too, the app store infrastructure is basically not necessary any more.

Picture the following:

1. I write a news reader app as a W3C Widget. Anyone can download it for free from my website.
2. If you like my app you can share it with your friends. Just send over the widget via Bluetooth. No more complicated user-unfriendly Send-To-Friend systems necessary.
3. But how do I make money? By selling access to the actual articles. Every article you want to read costs you, say € 0.02. Alternatively, you can buy a day of unlimited access for, I don’t know, € 0.99.
4. All the billing is done in-app through the operator. My users never have to do anything beyond saying “Yes, I want to buy this article.”

Where’s the app store in this process? Nowhere. We don’t need it any more. Wouldn’t that be something?

(I should note that although sending widgets via Bluetooth is possible nowadays — I’ve done it — the process is not very user-friendly yet. But this functionality is definitely coming; it’s not a pipe dream.)

Waiting for Google

So I’m impatiently waiting for Google to announce more details. Exactly how will their system work? What does the user have to do? Which operators? Questions, questions.

Anyway, the future of mobile payments has come one step closer.

Back in early June I got a Samsung Wave that runs the brand-new bada OS and did some brief tests of the native Dolfin browser. In the past few days I’ve done some more extensive testing, and the verdict is in: good browser, well on the way to becoming excellent.

(Oh, and Dolfin ought not to be confused with Dolphin, which is a skin for Android WebKit.)

It’s Samsung’s philosophy that it will not compete in a market unless it belongs to the top three of that market. In the case of the mobile browsing market Samsung has succeeded: from nothing, Dolfin has become the third-best mobile browser in the world. Only iPhone and Android are better.

If you’re keeping track of the mobile browser landscape you should add Dolfin to your A-list. It’s easily good enough, and Samsung has big plans with the bada operating system. Somewhere in 2011 the installed base of Dolfin will pass that of Safari iPhone, and bada might even become a competitor to Android. (Samsung sure hopes so.)

I have updated my mobile pages with Dolfin data. (By the way, I also tested Android 2.2 while I was at it: few changes. There’s not a single difference with 2.1 in my great WebKit table.)

The good parts

Dolfin is only the third browser in the world to support the touch events, after iPhone and Android, and that’s a large part of the reason I count it as the third-best mobile browser.

Mobile browsers for touchscreen phones just must support these events by the end of the year, or they’re out of the race. (Opera, Firefox, Microsoft, NetFront, Nokia, BlackBerry, you have been warned.)

Dolfin’s implementation is even slightly better than Android’s. If I do a pinch-zoom test on my touch test page I use two fingers, and during replay I want the browser to show the position of both fingers. iPhone does so, Android doesn’t. Now Dolfin also shows both fingers’ position.

Unfortunately Dolfin is not quite up to iPhone quality: my multitouch drag-and-drop does not work. Still, the stuff it does support is quite impressive for a browser that didn’t exist at the start of this year.

Dolfin’s responsiveness to pinch-zooming is good. One friend who’s used to the iPhone even said it’s better than Apple’s implementation. I’m not quite prepared to go that far yet, but it easily gives Android a run for its money.

Dolfin incorporates a very modern WebKit version, and in my great WebKit table it is the best mobile browser, narrowly above Android 2.1/2.2 and comfortably above the iPhone 3.1 (4 not yet tested).

I’m currently working on a little side project: the perfect scrolling layer script for touchscreens. Obviously it should work in all three browsers that support the touch events. Of the three Android gives me the biggest problems right now, with Dolfin smoothly sailing along in the wake of the iPhone without any serious problems.

Dolfin is just a bloody good browser.

The buggy parts

Still, not all is rosy. I found a few bugs in Dolfin, and I’ll enumerate them here for the benefit of the Samsung team:

• The viewport dimension properties are an absolute mess. Not only do they generally give wrong data, but a few of them change meaning when a <meta viewport> is present in the page. This must be addressed as soon as possible; it’s a show-stopper.
• There’s a bug in the touchstart event. When you assign an event handler to it and execute it once, the event handler is removed. See this test page for the effect. Works fine on iPhone and Android, but fails in Dolfin the second time you want to drag the item.
  The workaround, obviously, is setting the touchstart event handler again ontouchend. That works fine.
• Dolfin is over-eager in firing the scroll and contextmenu events. Basically they always fire, even if an action does not result in a scroll or a contextmenu. (In fact, I haven’t yet discovered any contextmenu on Dolfin.)
  These events should only fire if the scroll or contextmenu action actually take place.
• The event coordinates are wrong: clientX/Y and screenX/Y copy the values of pageX/Y, while they should report the coordinates relative to the visual viewport in CSS pixels and in device pixels, respectively.
• A personal peeve: on the browser software keyboard the “Go” button is located on the left. A standard is emerging whereby it’s the right button that says “OK, do it,” while the left button says “Never mind.” I got confused by Samsung’s button placement more than once.
• Samsung bada is supposed to support W3C Widgets, but there is no way for developers to upload test widgets to the phone. In practice that means nobody will test on Samsung bada. This situation must be rectified.

Still, such bugs are only to be expected from a first release. In general Samsung has delivered a good browser that’s only a few small steps away from becoming excellent. I will follow Samsung’s next moves with interest.

Apple continues to startle me, and I do not mean by its iPhone 4. (I haven’t yet seen it, so I can’t say anything useful about it.) No, what I mean is the ongoing Antennagate problems, and even there I do not mean the actual problem, but Apple’s way of dealing with it. And even there I do not mean Antennagate as an isolated PR incident, but as yet another chapter in how Apple spends 2010 to piss off the world at large.

Antennagate

The problem with Antennagate is not the actual technical issue itself. That issue may or may not be severe, may or may not occur on other phones, and is probably solved adequately by the covers Apple is now giving away. Frankly I don’t care about the details.

No, the problem is in how Apple handled the entire affair. Not its acknowledgement of the problem itself, or giving away the covers; those are proper, correct responses to the technical issue.

John Gruber made an interesting remark:

It’s telling that the criticism surrounding this issue has shifted, quickly, from speculation about a technical defect in the iPhone 4 hardware to criticism over the tone of Apple’s response to it.

The hardware defect is only a sideshow, and the way Apple is dealing with it is far more important to the world. Gruber is completely right in pointing this out, yet I believe he draws the wrong conclusions from it.

PR is crucial for Apple. Good PR has created a legion of Apple fanbois and a chattering class of tech commentators that consistently paints Apple in the best light possible. A serious PR flap is far more dangerous than a technical issue because it can cost Apple the support of the tech commentators (and possibly even the fanboi legion, but that will take more than a mere year full of Fuck Yous).

Thus I believe that Gruber is right, yet wrong. Weighing Apple’s tone and response is more important than the technical issue. Antennagate is about PR, and not about the iPhone 4’s antenna.

In that light, Tomi Ahonen points at an important mistake Apple made:

Why include that unnecessary hostile attack on the rest of the industry? That was a red flag to the rivals, and a clear challenge to the press to go compare. This is a lose-lose for Apple, even if others are implicated too, every time Death Grip is mentioned, Apple is the leading culprit of the news story. Every time the iPhone 4 is reminded to have Death Grip problems! And for every story where rivals are also implicated, there will be stories where at least one of the rivals is not shown as bad, or in the worst case, that Apple's iPhone 4 comes out worst at Death Grip. Apple's news coverage will be bad - or worse.

In other words, exactly because Steve Jobs wanted to implicate other phones in this problem, Antennagate will come back to haunt him. We can expect a string of press releases from other mobile players, saying something along the lines of “In contrast to Apple’s iPhone 4, our flagship product X does not suffer from an antenna problem.”

Note that it does not matter who’s right here. Even if Jobs is completely right and the other phone vendors are lying through their teeth, the world will again and again be reminded of Antennagate. That’s not disastrous, but it’s certainly a major annoyance that will hurt the iPhone 4’s sales figures somewhat.

Still, Antennagate alone will not spell doom and disaster for Apple. I would expect the hubbub to die down within a few months — if Antennagate were an isolated incident.

Problem is, it isn’t an isolated incident.

Apple pisses off everybody

I said it before and I’ll say it again: this year, Apple is being serious about pissing off absolutely everybody in sight. I do not think this is a viable long-term strategy, and I do think that if Apple keeps this up long enough it will eventually run into serious problems.

So what exactly did Apple do wrong?

First things first: in 2007 it barged in on the mobile market, changed the rules, and succeeded beyond everybody’s wildest dreams. That’s of course a huge success for Apple, and rightly celebrated as such, but it has also created a host of enemies: basically all other powerful mobile players. That’s not a disaster, but it does mean wolves are on the prowl, and Apple has to keep its defenses in order.

Its main line of defense, as always, is PR. And it’s exactly here that cracks are starting to show. Let’s recap Apple’s year so far:

• It pissed off Adobe by rejecting any kind of Flash on the iPhone. The problem here is not so much Adobe itself, which is facing serious trouble in making the move to mobile, but the Adobe fanboi legion, which got thoroughly angry. Adobe, too, has a powerful PR machine, and it knows how to reach designers. Adobe’s point of view has found powerful defenders. (So has Apple’s, but that’s not the point. It would have been far better to continue to let the Adobe hordes sleep.)
  PR translation: the iPhone is a closed platform, and Apple is proud of it.
• Closely related is the major SDK license flap when Apple banned 3rd-party runtimes from the iPhone. There are solid technical reasons for this, but that’s not the point. It’s one more PR flap and a serious gamble. To quote one analysis:

  The proposition is this: Apple is betting it can grow its platform fast enough, using any means necessary, that developers will stick around despite all the hardships and shoddy treatment. Each time it chooses to do what it thinks is best for the future of the iPhone OS platform instead of what will please developers, Apple is pushing more chips into the pot.

  Besides, once again attention was drawn to Apple’s almost frivolous app rejections. The problem here is not that Apple rejects some apps, but that the rules aren’t clear.
  PR translation: iPhone developers should bloody do what Apple tells them. The iPhone is a closed system that’s wholly dependent on Apple. Start loving it.
• Apple announced a lawsuit against patent infringements by HTC. To quote one analysis:

  Apple could be hoping for a chilling effect from other handset makers looking to avoid a legal battle. But Apple is walking a tightrope. It needs to whack HTC without drawing Google and Microsoft into the fight. Riddle me this: Can you realistically just focus on the hardware here? If so perhaps Apple can prosecute a surgical strike on HTC. The reality is that the smartphone software and hardware are intertwined. You can expect that Google and Microsoft will defend their code at some point.

  In other words, Apple may have bitten off more than it can chew. In any case it has aligned some of its most powerful competitors against it.
  PR translation: Apple will bully its weakest competitors on grounds that are not comprehensible to the general audience.
• Then it pissed off Mac developers by focusing WWDC wholly on iOS.
  PR translation: Fuck off, Mac devs. You’re not important any more.
• The case of the stolen prototype. I don’t really care about the legal aspects. The only thing I see is a large, legendarily closed company suing some journalists and assorted helpers.
  PR translation: Fuck you for not obeying our rules. We’ll send our Gestapo after you.
  I cannot help but be impressed by a closing remark on Gizmodo, the site that unveiled the stolen prototype:

  If you think that Gizmodo shouldn't have shown you the iPhone before Apple wanted you to see it, you’re accepting that Apple should be the one to control news about its products. That's not an irrational position, but let's be honest about what it means.

  [...]

  It hands back the control of the story to Apple because some are more comfortable believing Apple's machinations are infallible than that they’re a company made up of human beings who try to control the news cycle — and that even the best laid plan can fall apart because of a single human mistake.

  This is the flip side of the huge amount of attention the US tech world lavishes on Apple. Now that Apple is on the way to becoming a bully some media will gleefully report on it. It’s a new kind of Apple news, after all, and inherently more interesting that the next release of iWhatever.
• And now there is Antennagate.

(Incidentally, there are two groups that Apple hasn’t pissed off yet, and that I don’t expect them to piss off, either. They are consumers, who get their covers against Antennagate, and web developers, who’re still allowed to play with the most advanced mobile browser in the world. I continue to believe that web development is Apple’s ace in a hole. If everything else goes wrong, Apple will still have the best mobile web platform in the world.)

Is any of these mistakes fatal? Certainly not. Apple handled the technical aspects of Antennagate correctly, its rejection of Flash and the new SDK license agreements are defensible from a UX perspective, its dissing of Mac developers is understandable in the light of its mobile strategy, and I don’t doubt the lawsuits against HTC and the prototype culprits have a solid legal grounding. Finally, the PR flap is manageable in every case taken by itself.

Hubris

However, if we take all these issues together we see Apple spending 2010 by sending a cheerful Fuck You to people of all colours and all nations, and especially its own developers and former allies.

Is Apple suffering from imperial overstretch? Is Apple guilty of an old-fashioned case of hubris?

Judging from the evidence that’s certainly a possibility.

Fortune’s wheel. What goes up must come down. The throne of the once-almighty king is toppled because he grew overconfident.

Those are powerful story lines that have interested humanity for at least 2,500 years. Since they conform to some sort of basic human expectation of how history works, the tech commentators who are Apple’s PR mainstay could start to pursue them in order to present a different perspective and gain more readers. (Come to think of it, so am I.)

Right now Apple is doing everything in its power to push those story lines. In the long run that is not healthy.

I feel Apple has a PR problem, but isn’t aware of it, possibly because it doesn’t want to be aware of it.

Now let’s see how this plays out. The story isn’t done yet, and who knows, Apple might even see the errors of its ways before it’s too late.

In recent weeks Firefox 4 beta 1 and Opera 10.60 were released, and I could also put my hands on a working Chrome 4. I added all these browsers to the compatibility tables, which are now all updated, except for the Events one.

There’s little difference with my earlier reports, except that the new Firefox beta is making a serious effort to support the background module. It’s not there yet, but Firefox is not as disastrously behind as it was a month back.

Firefox

Of course Firefox remains a pain in other respects: still no support for contains(), incorrect indexing of attributes (it’s essentially random), no innerText or outerHTML, no sane second argument for the add() method for select boxes, a colorDepth of 24.

All these bugs are Firefox-only, with the exception of the attribute indexing, which is also a problem in IE. Frankly, I’m starting to get fed up with Firefox and its haughty refusal to implements useful methods and properties found in all other browsers. But maybe that’s a passing phase. Maybe I’ll pick another browser to be annoyed at next time around.

Events

I haven’t yet updated the Events table, partly because it’s such a lot of work (it takes me as much time as all other tables combined), and partly because I do not expect huge changes. I tested various problems in IE9, and sadly found no improvements.

I’m not sure when I’ll have the time to do the Events table; I hope before I leave on holiday in early August.

Vision Mobile just released its Mobile Developer Economics report in which it presents the result of a poll of 401 mobile developers across the eight main platforms: Android, iPhone, BlackBerry, Symbian, Windows Mobile, Flash, Java ME, and the mobile web.

If you’re interested in the mobile developer world, download and read the report. It’s free, though a valid email address is required. Below I treat some interesting aspects of the research, including the quote from me Vision Mobile decided to publish.

Platforms

The parity between the installed base of a platform and the amount of apps available is totally absent. As one would expect, the iPhone app store offers way more apps than the OS’s relatively humble market share warrants. No surprise here. (p. 10)

What is surprising is that the most popular platform among the 401 developers is not the iPhone, but Android with 60%. iPhone comes distinctly second at around 50%, and the third most popular platform, Java ME, is not far removed from it. No clear iPhone superiority here.

The mobile web does decently at 40% (i.e. 40% of the developers use the mobile web from time to time). Flash is used by about 20% of developers. The long tail is composed of Linux, BREW, bada, and webOS. It should be noted, however, that bada has only just been released. Thus its meager score is quite understandable. This is not the case for the other three platforms. (p. 12)

It should be noted that developers who used Java ME were rather negative about the platform. One said:

The vast majority of Java ME developers have lost faith in the write-once-run-anywhere vision

Incidentally, which technology do you think has the best chance to take over this write-once-run-anywhere vision? Hint: it has existed for twelve years already and has already been deployed across all smartphones.

Striking it rich

Why do developers choose a platform? The clear number one reason is market penetration at 75%, with revenue potential coming second at 50%. The existence of an app store or a development community is important for only 40% of the developers. (p. 13)

Frankly I believe that reason number two is going to disappear. Mobile development is not a goldmine, although obviously you can earn a decent living by making apps for others.

On page 26 the report explicitly treats the long-tail economics. If you’re just a random developer who tries to make boatloads of money by selling apps, will you succeed? Vision Mobile doesn’t think so.

The economics for long-tail developers - i.e. the per-capita profit for the average developer - remains dubious at best.

In other words, Apple’s App Store is not a shortcut to riches. It can’t take the place of the hard work of founding a succesful startup, making a compelling product that people want to use, and selling it to a large player.

The App Store will dole out only niche income to most developers. Obviously there will be one or two notable exceptions to that rule. It’s a casino, after all, and the luck of the draw can be with you. Wanna try? Have fun, but don’t complain that you don’t make any money.

Why is this so? The report pinpoints two main reasons:

1. First, there are plenty of “garage developers” around who create apps not for the money, but for status among their peers. Usually they offer their work for free or a nominal fee. If such a free app competes with your paid one, tough luck.
2. The huge crowding especially in Apple’s app store forces developers to lower their prices in order to remain competitive.

Mastering a platform

How much time does it take to master a platform? Android clocks in fastest with five months. The mobile web comes second with six (yay!), though it has to share this place with Flash. Then comes iPhone with about 7.5 months. By far the toughest nut to crack is Symbian, where it takes 15 months before you’re proficient enough with the platform to write a couple of moderately-simple apps. (p. 32)

Operators

Finally, the report talks about operators, and this happens to be a subject I’m deeply interested in. The general conclusion is that operators don“t care a hoot about mobile developers, and treat them badly. Questions aren’t answered, there is a complete lack of focus with initiatives and websites cropping up all over the place, and operators aren’t interested in the long tail of niche developers.

In other words, ADHD-suffering marketing people jump hither and tither, and don’t care about anything remotely resembling long-term planning. I don’t think that’s going to change in the near future.

Furthermore the operators refuse to send people to industry conferences, instead electing to hold their own. I’ve been to several such events, and although it always works in the sense that it’s a moderate-good conference with moderate-good speakers, the fact that they’re free to enter but not free from marketing speak means that they’re soon forgotten.

I am convinced that the operators’ approach to conferences is wrong. I hope to prove that within the next year.

Which brings me to the quote from me Vision Mobile decided to include (p. 43/44):

The first mobile company to TRULY reach out to web developers will have an edge over the competition, but right now I don’t see any candidates. Except for Google, obviously. (And Apple, but they’re playing their own game.) If Google became an operator our problems would be solved.

To be honest I completely forgot about this thought until Vision Mobile contacted me for permission to quote me. Reading it back I feel I’m on to something. So yes, I agree with myself.

Wondering what Google’s next step will be? Becoming an operator. Especially in the totally dysfunctional American market. They’ll bring simple mobile billing to the world. Unless the traditional operators do it first, but there’s little chance of that.

Interesting idea, no? Not easy, no sir, not at all. But it’s the obvious next step as far as I’m concerned. Operatorship is where the money is. And where the need for innovation is greatest. We don’t have to expect anything from the current marketing-driven bunch.

Well, I’ve revised the DOM CSS and the DOM CSS OM tables, too, and IE9 continues its march. It supports the standards!

Let’s be more specific. The following methods or properties were not supported by IE8 or lower, but are supported by IE9:

• getComputedStyle()
• cssRules[] (in addition to the proprietary rules[])
• deleteRule() and insertRule() (in addition to the proprietary addRule() and removeRule())
• innerWidth/Height and pageX/YOffset (!!!). Ever since the Browser Wars IE has refused to support these originally Netscape-proprietary properties, but IE9 supports them.
• pageX/Y (!!!). Back in 2002 I complained that IE didn’t give us the opportunity to read out the coordinates of a click event relative to the HTML document. Now IE9 finally gives us what we need.

There’s more, but these are the highlights.

Meanwhile I’ve discovered one bug and one oversight, which I’ll treat here for the benefit of the IE team:

1. A selectorText bug.
   If a rule has selector p#test,ul, IE8 and lower split it into two separate rules, one for p#test and one for ul. IE9 has revised this behaviour: it’s now only one rule. Still, when querying the rule’s selectorText it returns p#test, and not p#test,ul. This must be fixed before the final release.
2. An honest oversight: IE9 does not support setProperty on style sheets. This is not important; nobody uses the ponderous and slightly absurd x.style.setProperty('color','#00cc00',null) instead of x.style.color = '#00cc00', but for completeness’ sake it would be nice if IE9 supported it.

But that’s it. These are the only two IE9 problems I discovered in this round of revising. If we add the white-space: pre-line bug I discovered earlier we get to a grand total of three IE9 bugs.

Not bad, Microsoft. Not bad at all.

IE’s position

So what does all this mean for IE’s position in the browser landscape? It’s obvious that it has improved that position, but there’s more.

After IE7 and IE8 had been released I was left wondering about Microsoft’s pace of improvement. Sure, both releases fixed a lot of CSS and JavaScript issues and added support for new stuff, but was that enough?

The question was whether IE improved faster than the other browsers. Pure improvement rate is an unreliable metric at best; if you improve but the other browsers improve faster, you’ll fall even further behind.

I doubted that IE’s improvement rate was enough. With the advent of IE9, however, I doubt no more. Microsoft has made a giant leap forward, and I feel that, certainly in the traditional, non-HTML5 methods and properties, IE’s improvement rate now exceeds that of the other browsers. (They have more stuff to improve, but still.)

I haven’t yet studied HTML5 and related items, and I wouldn’t be surprised if IE still lags there, and that its rate of improvement is not enough yet. Nonetheless, that might change with IE10, now that the obvious stuff has been done. And who knows, I might even be wrong, and IE9 might show a prodigious rate of improvement in HTML5, too.

elementFromPoint()

Another major improvement has been added by Safari, Chrome, and Opera.

elementFromPoint() allows you to see which element is located at a specified coordinate pair. This is a godsent for drag-and-drop scripts: just get the mouse coordinates at the time the user releases the element, find the element that’s located there, and you know the drop target.

Until now, however, there was an incompatibility in the coordinates themselves. IE and Firefox required coordinates relative to the browser window (clientX/Y), while the other browsers required coordinates relative to the HTML document (pageX/Y).

No more. Safari, Chrome, and Opera have followed IE’s and Firefox’s lead and now also support coordinates relative to the browser window. As a result elementFromPoint() is now truly usable.

Future enhancements

There’s a catch here, however. elementFromPoint() returns the topmost element located at the requested coordinates, and when you use position: absolute that might matter. More specifically, any drag-and-drop script uses absolute positioning, which means that when you directly query elementFromPoint() the browser returns the dropped layer, and not the element that’s underneath it.

The solution is to first give the dropped layer a display: none, then query elementFromPoint(), and then restore the dropped layer’s original display.

Still, elementFromPoint() can be improved here. In a future version it should return an array of elements located at the coordinates, in (reversed?) order of z-index.

Thus we’d get all the eligible elements, and it would be up to us to choose between them.

Pretty please, browser vendors?

Problems

Still, not everything is rosy. I’ve got a few issues with the non-IE browsers.

colorDepth in Firefox

First of all, an old Firefox bug returned. Right now Firefox 3.6 returns 24 when you query colorDepth/pixelDepth, and that’s clearly incorrect on my system, which has a color depth of 32; a depth that’s properly returned by all other browsers.

An earlier Firefox version also had this bug, but it was corrected in the next version. Can’t remember which ones.

currentStyle

Also, Firefox, Safari, and Chrome stubbornly refuse to support currentStyle. Yes, this is a Microsoft proprietary property, but it’s one of those MS properties that’s just a bloody brilliant idea.

The syntax of getComputedStyle() is very ugly, and besides it always returns the value you query in pixels. currentStyle returns the value in whichever unit the style sheet is really using.

Sometimes you need the one, sometimes the other. IE9 and Opera support both. I think Firefox, Safari, and Chrome should move on and implement currentStyle. And no, it’s not in the standard, but if we have to wait for W3C nothing will ever happen.

imports

Similarly, it would be useful if all non-IE browsers also supported the imports array, which gives a list of imported style sheets. This is not nearly as important as currentStyle, but it could conceivable be useful in edge cases.

In the past few days I’ve been revising the CSS compatibility table with information about the latest crop of browsers. There’s no doubt about it: this is IE9’s show. It just supports nearly everything. No hassle, no buts.

Besides, CSS3 selectors are now fully supported by all browsers but one. And that one browser is not IE. It’s, curiously, Opera.

IE improvements

Microsoft has finally taken the big leap forward we’ve been waiting for ever since they announced their decision to restart IE development back in 2005.

IE9 promises to be an excellent browser. Its CSS support is now at par with that of the other browsers — although each browser still has its specific areas where it performs less. But we cannot in good faith say that IE is behind the others any more.

There are only a very few declarations in my test that IE9 does not support. CSS columns, gradients, text-shadow, resize, and text-stroke are the only ones, and the latter two are WebKit-only.

Even better news: Microsoft’s filters seem to have just disappeared from IE9. It supports normal opacity; no more filters required. Also, the gradient filter is gone, leaving IE (temporarily?) not supporting it.

Another golden oldie that got dropped is cursor: hand, the MS proprietary alternative to cursor: pointer. That’s not really important in practice (IE6 already supported both syntaxes), but it’s a powerful symbol of the changes that the IE team has wrought.

With so much excellence around I was almost glad when I found one single bug: IE9 doesn’t handle white-space: pre-line right. This bug will be fixed, though. It’s typically a minor point that crops up in a beta and is removed from the final product.

Kangax studied the JavaScript and DOM changes and finds significant improvements. He also lists quite a few things that still have to be addressed, but those items strike me as fairly minor points, most of which are probably honest oversights.

Test it!

By the way, if you want IE9 to be an excellent browser, do what Kangax and I did and test it. Then write up the results, and point out bugs or possible improvements. The IE team needs this feedback, and I know from experience that they do read this kind of posts and try to improve their product.

If you know of another series of tests that somebody has put IE9 through, pleae leave a comment.

CSS3 selectors and Opera

CSS3 selectors are now fully supported by all browsers but Opera. Not that Opera’s sins are manifold: there are two bugs the Opera team will have to solve in order to join the fully-compliant browsers:

• The mess the browser makes with dynamic nth-child and nth-of-type declarations. Statically it works fine, but as soon as you add elements with JavaScript Opera goes completely haywire.
  This is all the more odd since Opera supports dynamic nth-last-child and nth-last-of-type declarations absolutely fine. I don’t understand the difference.
• The :target pseudo-class does not react properly to use of the Back or Forward functionality.

Both are relatively minor issues, although both have been plaguing Opera for ages now. All other browsers have had similar nth-child problems, but they have been solved fully.

New tests

I already talked about the support for the background module. There’s no question here: IE9 has the best support; Firefox the worst.

I added :nth-last-child() and :nth-last-of-type() and :first-of-type, :last-of-type, and :only-of-type tests, this being the only CSS3 selectors I did not test yet. All browsers support them fine.

We can also welcome a whole new slew of values for list-style-type. Binary, lower- and upper-hexadecimal, lower- and upper-norwegian, and octal are now supported by Safari 5 and Chrome 5. I’m not sure if these values are terribly important, but binary lists will look cool on any nerd-type of site.

I also added test pages for border-radius, box-shadow, gradient, text-shadow, and text-stroke. These properties are more of a mixed bag; the first two are universally supported; the last three are not supported by IE9, while Firefox lacks text-stroke.

All in all this was time well spent. CSS3 is really coming on strong, and there’s no more excuse not to try your hand at it.

On 7 and 8 October Fronteers 2010 will take place in Amsterdam. Three more speakers and one more workshop have been announced, and the early bird period will end next Wednesday, at the end of June.

The three speakers are Brad Neuberg, who will talk about SVG, and Steve Faulkner and Hans Hillen, who will talk about doing HTML5 the accessible way: with ARIA.

Dan Rubin will be giving a workshop “Bringing Your Design to Life with CSS3” on Tuesday 5 October, two days before the conference.

Right now a conference ticket for two days is still only € 275. These prices will go up next Thursday, though. A workshop ticket for Dan Rubin or Andy Clarke will remain € 350 So what are you waiting for? Buy one! (Or two, or five.)

(Fronteers members should not use the general ticket sale page. Instead, they have gotten a mail with special instructions for obtaining an extra discount.)

I hope to see some of my readers at Fronteers 2010.

I just finished my CSS3 background tests, and I’m happy to report that all browsers but one now support the module very well. Also, I’m pleased to report that all browser vendors but one have ditched the vendor prefixes and now support the pure, correct CSS3 properties.

All browsers but one. If you guess that that one browser is IE, you’ve guessed wrong. It’s Firefox.

In the latest crop of browsers, this is the situation:

• IE9 preview 3 supports everything except border-image.
• Opera 10.53 supports everything, except that it has issues with background-clip.
• Safari 5 and Chrome 5 support everything, except that they interpret background-repeat: round and space as no-repeat, and that they have forgotten to remove the vendor prefix from background-clip: content-box. (padding-box works fine without prefix. Go figure.)
• Firefox 3.6.3, unfortunately, does not support background-attachment: local, the new background-repeat values, background-clip, and background-origin, and uses vendor prefixes for what it does support.

These new facts have not been added to the CSS compatibility table yet; the series of tests is supposed to be a step towards updating that table, but so much has happened in the background module that it’s worth early publication and a separate entry.

Local background images

I’m extremely, extraordinarily pleased by the fact that all browsers save Firefox now support background-attachment: local. This value makes the background image scroll with the element.

div.test { background-image: url(/pix/logo_quirksmode.gif); border: 5px solid; padding: 10px; width: 400px; height: 52px; overflow: auto; color: #999999; margin: 5px 0; }

Scrollable

Test Test Test Test Test Test Test

I discovered the need for this value back in 2002, and published about it when I unveiled QuirksMode.org back in October 2003. Moving at a brisk pace, W3C and the browsers have implemented it within seven years.

Pretty soon I’m going to argue that position needs a fifth value. If we take local backgrounds as a precedent, this fifth value will be implemented in 2017.

Transparent borders

Web designers will want to look into transparent borders. Some new background properties, notably background-clip: padding-box only make sense when the element’s borders are in fact transparent. The test page allows you to toggle the border colour.

I’m not totally sure what the use of all of this is, but then I’m not a designer and I’m usually very bad at estimating the design impact of new properties such as this one.

Vendor prefixes

Finally, the latest crop of browsers gives completely unexpected support to my contention that vendor prefixes should be abolished. I published that thought back in March, and within 24 hours Eric Meyer, Andy Clarke, Jonathan Snook, and Stephen Hay told me I was wrong. Vendor prefixes may not be beautiful, but they’re necessary. As a result, I backtracked.

Now, however, I find that Microsoft, Apple, Google, and Opera have decided to ditch all vendor prefixes in the background module (although an oversight allows one -webkit- instance to survive for the moment).

If you’re still wondering what my gripe with vendor prefixes is, take a look at the test page. I have to repeat all of my tests for all of the vendor prefixes, and so do you when you actually want to use it in a live site.

Does that mean I’m right after all? I can’t say for sure. The spec is in Last Call, but that doesn’t mean it’s a recommendation yet, and as far as I understand prefixes should only be ditched when a spec is in fact a recommendation.

Still, the very same crop of browsers that ditched the background-related vendor prefixes maintains them for box-sizing, even though the meaning of this property has been stable for years. Only IE9 preview 3 uses the pure declaration.

So all in all the fact that the background vendor prefixes have been removed does not prove that I was right. Pity, but I guess I’ll survive.

About a month ago I release part one of my series “A tale of two viewports,” where I discuss the widths and heights of the viewport, the <html> element, and related issues on desktop browsers. Today I release part two, which deals with the mobile browsers. And of course there’s the inevitable compatibility table.

I advise you to read part one before starting on part two; part one explains some crucial concepts that you need in order to understand part two.

Mobile browsers have two viewports, and not one, as the desktop browsers have. On mobile it’s impossible to make the viewport (relative to which all CSS layouts are calculated) as wide as the screen, because the screen is far too tiny and some CSS layouts may look horribly squashed.

Therefore mobile browser vendors have split the viewport into a visual one and a layout one; the first is the area the user actually sees on his screen, the second the area in which the CSS layout is calculated. This makes sense, but it’s one more complication for mobile web developers.

I also treat mouse coordinates, media queries, and the <meta viewport> tag.

Curious findings include:

• The best browsers in the series of tests are the iPhone and Nokia’s Symbian WebKit, which performs really brilliantly except that it doesn not support <meta viewport>.
• When setting a <meta viewport> in Samsung WebKit (on bada), several properties change meaning and suddenly give different data. This is obviously a bug, and one I hadn’t expected. It makes your job as a web developer more complicated — but then, nearly everything I discover does.
• The crucial visual viewport size, which tells you how much of your site the user is currently viewing, is given only in iPhone, Symbian WebKit, and BlackBerry. The other browsers don’t include this vital information — yet.
• Opera and Firefox perform rather poorly in this series of tests.

Have fun!