Realistic Web Time

The first beta of Internet Explorer 8 is available. Get it at http://www.microsoft.com/windows/products/winfamily/ie/ie8/default.mspx. Like the Opera beta's, it's not finished and is intended for developers to test with. Don't rely on it as your main browser as undoubtedly many things will change (for better and worse) in the next beta.

Check it out. And check out Opera 9.5 beta too.

Shift browser compatibility problems from the page authors to the browser makers.
Is it possible?

Opera has been doing it a long time, due to Internet Explorer 6 dominance. Dean Edwards has given the web community the possibility to have IE6 behave more like IE7, and it looks like he isn't going to stop at IE7.

But is it possible to create a css/js/... file to downgrade browser compliance from IE7 to IE6?

Why would we want that?
It would give Microsoft the ability to break radically from their broken box model, which they have forced upon authors for too long.

As Eric Meyer put it: "Besides which, we’ve written enough scripts and hacks to make our pages adjust to browsers. Isn’t it about time browsers started adjusting to our pages?"

It would need to be a js/css/... file like the browser.js in Opera. I don't mean the site targeting, but the auto-updating, without users being even aware. Instead of site targeting, I feel browser targeting isn't so bad. We could even uphold the right practice, which nobody (almost nobody) uses, to use standard targeting and upgrade the browsers.

I propose (until I become smarter) an open source effort, supported by browser vendors and others (commities like Wasp, ...) to create a universal implemented system for down- and upgrading browsers to each other and to the standard, based on a target put in pages.

1. We need to find out which technology is best for this task.


2. We need a system for every browser to get the files (cached or not)


3. We need to establish and agree on which base to choose


4. We need browser targeting


5. We need an agreement on one https site to host every file for every browser-browser combination

In practic, this means browsers (including mobile browsers) will have to download the file from the site when they encounter the browser targetting tag (just like css files are downloaded now) and then cache it so no download is needed the next time. Like DNS, every week (or another time period) the cache is invalidated. Next time a browser target is encountered, the browser needs to check whether the version they have is the same as the version online. Of course, no files may be downloaded when the current site is a https site.

We will need a system to make sure people don't become dependant on bugs in the down/upgrade files. I propose a weekly update check to this end. If a bug is discovered in a file, the decision process for update/inclusion/... must implement a breaking element in that file until a real solution is found. No bug dependance due to different bugs for the same functionality every week.

...


Use open source javascript, dom and css to make ie8 (and other browsers) backwards compatible with ie7.

The entire IE problem is IE, as is known by everybody. Given that, how do you solve it? By creating a new IE. But then all kinds of _intranet_ pages break. A browser developer cannot detect whether such a page was meant for IE or for Opera (chances are it was IE-targetted due to market share).

Now MS has determined the upgrade costs for page devs too high. So the problem is stated easily:

1 every exiting page must work as it did in IE7.
2 every new page must work by IE8 rules*

* This is, pages developed by hand or by tools older than the IE8 release date.
Point 2 is needed because IE7 is broken. Point 1 is needed because browser vendors are scared for pages to break, see firechicken, which is/was a kind of feature-complete-but-buggy implementation.

Both arguments will also hold for IE8, Opera 9.5, Firefox 3, ...
How to solve the mess? No more vague specs, no more bad implementations and no more bug-dependent sites. This is all very unlikely to happen. The truth is the only real (and badly documented) reference for authors are the browsers themselves. That's why the choice for browser targetting may not be so bad, for browsers with enough market share.

The problem for Opera: almost no page will include an Opera target, and the sites will not be updated for new browser versions, because it isn't necessary. This means Opera would have to spend hours analysing IE quirks.

I am an Opera user, and I believe is Firefox is not on the right track, and the current IE is broken. However, at the moment I believe the browser targeting is the best option to move forward.

Extra: feature based css won't work, because, if it existed a lot of years ago, IE6 would claim to support the css 2 box model and new switches would have to be invented for the firefox box model (firefox 2 + acid2, anyone) and then opera would need yet another switch, leading to browser sniffing like it occured (and still occurs) in javascript.

On that account, edge should be removed. Even CSS 2.1 might still change a little and therefor no current browser can be a definitive implementation and no author can code to the spec and be certain his/her page is edge. They will test it (probably in firefox) and conclude it is edge. Edge is _impossible_. You are predicting the future when you use it. You will need to change your page in the future and you will test it in some of the future browsers. It isn't much of an effort to update the numbers.

In the end we should ask ourselves: how can we make web time a reality again, without ever breaking older pages.

If people do want to edge to ship, it should be renamed and called crash, signalling this mode allows browsers to crash on the content, if it is coded to an unfinished standard or to a previous browser version. Of course the browser shouldn't really crash but show something like the Opera error when a non-xhtml document is send using application/xhtml+xml.

Concerns:

- Footprint: well this is a legitimate concern.
- Cross-version interactions: this will be solved in some ugly way.
- Maintenance burden: this is false. The same burden as the current one can be chosen.
- Security / Footprint: this is a strange issue. It is fully legitimate and has a very logical answer. The current specs are insecure (see same domain policy) and the entire nature of the web makes phishing sites easy. How do we solve it? Phishing filters. How will they solve security? Like antivirus and antispyware, antibadsites will be incorporated into browsers, like antiphising today. This may even be developed by Symantec and the likes, not by the browser makers.

This targeting (and every other switch) actually forces browsers and spec writers to offer something in order to persuade businesses and authors to redo their page for the next browser.

No new features means no updated pages.

Concerning mobiles: the targetting in effect makes mobile browsing different than desktop browsing (which it has always been). So in the long term companies are going to come across the issue: IE10 is out, but we target IE7 and the mobile community only accepts IE10mobile. Will we rewrite our current pages for IE10 and compatible with IE10mobile, or are we going to make 2 pages?

So who will lose? The open web, standard bodies, all small ones (mobile, Opera, Safari, ...)
So who will win? current market share holders: IE and firefox, bussinesses that don't target mobiles.

(Summary coming up)
To be continued ...