Some IE8b1 test results:

IE8b1 intitial tests

But I really enjoy Selectors API implemented in IE8b1. It was the second browser to support this right after Webkit. I will describe the support and prepare some testcases in the next post.

I've tested generated content model in IE8b1 quite thoroughly, have found quite weird bugs and here's what I've come up with:

Of course I can only guess but my feeling is that IE8b1 doesn't have proper support for the generated content, it's rather done by a hook somewhere firing off the function that generates the content. All these four bugs have something in common - debug window (that's usually shown for javascript errors); generating content after window.onload in some cases; reading class attribute value by its DOM name (className). Basically it's all about javascript.

And I can't help thinking that IE8b1 uses some hidden javascript code to support generated content. And this functionality is triggered by some hidden event like DomContentLoaded.

And if so I would be really happy if they could give us access to this handler :)

Selectors API and IE8b1

As mentioned above, IE8b1 introduced support for very powerful DOM accessing concept - Selectors API. It is still a W3C working draft, but I bet that as IE and Webkit already support it, Presto and Gecko will soon have it as well.

So what do we have? As per the spec, we have 2 methods: .querySelector() and .querySelectorAll() which can be applied to any HTMLElement and based on he parameter (CSS selectors string) provided return an Element or StaticNodeList populated with elements matching the provided CSS selectors. Bottom line, you give it CSS selector, they return you matching element(s).

It provides you with a new flexible way to select elements in DOM. We can do any weird and wonderful stuff we want with the power of JS combined with the flexibility of CSS selectors:

So generally we don't have to iterate over huge StaticNodeLists anymore - it's done natively and very fast (much faster then by JS libraries). Please see the testcase prepared by Webkit authors to measure their Selectors API support - it works in IE8b1 except for CSS3 Selectors block (IE8b1 doesn't support CSS3 :nth- and :last-child selectors).

Bottom line, Selectors is a way to find elements in DOM. All browsers know how do it already when they parse CSS rules and find elements to which these rules have to be applied. So it's just an existing browser functionality exposed to the developer. And we have to keep in mind that if browser supports a CSS selector, it will allow you to query for this element using Selectors API. And obviously if there's no support for some CSS selector, you won't be able to get this element using Selectors.

For example, as IE8b1 doesn't support :last-child CSS3 selector, you can't style such elements in CSS and you can't query them using Selectors.


Attribute selectors

Both [class=myclass] and [className=myclass] work in IE7/IE8. The last one can be used as a CSS hack to target those browsers, but I would still recommend using conditional comments to target different IE versions.

If you look at the testcase, you will see that both [class=test1] and [classname=test2] selectors work. When I saw className working, I immediately tested other DOM properties like nodeName. Unfortunately, it didn't work there - here's the testcase. If it did, if there was such a way to access not HTML attribute but DOM properties from CSS selectors, it would be really weird but interesting.

Generated content

When I was testing it, I noticed that if you want to get element's class, you can't use content: attr(class) rule, you have to use content: attr(className). It's obvious that this is a DOM property name rather than HTML element's attribute.

This violates the standard which clearly says that attr(X) must return an attribute string value for the element matching the selector. It also violates the standard by returning null value for not existing attributes.

This behavior also gives us some strange options. Please see the testcase.

I don't know if it's a bug or a feature - none of the Microsoft documents on IE8 describes this behaviour, so I don't know if this is going to be fixed or not; but it may be used in some interesting ways.
E.g. using outerHTML IE-only DOM property I rebuilt the testcase for the attribute selectors bug mentioned above. If you have IE8, don't wait to have a look. And please have a look at another interesting thing - again it's IE8-only as it uses attr(nodeName) function to show every element's nodeName.

During testing I've noticed some more bugs with generated content:

IE8 and expressions

Internet Explorer keeps on changing. One example is expressions - their support is dropping from version to version. In different versions of IE this testcase produces the following output.

So IE started filtering values in expressions since IE6, and now IE8b1 in both modes doesn't even allow you to use object property accessors (both dot and square brackets notations - see testcase). So in IE8b1 in expressions you can only use plain string values in your expressions (which is not handy at all) or call externally defined functions.

I can't think of any other reason for disabling this except for protecting from potential XSS threat that I described in the previous post.

Also in IE8b1 expressions are not reevaluated on mouseover event (see testcase), but onscroll still fires document.recalc (this again seems to be left intentionally in order to support all cludges that were invented to implement for example non-existent position: fixed CSS rule).

Bottom line, if you have expressions used in your CSS code, don't wait - separate all the stuff you do there to JS functions and just call these functions from your expressions.

comments powered by Disqus