IE8b1 generated content support

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

1. First bug I've noticed was happening when you set position: relative for the generated content rule. The tab where you have this page opened dies. And then due to newly introduced crash recovery system, it tries to recover the tab, loads the page and dies again and so on — an infinite loop that you can't break. But the weird thing is that it doesn't actually die — it shows a window promting to select a debugger. The kind of window that appears when you have errors in your javascript code.

   here's the code sample:

   p:before {content: "test"; position: relative;}

   and the testcase.

2. I noted the bug and continued testing.

   Next thing I came up with was the fact that if the page doesn't have IMG/OBJECT/IFRAME elements or an image set as a background for an element, generated content is created after window.onload!

   Please have a look on the following testcases:

   1. Document contains None of the elements listed above, and generated content is not being generated till you press OK. It means that generated content is created after window.onload occurred!
   2. Generated content is created before window.onload as it should be in the following cases:
      an element has CSS background-image rule set, or page includes one of the elements: IMG,
      OBJECT or an IFRAME

   At this point I thought — wait — it's strange — all CSS rules were always applied before window.onload! Anyway, I just went on testing.

3. And then there was another strange thing — when you use content: attr(class), IE8b1 doesn't show the attribute value but shows null instead. But if you set the rule as content: attr(className), it actually shows the attribute value!

   Here's the testcase for this bug.

4. And another interesting thing is that expression doesn't work in generated content rules.

   Please see the testcase.

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 support in IE8b1

As I mentioned in the previous post, 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:

1. Get all paragraphs with the .note classname from one div? Not a problem – document.querySelectorAll('#myDiv .note');
2. Get all elements with some classname? Forget about document.getElementsByClassName slow kludges — use document.querySelectorAll('.myClass');
3. Get a link with .current classname from your UL-based menu? document.querySelector('#menu .current');

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.

Notes:

1. Unfortunately, IE8b1 doesn't fully implement the Selectors API spec. Here's the MSDN article quotation:

   Because Internet Explorer 8 does not formally support XHTML documents, it does not support the namespace features of the W3C Selectors API specification, such as the NSResolver parameter.

   But for websites where namespaces are not used it's not gonna be of any problem.

2. Another interesting issue that Selectors API spec raises is a potential history theft.

   Basically you can get all visited links hrefs and send them by AJAX somewhere (just a matter of getting a StaticNodeList of elements by doing document.querySelectorAll("a:visited")).

   Spec leaves it for the vendor to fix. So IE8b1 ignores the :visited and :link selectors when they appear in the selector query criteria.

Please see the Testcase

IEb81 initial tests

Some IE8b1 test results:

1. As earlier, alert([1,2,3,].length) shows 4 and 4^th element has undefined value.
2. Unfortunately no support for so wanted :last-child CSS3 Selector and buggy support for dynamically added elements that match :first-child and should therefore enforce layout to be recalculated. See PPK's testcase on quirksmode.org.
3. We can't set padding on html element for some reason — see testcase.

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.

Have a good weekend, people!