Tales from the Evil Empire : CSS

Orchard team looking for a new developer

Bertrand Le Roy — Mon, 23 Nov 2009 19:24:19 GMT

My team is looking for a new full-time developer. The project is to build a completely new open-source CMS based on ASP.NET MVC 2. It’s a lot of fun :)

https://careers.microsoft.com/JobDetails.aspx?ss=&pg=0&so=&rw=1&jid=9434&jlang=EN

querySelectorAll on old IE versions: something that doesn’t work

Bertrand Le Roy — Tue, 01 Sep 2009 01:03:13 GMT

In today’s post, I’m going to show an interesting technique to solve a problem and then I will tear it to pieces and explain why it is actually useless. I believe that negative results should also be published so that we can save other people from wasting time trying the same thing. So here goes…

A few days ago, a post on Ajaxian proposed a new version of a somewhat old technique to implement querySelectorAll on old versions of IE, using the browser’s native CSS engine. That sounds like a great idea at first, and the hack is quite clever. The idea is to dynamically add a CSS rule to the document that has the selector that you want to evaluate, and an expression that adds the matched elements to a global array.

When I read this, it reminded me of a similar approach that I had tried a few years ago. At the time, we were considering implementing our own selector engine (we had not yet decided to integrate jQuery to our Ajax offerings, which in the end made the whole effort moot) so we explored a number of approaches.

My idea was different in that it doesn’t use expressions at all. It does dynamically create a style rule, but instead of an expression, it just sets a non-existing “foo” style property to the equally arbitrary value of “bar”. It then scans the whole document (using the much decried and IE-specific but very fast document.all) and gets the computed style for each of the elements. We then look for the foo property on the resulting object and check whether it evaluates as “bar”. For each element that matches, we add to an array.

Here’s the code:

(function() {
    var style = document.styleSheets[0] ||
                document.createStyleSheet();
    window.select = function(selector) {
        style.addRule(selector, "foo:bar");
        var all = document.all, resultSet = [];
        for (var i = 0, l = all.length; i < l; i++) {
            if (all[i].currentStyle.foo === "bar") {
                resultSet[resultSet.length] = all[i];
            }
        }
        style.removeRule(0);
        return resultSet;
    }
})();

or, in minimized form:

(function(){var d=document;var a=d.styleSheets[0]||
d.createStyleSheet();window.select=function(e){
a.addRule(e,"f:b");var l=d.all,c=[];
for(var b=0,f=l.length;b<f;b++)if(l[b].currentStyle.f)
c[c.length]=l[b];a.removeRule(0);return c}})()

That’s 235 characters, which is not too bad (although not quite #twitcode small).

The first problem with that approach though is that because it’s using the native CSS selection engine in IE, it has the same limitations and quirks. That means no fancy CSS 3 (or even 2) selectors. It also means any IE bug will surface into the result set.

In other words, if you want more selectors than that, you will need to parse the selector string and branch off the code to another, more complete engine whenever something not supported is used. It also means that you need to know what is supported and what isn’t. That could be done through some dynamic discovery but doing so, we are getting into much complexity.

So limited as it is, how does it perform?

I ran the code in a SlickSpeed test (where I removed the selectors that it couldn’t handle) on IE6 and the good news is that despite the document.all scan and the current style computation, it’s more than three times faster than Paul Young’s implementation that got featured on Ajaxian.

But the bad news is that it’s also six times slower than jQuery:

I’m afraid a hack to use the native CSS selection engine of the browser is always going to be slower than an optimized pure JavaScript implementation (to be clear, I’m not talking about native implementations of querySelectorAll, but about hacks such as this which try to surface the feature on older IE versions that don’t have querySelectorAll). Somewhat counter-intuitive, but true.

End of story. Just use jQuery. :)

Glimmer: visually build jQuery animations and stuff

Bertrand Le Roy — Tue, 28 Apr 2009 18:35:29 GMT

If you’re still intimidated by jQuery or DOM manipulation in general, if you need to quickly build web animations, if you’re more a designer guy, if you think tooling makes sense, or a combination of the above, you should probably check out Glimmer.

In a nutshell, Glimmer is a visual tool that builds HTML animations, menus, tooltips on jQuery. It builds all the code you need (HTML, CSS and JavaScript with jQuery) at the click of a button.

Check it out!
http://visitmix.com/Articles/Glimmer-a-jQuery-Interactive-Design-Tool

CSS isolation: there has got to be a better way

Bertrand Le Roy — Tue, 14 Apr 2009 07:26:04 GMT

CSS can be a tricky thing. I’m trying to do something that I think should be pretty simple. Let’s say a page contains a section (e.g. an admin panel) that must be styled independently from the rest of the page, but consistently and predictably. The DOM and CSS for the main part of the page is undetermined (e.g. because it’s part of a user-defined theme). Of course, you could use iframes, which are about the only isolation mechanism in HTML but we can’t do this here because iframes are quite rigid in shape (they are rectangles), they make scripting the DOM more difficult and they pretty much require an additional round-trip to the server to serve their contents.

The real problem to solve here is that if the main CSS for the page defines very general styles that for example target all elements with a given tag name, and those styles are going to bleed into our specialized region unless we find a way to block that CSS from cascading down. Ideally, you’d have an attribute on the tag, something like inheritcss=”false”, but no such thing exists.

So the only way I’ve found to solve this problem is to write a stylesheet that explicitly resets the defaults for all properties and all elements. Here is an excerpt from the CssIsolation.css file:

.isolate *
{
    background: white none repeat scroll 0% 0%;
    border: 0px none black;
    border-collapse: separate;
    border-spacing: 0px;
[...]
    z-index: auto;
}
.isolate p 
{
    display:block;
    margin-top: 16px;
    margin-bottom: 16px;
}
.isolate strong, .isolate b 
{
    font-weight: bold;
}
.isolate h1
{
    display: block;
    font-size: xx-large;
    font-weight: bold;
    margin-top: 21px;
    margin-bottom: 21px;
}

This is lame for a number of reasons:

Defaults might vary from browser to browser (this is particularly true of fonts and sizes).
Some styles can’t be reset to defaults, such as default button styles (at least, not without using browser-specific styles that aren’t consistently available):
An exhaustive list of tags and style properties is sure to be wrong now or in the future (I did CSS 2, so it’s already outdated by CSS3).

Still, imperfect as it is, this is a solution that works reasonably well and can be improved as problems are found. The equivalent of that inheritcss=”false” attribute, using my isolation stylesheet, is to set class=”isolate” on the parent element of the section of the page you want to isolate. None of the styles defined for the rest of the page (which is defined just as usual, with no difference whatsoever) should bleed then.

Here a snapshot of my test page, where you can see, side-by-side, unstyled HTML and HTML with reset styles:

Differences exist but are quite subtle.

The HTML for an isolated section is defined like this:

<div class="isolate" id="isolated1">
    Isolated 1...
</div>

If for example the main style sheet defines the style of lists like follows, this style won’t bleed into any element that has the isolate class (on the right on the next screenshot), just because we set the “isolate” class on the parent element.

ul li 
{
    list-style-type: square;
}
ol li 
{
    list-style-type: upper-roman;
}

You can then style each of these sections independently by just qualifying each of the style selectors with the ID of the parent element. In other words, just paste “#isolated1” in front of each selector of the local stylesheet, if the id of the parent element is “isolated1”:

#isolated1 p
{
    color: Green;
    border: solid 1px black;
}

This style will override the isolation CSS because it is qualified by id, which always wins over styles that are only qualified by class:

I really wish one of you will tell me how stupid I am for not knowing about feature/hack X that is way simpler and gets you to the same place… There has got to be a better way.

The code for the isolation stylesheet, as well as the test pages, can be found here:
http://weblogs.asp.net/blogs/bleroy/Samples/CssIsolation.zip