Opera passing the Acid 3 test

WebWebkit passing the Acid 3 testkit

While Opera Software technically won the race, Apple released nightly builds for everyone to run the test themselves. Anyway, I do not care about which rendering engine actually was the first to pass the test. I am just amazed by the effort both teams invested to meet demands of the test and so get their browsers closer to the web standards.
Also the agility of the browser vendors is impressive: it only took 15 days for the first rendering engine (Webkit) to pass the Acid 2 test and 23 days to pass the Acid 3 test.

Of course it will take longer to release the next stable browser version which benefits from the engine development (the first official Safari update came have a year after Webkit passed the test), but we can be sure that future browsers will have more standard support than ever.

IE always had performance problems with string operations. Even when Microsoft's developers promised to solve this problem, it existed all the time — until now. That is the reason why superior JavaScript frameworks have an option to replace all used strings with variables to avoid this browser weakness. ;-)
Anyway — I am very happy to see, that this huge issue is finally fixed.

If you run the SunSpider benchmark without the string tests, the final result looks different: the increase of performance reduces to 1.5. Do not get me wrong, I do not want to put down IE team's effort: they have done a fantastic work; not only in performance but also in standards support and they have included an excellent debugger. I just want to straighten out that most of the gain in performance comes "for free", as it derives from a bugfix for a quite old issue.

While today's support for web standards is pretty well, web applications are spreading like wild fire and web applications for mobile devices are getting more important, web browsers vendors are working hard on optimizing their products for speed and memory footprint.
This results in the fact that nightly builds of Webkit and Firefox are 3 to 6 times faster than IE 8. These are (and will be!) the products Internet Explorer is compared with.

There are interesting times ahead and I am looking forward to see the results in the final version of the browsers. :-)

We’ve decided that IE8 will, by default, interpret web content in the most standards compliant way it can. This decision is a change from what we’ve posted previously.

I hardly dare to say, but Microsoft's recent work got my respect. ;-)

Update:
On OS X you can run both versions at the same time. Awesome! :-)

Unfortunately there are some extensions which do not work with Firefox 3, since their authors have not tested and qualified them to work perfectly with the new version.

Luckily, you can easily install extensions, even if they are not qualified the new version.

1. Download the extension file to your computer.
2. Unzip the xpi file (it behaves like a zip file) and open install.rdf with your favorite editor.
3. Change the setting of em:maxVersion to 3.0 or higher (be sure that em:targetApplication is Firefox)
4. Save the file and restore the xpi file.
5. Open the extension from your local filesystem with Firefox 3 and install it.

Please note that using an unqualified extension is risky and can cause unexpected behavior and even browser crashes.

After the last "update" of IE 7 and the questionable communication policy in the IEBlog I am very happy to see that things can change. :-)
Thanks, Mr. Gates for bringing light into the darkness.

Anyway, how can IE 8 render the test correctly? At this moment the test is broken...
Ok, I have just seen their video and I guess they were working with the correct Acid2 test.

<span style="filter:Alpha(opacity=100, style=0)"></span>

and my text just looked blurry.

Text with ClearType enabled

Text without ClearType

The text appears blurry only if ClearType is enabled.

Did your noticed this behavior by yourself? If you have any experiences with the attribute filter in connection with ClearType, please let me know!

Some months ago I mentioned how to prevent the browser from selecting HTML elements. While I was working on an early prototype of a new functionality, I discovered an interesting pit fall in handling events in all browsers.
When I tried to move an HTML element, suddenly it was not moved on the screen. Furthermore it seemed that no mouse event was handled to my functions. I double checked that the event handles were assigned to the specified element and also checked the functions which should be called on the mouse events.
It was like something strange cut off the event handle and did not inform my functions about the mouse move. It took me a while to notice the strange new cursor which my Firefox showed. The browser showed a typically drag-and-drop cursor. By selecting the GUI element, I unnoticed selected some text which lay inside this element!
When you select text in your gecko-based browser you can drag it into places like the address, a textarea or create a bookmark based on the selected content. This is a nice feature, but it is important to know this internal method has priority against JavaScript functions which are bound to events.
I have created a little test page on which you can have a look at this behavior.

So, remember: internal browser events are fired before custom events.

Generally conditions start with [if] and end with [endif]:

<!--[if exp]>
 HTML block <![endif]-->

The typically use of this technique to figure out which version of Internet Explorer the client is using. An expression can contain the string IE, the version number, comparison operators (lt, lte, gt, gte), boolean operators (&, |, !) and parentheses ((, )).
With this constituents it is possible to construct flexible version number detections.

<!--[if IE]>

<link rel="stylesheet" href="styles_ie.css" type="text/css">
<[endif]-->

It is even possible to nest comments.

<!--[if IE]>

  <![if gte IE 5]>
<link rel="stylesheet" href="styles_ie5.css" type="text/css">
  <![endif]>
 
  <![if (gt IE 5)&(lt IE 7) ]>
<link rel="stylesheet" href="styles_ie55_and6.css" type="text/css">
  <![endif]>
 
  <![if IE 7]>
<link rel="stylesheet" href="styles_ie7_hacks.css" type="text/css">
  <![endif]>
<![endif]-->

• The menu bar is now visible by default.
• The Internet Explorer 7 online tour has updated how-to’s. Also, the “first-run” experience includes a new overview.
• We’ve included a new MSI installer that simplifies deployment for IT administrators in enterprises.

In addition,

[..] Internet Explorer 7 installation will no longer require Windows Genuine Advantage validation [..]

This is really disappointing. Instead of fixing some of the known bugs, this update only offers minimal changes on which I would like to comment.

1. What is the point in hiding the menu bar in appliations? I can see this trend on new applications from Microsoft like Media Player or Messenger, but why should hiding the menu bar be an advantage? So, re-enabeling the menu bar is a good decision, but why is it placed below the icon bar? This is violating the user interface guidelines and may confuse the users.
2. The online tour is located on Microsoft's servers. This does technicly not effect the browser application.
3. The new MSI installer will make it easier to rollout the IE 7 in company installations. This is a good aspect to expand IE's marekt share in enterprise enviroments.
4. If the installation does not require Windows Genuine Advantage it is possible to run it on all versions of Windows XP — even if they are not original. This procedure seems to expand the market share in the consumer area.

The aim of this update is obvious: expanding the market share at all costs. Microsoft even accepts users with non-orignal copies of Windows installing Internet Explorer 7. Anyway, if this helps users switching to version 7, we web developers should be pleased.