When adding these two top speakers to the already-existing roster of Steve Souders, Nate Koechley, John Resig, and Nicole Sullivan, we’re starting to see the outline of a first-class web development conference. The other six speakers will be announced later.

Currently Fronteers 2009 tickets are € 250 (€ 175 for one day), but when the early bird period expires on the 10th of July these prices will go up to € 350 and € 250, respectively. So now is the time to order your ticket. (Fronteers members have additional discounts; you ought to have received a mail with instructions by now.)

I hope to be able to welcome some of my readers in Amsterdam in November.

Basically, IE6 will continue to exist when IE7 has all but disappeared, and, contrary to what you might expect, this situation will create exciting opportunities for Microsoft’s competitors.

Besides, last week the news came that Microsoft is going to voluntarily de-bundle IE from all Windows 7 machines that will be sold in Europe, and I continue to have my doubts about that affair.

So it’s time for a special State of the Browsers IE edition.

As we all know IE8 is out, and whatever your opinion, no one will doubt that it’s a better browser than IE7, and that a quick growth of the IE8 market share will serve web developers well.

Still, the real problem for web developers is IE6. That’s the browser we absolutely have to get rid of.

IE8 is picking up quite a bit of market share right now; but as far as I can see that share mostly comes from IE7, and not from IE6. The following graph shows where I think the market shares of the various IEs are heading:

Although IE8 will become the largest Microsoft browser, I expect IE6 to retain about 20 to 25% of the market even by the end of 2010 (OK, maybe 15%, but still considerable), while IE7 will drop below IE6 sometime (early?) next year.

Now why do I expect IE6 to stick around while IE7 goes down? The answer is simple: Intranets.

Intranets

In the era of IE6 dominance (2000-2006), countless companies created countless Intranet application for time registration, sales support, contact information, you name it. All these applications are absolutely vital for the daily datastream in these companies.

Some companies deliberately opted for Microsoft technology and a Microsoft-only Intranet, while others were lazy and didn’t bother to make these apps compatible with other browsers, even though they did not particularly use Microsoft products.

The net result is that there are countless vital apps around the world that only work with IE6. Not with another browser — not even IE7. Therefore the companies did not upgrade their browser. (Incidentally, this was the most important reason for Microsoft to introduce the versioning switch — the IE team wanted to prevent a repeat performance of this problem.)

Sure, some companies will revise these apps to work with other browsers, but many won’t, partly because it costs too much money in this time of recession, partly because it’s so hard to find good front-end engineers (which good front-ender wants to work on Intranet applications for several years?), and partly because the old apps still work, don’t they?

So many old apps won’t change, and many office workers will continue to be condemned to IE6.

Office vs. home

At work, that is. It’s quite likely that on their private computer at home they run another browser — IE7 or 8, Firefox, or maybe one of the smaller ones.

What generally gets too little attention is the difference between browser stats during office hours and browser stats outside office hours. More than one web developer told me in the past year that there is quite a bit of difference between the two.

Basically, most of the IE6 market share comes from office-hour surfing, while it drops significantly in the after-hours period. This is something to keep an eye on when a client comes with his site stats. If you can, split out the office hours and after-hours stats, and take a look at the pattern that emerges.

I wouldn’t be surprised if business-to-business clients will continue to demand IE6 compatibility, while business-to-consumer clients will start to drop this demand — especially when we put a realistic price tag on IE6. It all depends on when users visit their site.

Update: reader S. Anand found exactly the predicted result when he checked his logfiles

The price tag

I think that we web developers will start to get fed up with IE6 to such a degree that we are actually going to charge more money when this browser comes into play.

“Want a site that works perfectly in IE6? Fine, but it’ll cost you about 20 to 30% extra.”

In fact, I hope web developers will start to charge this extra amount reasonably soon. Some clients won’t be willing to pay, which will save you a lot of heartache (and hair care products), some clients will actually pay you for your extra-special IE6 trouble, and yes, you might lose some business as a result. Therefore this is a decision everybody should take on their own.

Despite understandable hesitation, in the long run charging extra money for IE6 compatibility is inevitable. The result will be that less and less sites will work perfectly in IE6.

Two corporate browsers

The victims will be the office workers during office hours. They’ll find that they are less and less able to view perfect sites on the Internet — even though their Intranet applications will still work fine.

The obvious solution to this problem will be to install another browser for real surfing on the corporate network. Whichever browser the company will eventually select, one thing is certain: it will not be IE.

After all, it’s officially impossible to install several IE versions next to each other, and I doubt whether cautious and conservative corporate sysadmins will go with one of the unofficial ways.

In fact, a source within a large company told me they are seriously considering installing Opera as the real browser on their internal network, and use IE6 only for accessing their internal apps. I have no idea whether that will actually happen in this particular company, but it shows that the basic scenario is viable.

Thus IE6 will more and more become an internal system browser, while office workers use a non-IE browser to surf the real Internet. This process will work to the detriment of IE’s overall market share relative to the other browsers.

Companies will be forced to choose one non-IE browser. Which one? Probably the one with the best marketing machine.

This opens up perspectives for the other browser vendors — unless they’re locked up in battles that are purported to serve and protect web developers and end users, but will certainly harm the latter, while the former will not benefit much.

Opera vs. Microsoft, round 3

Microsoft has voluntarily decided to unbundle IE from all Windows 7 computers that will be sold in Europe. It leaves the choice and installation of the browser to the hardware vendors or the consumers.

This is supposed to be a great victory for web standards. Hurray, hurray.

Frankly, I’m getting downright frightened of the whole affair. I wish the European Commission, Opera, and their allies would just stop it. It’s opening the path for an endless series of partisan complaints.

Sure, it was to Microsoft’s advantage that IE was automatically installed on any Windows computer. Sure, it has inflated IE’s market share to 90%, because the other browser vendors didn’t have comparable distribution channels.

Still, I wonder if anybody would have complained if IE had been 100% standards compliant. It’s the combination of distribution advantage with the eternal IE6 problems that made people get sick of Microsoft.

Besides, I have my doubts about the fairness of the process. I have not yet heard a similar complaint against Apple for tying Safari to its operating system. Or against the KDE guys for tying Konqueror to theirs, for that matter.

Canned worms, anyone?

In any case, Microsoft is not awaiting the European Commission’s formal ruling and has chosen the Zero option. A new Windows computer will contain zero browsers — unless the hardware vendor installs a browser of its choice.

There are several things wrong with this solution:

1. Suppose a consumer buys a new computer and it doesn’t have any browser installed on it. How is he going to get one?
2. Probable answer: some kind of temporary download program that pops up the very first time he uses his computer and gives him the choice of no less than five browsers. Problem is, the consumer doesn’t want this choice because he has no idea what’s going on.
3. Besides, if this solution is implemented we can expect a stream of complaints from the truly tiny browsers nobody has ever heard of. In all fairness, we should include them, too. So the user will get the choice of eight to ten (twelve? fourteen?) browsers — a choice he doesn’t want and has no idea what to do with.
4. Or will somebody have to decide which browsers to allow in this program? Who? How long will it take before this person or institution is accused of unfairness because he forgot one browser?
5. Now suppose the hardware vendor installs one browser on the computer. Even worse, suppose this browser is actually IE. Are we going to get a crusade against hardware vendors, too, for daring to install the wrong browser?
6. Suppose the world caves in to the mighty pressure of teh Interwebz and forsakes IE forever. Now hardware vendors will install another browser. Let’s say they mostly opt for Firefox — a reasonable choice in today’s market. Will we get a re-run of the entire thing, but now aimed against those evil hardware vendors who’re giving Firefox an unfair advantage? If so, when will it stop? If not, where’s the fairness in the process?

We’re opening up a can of worms that should remain firmly closed.

Precedent

Finally, with this ruling we’re setting a precedent that I feel should not be set.

Opera Mobile used as default browser for all HTC phones? Unfair advantage! Google WebKit default for Android? Unfair advantage! And let’s not talk about the iPhone and Apple’s manifestly hideous unfair advantage there.

If we take this ruling to it utmost conclusion a mobile phone vendor may not install a default browser on its system, but will have to allow consumers free choice, too. So the innocent end user who just wants to surf with his brand new mobile phone will first have to pick one of approximately two dozen browsers.

Where will it stop?

I feel we should allow Microsoft to continue to bundle IE with Windows. Not because it’s good and proper what Microsoft has been doing, but because the alternatives are far worse.

As I showed in the first part of this article, Microsoft’s competitors are granted a unique chance to conquer the office market. I feel they should spend their energy on that part of the market instead of setting potentially dangerous precedents that will most likely harm the end-users more than anyone else.

Although in theory there’s little difference with cookies, HTML5 Storage is more useful because it doesn’t get sent to the server (less overhead), and because the fields can contain more information than a cookie (this feature is untested, BTW). These two advantages are clearest when you want to set a lot of values; for instance for a preference menu.

HTML5 Storage is supported by IE8, Firefox 3.5b4, and Safari 4. As yet Chrome and Opera do not support it.

Safari’s support is by far the best, because it is the only browser to also support the special properties of the new storage event.

IE8 supports HTML5 Storage in both IE8 and IE7 mode. A pure IE7 does not support HTML5 Storage.

localStorage and sessionStorage

There are two storage options:

1. sessionStorage sets fields on the window. When the window is closed, the session fields are lost, even if the site remains open in another window.
2. localStorage sets fields on the domain. Even when you close the browser, reopen it, and go back to the site, it remembers all fields in localStorage.

Essentially, that means that the entire sessionStorage is cleared when the user closes the browser window, while localStorage will remain available forever.

Except for this difference the two storage objects work exactly the same. The detail table contains a full breakdown of the rather simple API.

The storage event

The specification also defines a storage event that fires whenever a change is made to a field. Safari requires you to define your event listener on the <body>; IE requires it to be set on the document. Firefox doesn’t care.

The interesting part is that if you change a localStorage field this event fires in all windows that contain a page of your site.

So if I’d open three QuirksMode.org pages in three tabs, and I’d change the localStorage in one of them, the event fires in all three tabs. Thus other pages can keep track of what’s going on and update themselves, if necessary.

This event needs some special properties in order to tell us which key was changed, what the old and the new value are, etc. Unfortunately only the Safari team has made an effort to implement them; Firefox supports only the least interesting property, and IE none at all.

By far the most interesting property is source, which refers to the window in which the localStorage change took place.

By itself that’s only of moderate interest, but the consequence is that we now have a way of connecting windows that do not know of each other’s existence.

Cross-window communication

Until now, windows could only influence each other if they were aware of each other’s existence; i.e. if one window was opened by the other by means of JavaScript. In that case, the new window received an opener property that referred to the old window, while in the old window you could store the return value of the window.open() call (i.e. the new window) in a variable.

This was the only way of enabling cross-window communication. If a user manually opened two pages of your site in two windows, there was no way these windows could figure out each other’s existence.

With the coming of the source property this restriction is lifted.

When a storage event fires and you read out the source, you can now access the window in which the event fired. In other words, you have created a reference from one window to another.

In order to connect all windows that have your site in them, just register a storage event, change a field in one window, capture the events in the other windows, and create a variable. Now all other windows are connected to the first one, and a simple cross-window script will create a lookup table that gives all windows access to all other ones.

Although this sounds nice, I wonder if there are security repercussions.

Still, HTML5 Storage is here to stay, and it will be especially important on mobile phones, which, as always, suffer from worse data connections than desktop browsers. I’ll run the tests on the mobile browsers later.

The Fronteers 2009 conference will be held on 5th and 6th of November in Amsterdam. In addition to Nate Koechley and Steve Souders , John Resig of jQuery and Nicole Sullivan will join us to discuss JavaScript libraries and object-oriented CSS, respectively. The line-up will consist of twelve world-class speakers; the other eight will be announced later.

Ticket sale has started; currently we’re in the early bird period that will expire on the 3rd of July. A two-day ticket costs € 250; a one-day ticket € 175.

Additional discounts are available for Fronteers members (who have meanwhile received a mail), and Dutch educational institutions.

The conference is sponsored by Vodafone, and we’re currently negotiating with other potential sponsors.

I hope to see some of you at Fronteers 2009!

After that I decided to continue with mobile browsers, of which I have 15 lying around on my desk. Unfortunately I could not test IE Mobile (old) because it supports only inline event handlers, Skyfire because it does not allow you to remove alerts, and the Opera runtime in the Vodafone widget manager for terrifyingly complicated reasons I still have to describe properly.

Still I managed to test the other twelve and found a few surprises.

All in all these bugs are not very important. Nobody ever uses getElementsByName() or the nodeValue of comments, while we remove event handlers by specialised event methods and have learned to work around the empty text node issue. Only the S60 WebKit bugs are annoying, and even they can be worked around.

Still, these bugs have their use as marker bugs; that is, as bugs that show how well (or badly) a certain browser is progressing, and that allows us to estimate its relation to other browsers.

I was saddened by the differences between S60 WebKit on the Samsung on the one hand, and those on the Nokia on the other. Until now I dared to assume that there’s only one S60 WebKit, but it turns out there are differences between Nokia and Samsung after all.

Fortunately Nokia remains by far the most important vendor of S60 devices, so I assume web developers are going to ignore the Samsung S60 WebKit’s differences. In the end, they will remain Samsung’s problem, not web developers’.

What puzzles me is the fact that two totally unrelated bugs occur in Opera 8, S60 WebKit Samsung, and Blackberry. What’s the common denominator of these browsers? What’s the common denominator of empty text nodes and a faulty comment nodeValue? I have no idea.

The chances of exactly these two (apparently unrelated) bugs occurring in the same three browsers (that do not share a code base) are small enough to wonder and worry.

I have no solutions, only more questions.

Still, we can now take as a given that the DOM Core support of all mobile browsers, including Blackberry and NetFront, is decent. Their problems are mostly located in performance: there Blackberry and NetFront have to take a back seat to Opera and all WebKits.

More research is clearly necessary.

This sort of testing should not be used at all. Ever. The methodology is plain wrong. Browser compatibility tests are to be done by hand. Any automated system is useless, because it will give false information.

Before we continue we should make a distinction between performance, network, and compatibility testing. The first two can be automated — in fact, the whole point of performance tests is to measure the time a script needs to execute, which makes an automated set-up almost mandatory. Networking tests, too, can easily be automated (as Steve Souders has done).

Compatibility tests, however, cannot be automated. I’ve thought about this problem for quite a while since starting my mobile compatibility work, but a quick test last Thursday proved conclusively that testing CSS by means of JavaScript is just plain wrong.

CSS tests in JavaScript

In theory, testing CSS compatibility by means of JavaScript is quite elegant. Kangax gives this example:

 if (docEl && (s = docEl.style)) {
      return typeof s.borderRadius == "string"
        || typeof s.MozBorderRadius == "string"
        || typeof s.WebkitBorderRadius == "string"
        || typeof s.KhtmlBorderRadius == "string";
  }

See if there’s a property style.borderRadius and see if it contains a string (instead of undefined). If that’s the case, the browser (apparently) supports CSS border-radius.

Now I do not doubt that this approach works fine in the current crop of desktop browsers. It fails abysmally, however, on some mobile phones, as we’ll see in a moment.

Besides, this test does not prove anything about CSS border-radius. Instead it says something about JavaScript style.borderRadius.

Sure, these two properties are supposed to reflect the same bit of data, but what if they don’t? Suppose there’s a browser bug that doesn’t allow you access to style.borderRadius while border-radius works fine? Or vice versa? The test might return false positives or false negatives.

More in general, this testing methodology assumes that no browser will ever make a mapping mistake between CSS and JavaScript. That means that an entire category of bugs will never be discovered by such tests, and — worse — that the tests may generate false positives or negatives.

This is not just a random theoretical musing. I actually found such a bug. At least four mobile browsers will return a false positive when this testing methodology is used on font-style: italic.

If this methodology doesn’t work for one single browser, it is inherently untrustworthy. After all, any testing methodology must work everywhere, or it is worthless.

The font-style: italic problem

As I think I said before, I discovered that some basic CSS such as font-style: italic does not work in certain mobile browsers (Opera Mobile < 9 in mobile mode , Opera Mini, and Bolt). We’ll leave the whys and wherefores for another day, and concentrate on the aspect I tested last Thursday.

What I did then is change the test page a bit in order to include a simple JavaScript test:

<p style="font-style: italic" id="test">font-style: italic</p>
<script>
document.write(document.getElementById('test').style.fontStyle);
</script>

If a browser does not support font-style: italic, so the theory goes, style.fontStyle would be empty, too. The point is, it isn’t.

Two Opera Mobiles, Opera Mini, and Bolt all faithfully reported italic, even though they do not support font-style: italic (or, let’s put this more precisely, they do not use an italicised font for rendering the test paragraph).

These browsers do not support font-style: italic in any meaningful way, but an automated testing system based on JavaScript style.fontStyle would report that they do in fact support the CSS property. It would give a false positive.

This false positive conclusively proves that testing CSS compatibility by means of JavaScript does not work. (Remember, one single false result is enough to invalidate the entire approach.)

Testing CSS compatibility by means of JavaScript is methodologically unsound and should be avoided at all costs. CSS compatibility tests (and probably the JavaScript ones, too) must be done by hand, by creating a test page and looking at them. Automated systems are just not going to work.

As you may know by now, I’m currently heavily engaged inW3C Widgets research, so it’s no surprise that three out of four of my presentations treated this topic. As usual I’ve put the slides online.

At the urging of Jon Boutelle I became a SlideShare member and uploaded my presentations there, too.

This presentation overlaps with my recent Yahoo! one for about 40%, and it's somewhat more basic. (Still, it was the most advanced JavaScript presentation at the conference.)

By the way, the good people at Yahoo! have already published the video of my presentation; including a complete transcript (it's odd to read through it).

As I said during my VTM presentation, the Yahoo! one contains the solution to the focus/blur event delegation thing, as well as some information on events in the mobile browsers.

This presentation, too, has been taped and will be published online. I'll let you know when that happens.

I also caved in to Jon Boutelle's peer pressure and now publish my slideshows on Slideshare.net; including this one.

The presentation has been taped and will eventually be published online; I'll let you know when that happens.