Current State of Affairs

Web folks are a clever bunch, though. If browser support for CSS won’t give us a way to target a particular element, a common solution is to make classes do the heavy lifting for us. Going through files to add class="text" to every text input is an all-too-common experience for web designers.

Adding the classes allows us to target elements on all browsers, but is labor-intensive and potentially error-prone. Moreover, if your site includes content (like comments or blog posts) which will entered by users, you have no easy way to ensure those classes are added appropriately.

A Glimmer of Hope

jQuery is one of several great javascript frameworks which have burst onto the scene in the past year or so. One of the reasons jQuery has gotten a lot of attention from web designers is the way it allows you to select elements – in many cases, jQuery selectors are identical to CSS selectors. jQuery is also extremely extensible. If there’s functionality you need which isn’t provided by the core framework, you can easily add it via a plugin (or by extending jQuery directly).

In the course of a recent project, I used jQuery to add a first-child class to some <li> elements in our top navigation, to shore up IE6 CSS support without having to alter the markup. After seeing how easy jQuery made that, I realized it’s be possible to write a plugin allowing any browser supported by jQuery capable of supporting all CSS 2.1 selectors. So I wrote SuperSelectors. It goes through your site’s stylesheets, dynamically adding classes to elements so that even IE6 can bask in the glow of properly supporting CSS selectors like ul li:first-child li:nth-child(odd) a:hover.

Pencils out

Before we can start to determine which elements ought to have classes added, we’ll need a way to access each stylesheet being used by a given page. Fortunately, the document.styleSheets array does exactly what we want. Unfortunately, we have to incur a little bit of overhead here. Since browsers will silently excise rules they don’t understand, we have to re-request the CSS files via javascript, and parse those for matches.

Now, the fact that jQuery supports CSS selector syntax comes in really handy. We can pass the matching CSS rules directly to jQuery, and add classes appropriately. Then, any browser supported by jQuery can properly target elements, even useful-but-not-broadly-supported CSS rules like ul li:first. All we need to do to have classes added to match any of the rules in our CSS is include jQuery and the SuperSelectors plugin, and add the following javascript:

$(document).ready(function() {
  $(document).superSelectify();
});

This is a great start, but some of us are maintaining sites with established conventions for element classnames. Maybe you’re working on an educational site, and the child is already reserved for another context. No problem. SuperSelectors will allow custom classes to be passed in, while still providing sensible defaults. You can override any (or all) of the default classnames. If you need to alter the class attached to child elements to be child-element, your javascript would just change to be:

$(document).ready(function() {
  $(document).superSelectify({childClass: "child-element"});
});

Attribution needed

What about special cases which fall outside the normal advanced selectors? Maybe we need to have styles applied conditionally, based on attributes. For example, maybe the links in your file download list should have an icon based on the extension of the file they’re pointing to. CSS 2.1 allows us to target elements based on attribute values – we can even match against substrings within the attribute value, which is a perfect fit for finding the file extensions of our links. The number of potential choices for attribute selectors alone is more than we can reasonably build into a single plugin, but fortunately SuperSelectors supports arbitrary selectors through the additionalElementHash attribute. This can be done with or without overriding the default classnames. A setup which addressed the file-type requirement mentioned above would look like this:

$(document).ready(function() {
  $(document).superSelectify({additionalElementHash: {jpeg: 'a[href$=".jpg"]', pdf: 'a[href$=".pdf"]', doc: 'a[href$=".doc"]', gif: 'a[href$=".gif"]', xls: 'a[href$=".xls"]', png: 'a[href$=".png"]'}});
});

A little more effort than the no-argument invocation, but that will enable matching almost any elements you can think of – you’re only limited by jQuery’s selector support, which is one of the best out there.

Hovercraftiness

It’s probably time to acknowledge the elephant in the room – specifically, the fact that IE6 only supports the :hover pseudo-selector for anchor tags. Through the years, there have been a variety of approaches to add this in, including Peter Nederlof’s whatever:hover. This is all well and good, but it’d be nice to be able to have one-stop shopping for all our CSS needs. Fortunately, jQuery makes it easy for us to add this functionality into Super Selectors. Declare your :hover rules normally, add an equivalent rule using the hover class, and SuperSelectors will take care of adding / removing the classnames from elements on mouseover.

Faster, faster

Things are really shaping up nicely. Any browser which jQuery supports can now use virtually any legitimate CSS selector, but we can still do better. If we know which advanced selectors our site will need to support, it seems wasteful to have to re-request all those CSS files, and then scan them for matches. In fact, on slow connections, or with sufficiently-large amount of CSS, users could see a page without the added classes for a fraction of a second, similar to the old Flash of Unstyled Content bug.

SuperSelectors makes it simple to avoid the unnecessary request/parsing overhead and display properly-classed markup right away. You just need to pass in all your selectors via the manualSelectors attribute, as a comma-delimited list. As with everything else, it can be used solo or in combination with any other arguments.:

$(document).ready(function() {
  $(document).superSelectify({childClass: "child-element", manualSelectors: 'div.example > ul, ul.sample li:first, input[type="text"], input[type="password"]'}});
});

For complex CSS needs, this may require a fair amount of work. However, this approach saves us from having to re-request and parse all the CSS files in use. Consequently, it will be much faster – especially for sites with large (or large numbers of) CSS files. Check out the example.

One caveat

SuperSelectors does a lot to help enable better CSS selector support across browsers, but it can’t do everything for us. We still need rules in our CSS which use the classes SuperSelectors will add.

Because Internet Explorer will discard the entire rule if it doesn’t understand one of the selectors, we do have to do a little duplication in our CSS. That means that, instead of

div.example > ul,
div.example ul.child {
background: #0f0;
color: #f0f;
}

You should write:

div.example > ul {
background: #0f0;
color: #f0f;
}

div.example ul.child {
background: #0f0;
color: #f0f;
}

In Closing

The goal of SuperSelectors is to make it possible for all of us to start using CSS 2.1 selectors in our everyday work. It doesn’t have CSS3 support (yet), but SuperSelectors will automatically benefit as jQuery adds support for CSS3 selectors.

You can download SuperSelectors as a zip or tarball. Github also hosts the official SuperSelectors repository, if you’re interested in helping make SuperSelectors even better.

An example will probably help make the issue more clear.

The structure we’ll use is simple. A “container” div wth an explicit width will contain all our content. Each test case will be a “holder” div, which contains the paragraphs with negative margins to pull them beyond the boundaries of both parent elements.

In a standards-compliant rendering, elements can be caused to extend beyond containing elements, through the use of negative margins:

Internet Explorer, of course, plays by different rules. Let’s start by looking at IE6:

When no width is set for the holder div, the paragraphs with negative margins are shown to extend beyond their holder div, but are clipped at the edge of the container div. However, when we explicitly set the width of the holder div to 100%, the paragraphs are clipped at the edge of the holder div – they’re not allowed to extend past any of the containing elements (more correctly, the content does extend past, but it’s inappropriately truncated, as though overflow: hidden; were declared on holder divs).

The same results are obtained in our second result set. When we declare the width in pixels, the paragraphs are clipped at the edge of the holder div. When we explicitly declare the width to be auto (same as the default property for block-level elements), content is clipped at the edge of the container div:

With Internet Explorer 7, we get yet another curveball. IE7 does properly honor the negative left margin in all cases, regardless of whether (or how) we declare a width for the holder div. The right negative-margin isn’t so lucky. It still gets truncated exactly the same way as IE6:

It’s almost like the dev team created a unit test for left negative margins and decided they were all set.

To their credit, the IE8 team has fixed right negative margins, based on the current beta:

So, if your site has sizable numbers of IE users (which, I think, is most of us), be aware that negative margins can cause unexpected consequences. Explicitly declaring overflow: visible; on holder and container has no impact on the resulting page renders. For the LSN launch, I ended up using relative positioning to achieve the desired affect.

Have a different workaround? I’d love to hear about it. In the meantime, here’s the testcase I put together.