weboholic.de

Много ясно, че ИЕ-потребителите не си актуализират браузъра. На кого му се рестартира два (!!!) пъти?

I’m so happy about the great news today that I don’t know what to say … :) :)

Official anouncment and some people’s reactions.

I welcome this decision and applaud it. It really shows Microsoft’s efforts towards openness and interoperability. This news just might turn my personal image of Microsoft from evil to good.

Hey bartender, let me get a beer for Chris Wilson, Bill Gates and all the great guys and girls from the web development community that helped with this issue.

In case you’ve missed it, you can warm up here, here and here.

I’ve realized today, that it’ll be a long time till “edge” is default setting.

Let’s just examine the problem from Microsoft’s corporate point of view. Don’t forget that IE has still the largest market share and back then when IE7 came out it was even larger. But IE7 is supposed to be a better browser than IE6, why did Microsoft lost users? Because IE7 “broke the web”. By being more standards aware. And users didn’t blame the poorly written web sites nor the authors of those sites but the software. Many downgraded to IE6, others switched to Firefox or Opera. Truth is Microsoft lost “something” by bringing out a new browser release. And they obviously did learned from their mistake. This is the reason for the switch and this is also the reason, why “edge” is not going to be the default setting any time soon.

This is sad because backwards compatibility slows down the progress. But it’s also nice because it ensures accessibility.

I like about the solution that it’s a simple one. The <meta>-tag should save us real work of crafting ie6.css or ie7.css or anything similar. But only if IE8’s adoption rate is high enough, which I doubt. However what I don’t like about the whole story is the mere fact that out there are a lot, and I mean a lot, of lazy web developers that rely on old design patterns like table-based layouts, inline styling and scripting and spacer.gif. Those developers will be adopting standards at even slower rates. Now … this could mean more contracts for real web developers but on the other hand: Why pay more and wait longer?

And this is the real issue here and what the discussion should be about: How is Microsoft planning to remove old rendering modes? On what rates, under which conditions? Dean actually already asked the very same question:

Tell us what your real concerns are and we will try to help.

Thinking about the whole story today I’ve realized how right Dean is and how wrong I was yesterday. My statement might have been true, but this just makes the switch more dangerous: Where is our Web going to be in 2 or 3 years? Still IE6? No, thank you Microsoft, you can keep it for yourself.

John Resig also makes some perfectly good and valid points about the <meta> but in terms of JavaScript. Eric Meyer suggests for javascripters to continue and to expand object detection or browser sniffing. Now have a look at this sample code and tell me what do you think of it:

… People seem to forget that the internet is big — really big — and the number of pages written to match what the spec wants, rather than what IE displays, is rather small. Furthermore … people would blame IE and not the web developer.

Now although it’d be nice for the world to be perfect … the sad truth is that there’s a real world out there, with real people other than web developers, and Microsoft has to make IE work for them, even if this means opt-out backward compatibility.

– Leszek Swirski

I just want to add that unfortunately there are a lot of web developers out there, that are unaware of specs, semantics and best practices. They are definitely not going to be drilled about IE8 “breaking the web”. So I’m for this version targeting. But I really wish “edge” would be default rendering if no <meta>-tag is found.
Update 26.01.2007: I’ll vote against if given the chance.

In addition to the first part of screenshots of the Slick Speed test suite I’ve been able to get my hands on a Konquerer 3.5.6 running on Kubuntu Feisty.

on Linux (kubuntu feisty)

Konquerer 3.5.6

Default install. 383KB, 1000×1190.

Prototype and mootools throw an error on every single selector. dojo on Konquerer is comparable to dojo on Firefox on Linux and is the fastest one along with ext. However the winner this time is jQuery: it throws only one error, like cssQuery, but is twice as fast.

Final Notes

Note that the jQuery team released the new 1.1.3 version just a few days back and selector speed is improved by the amazing 800% (!!!). This is one hell of improvement. I haven’t made new tests on my own, be aware. I will be just giving a calculation of the improved time, next to the measured one.

So I’ve decided to make a simple error and time count, but excluding the double Firefox 2.x install. In parenthesis is given the result without Konquerer:

• Prototype: 48 » 6326 (10 » 6312)
• jQuery: 46 » 34813(45 » 32689)
• jQuery 1.1.3, improved by 800%: 46 » 4351.625 (45 » 4086.125)
• mootools: 53 » 5156 (15 » 5150)
• ext 60 » 6925(55 » 6405)
• cssQuery 11 » 64219 (10 » 60550)
• dojo 39 » 4747(36 » 4195)

While making that count I’ve made one discovery: every library struggles with the same selectors on the different A-graded browsers. Another one interesting fact is that cssQuery offers the same browser support on all participants, even on IE5.5

There are no winners in this case study, because each library has its own uniqueness and greatness. Besides, all of them are comparably fast and offer a comparable amount of supported selectors. Now let’s go back to the real thing – coding on top of them and not comparing them!

on Windows

Firefox 1.5

A fresh install. No extensions. 396KB, 1000×1224.

Firefox 2.x

A fresh install. No extensions. 400KB, 1000×1240.

A bunch of extensions: ~25. 399KB, 1000×1235

IE 5.0

MultipleIE install. 156KB, 1000×679.

IE 5.5

MultipleIE install. 530KB, 1000×1452.

IE 6.0

MultipleIE install. 404KB, 1000×1221.

IE 7.0

Default install. 384KB, 1000×1221.

Opera 9.1

Default install. 392KB, 1000×1261.

Opera 9.2

Default install. 399KB, 1000×1242.

Safari 3 beta

Default install. 484KB, 1000×1132.

Observations on Windows

All libraries behave equally fast/slow on the different Firefox installations. Except jQuery and mootools on my default FF install. This could be caused by GMail Notifier, which is checking my mail every minute.

IE7 improves speed by factor 2. Frustrating is that IE5.5, IE6 and even IE7 return different results on the * selector compared to other browsers and compared between the libraries.

Opera 9.2 is slower than 9.1.

Safari is in beta and is a freshman among Windows browser, so results are “just for fun”.

Prototype, mootools and dojo are the winners. I am somehow disappointed by jQuery.

on Linux (ubuntu feisty)

Firefox 2.x

A fresh install. No extensions. 375KB, 1000×1190.

A bunch of extensions: ~25. 375KB, 1000×1190.

Opera 9.2

Default install. 325KB, 1000×1192.

Observations on Linux

Opera is the faster one on my Linux box, but it took an awful long time to load the official test page.

Both Firefox 2.x profiles, clean one and one with a bunch of extension, behave quite equally – there are no speed improvements by factor 3 like mootools on Windows.

I couldn’t find any trident or WebKit browsers for ubuntu, but if you know of any feel free to drop me a line and I will run test once again.

We have the same winners – prototype, mootools and dojo.

Final Notes

Observations

Overall: libraries are running faster under Windows.

Locally I’ve tested also MochiKit – it threw a lot of errors.

Download the Shots (CC BY-SA)

Download SlickSpeed on Windows & Linux (~4.8MB).

Update: Note, that the Konquerer screenshot is not included in the archive. Download it separately.