Jonathan Weiß

Congratulations to Opera Dektop Team at Opera Software and to the Webkit team at Apple for successfully mastering the Acid 3 test.

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.

The appearance of HTML elements is set by it's style properties. They define dimensions, colors, margins, borders and much more.
All styles which are defined in the style attribute inside an element are available to JavaScript in the style attribute of it's corresponding HTML element object. The value of each property is mapped from HTML without being translated. This means, that a color value of red becomes a string containing red and not the computed value rgb(255, 0, 0).
All styles, including styles from a class definition or inherited styles from a parent element, can be retrieved using the standard way window.getComputedStyle(<element>, null) or the Microsoft way <element>.currentStyle[style property]. This values are also translated to the computed value.

Why am I talking about HTML elements appearance? Well, imagine you want to clone an HTML element not only with its content and child nodes, but also with its appearance. To match the original element, every single style property, which applies on it, has to be copied to the clone.
Now that we know so much about computed styles, it should be no problem to get it done, right? Well, this task is not as easy as it first seems.

Stumbling block no 1: background-color

When an element has no background color, its computed value of background-color is transparent. So far so well, this makes sense, as this information is used by the browsers rendering engine.
To get the visible color for this property, you have to walk through the element's parent elements and fetch the first background color value that contains an usable color value.

Stumbling block no 2: text-decoration

A real head-scratcher for me was the text-decoration property. The value of this property is not inherited, but it's child elements are rendered, as if it were so!

»This property is not inherited, but descendant boxes of a block box should be formatted with the same decoration (e.g., they should all be underlined).«
CSS2 Specification

So all child elements inside an element with a text-decoration style property it will return none for text-decoration — even if you can see their text-decoration. As the property is not being inherited it also is not overwritten and an elements can be rendered with several different text-decoration values.

 
<span style="text-decoration:underline;">Oh
  <span style="text-decoration:overline;">noes!
    <span style="text-decoration:blink;">Teh
      <span style="text-decoration:line-through;">
      blink
      </span>
      tag
    </span>
    is
  </span>
  back!
</span>
 

Oh noes! Teh blink tag is back!

Note that not all browser support the blink value. Luckily... ;-)

I wonder why the specification is that way. Is there some reason for that? I am not aware of any other property that behaves like this.

To retrieve the rendered value, you have to walk through the element's parent elements, as you have to do for the background-color. When the parents have more than one different text-decoration value, it is not possible to clone the element's appearance without adding some extra elements around it.

Stumbling block no 3: text-decoration color

And as if that were not enough trouble with the text-decoration, here is one more thing:

»The color(s) required for the text decoration should be derived from the 'color' property value. [..] The color of decorations should remain the same even if descendant elements have different 'color' values.«
CSS2 Specification

 
<span style="text-decoration:underline;color:red;">lorem
  <span style="text-decoration:overline;color:green;">ipsum
    <span style="text-decoration:line-through;color:blue;">
      dolor
    </span>
    sit
  </span>
  <span style="color:purple;">
    amet
  </span>
</span>
 

lorem ipsum dolor sit amet

The completely match the element's style, you have to add one parent element for each different text-decoration property that also contains a color style property whose color will be applied on the text-decoration line.

The quote

If you are wondering about the quote in title: this is the first line from the Book of the Blind which appears in Blizzard's great game Diablo. I played it for ages when I was younger. :-)
When I realized that I could see a property, that is not visible to JavaScript (at first glance), this poem was brought back to my mind. Here it is, at full length:

I can see what you see not
Vision milky – then eyes rot.

When you turn they will be gone
Whispering their hidden song,

Then you see what can not be –
Shadows move where light should be.

Out of Darkness – out of mind,
Cast down into the Halls of the Blind!

Have you ever seen the icons for servers in the network at a bigger size?

Details about some server

Details about a Windows server

Nice icon, right? ;-)

When the first benchmarks with the Internet Explorer 8.0 Beta 1 came out, I was curious to see how much better IE would be compared to it's predecessor.
If you look at Apple's established SunSipder JavaScript benchmark, you will find that IE 8 is about 4.5 times faster than IE 7. First of all, this is great news for all web developers, But if you look carefully, you will notice that IE 8 benefits most from the results in the string section.

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. :-)

I can not believe this! Microsoft just U-turned their IE 8 strategy:

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. ;-)