Things Worth Noting About CSS Attribute Selectors

The main reason CSS attribute selectors have been avoided up to this point is their complete lack of support in IE6. But since IE6’s market share is continuing to slowly but steadily decline, it’s becoming safer to use them.

I’m not going to go through the basics of CSS attribute selectors and their syntax. There are some pretty good resources explaining them, which I’ll link to at the bottom of this post. So if you don’t have at least some grasp of what this CSS feature is all about, please check those out first.

This article will go a little further and focus on some interesting facts and bugs surrounding attribute selectors that you may not have known.

You Don’t Have to Specify an Actual HTML Element

Normally when you see examples showing attribute selectors in action with accompanying code, you’ll see something like this:

a[style] {
  color: red;
}

The example above contains a very specific target: HTML anchor elements (represented by <a>) that contain the exact attribute “style”, with one or more values present. But that specificity is not required. You can also do this:

[style] {
  color: red;
}

That’s perfectly valid CSS, and allows you to use the attribute selector in a more general way.

UPDATE: As rightly pointed out by Ricardo in the comments, when you don’t reference an HTML element in the selector, you’re essentially using the universal selector (so evidently, [style] is the same as * [style]). For performance reasons, this kind of filtering should be avoided.

“id” Is Not Equal to #id

Suppose you have the following HTML:

<div id="box"></div>

You can target that element via CSS in many ways, and two of those ways directly involve the id element. The obvious way is:

#box {
  width: 400px;
}

But you can also target the element quite specifically using an attribute selector, like this:

[id="box"] {
  width: 400px;
}

Both methods shown above will target the box just fine. But according to CSS specificity rules, an ID selector has more weight than an attribute selector, so be careful when using the attribute selector in this way, as it’s not as specific as it appears.

To be honest, I think it would be next-to-impossible to have a situation that required that you use the attribute selector to target an element via its ID. But I think it’s good to keep this kind of thing in mind because it reminds us that CSS does have a natural cascade wherein element targeting is decided based on specificity.

You Can’t Target User Agent Attributes

HTML elements sometimes have default attributes with a default value. For example, take the following HTML:

<form action="index.html">
<fieldset>
<input />
</fieldset>
</form>

Although the above HTML form code is woefully lacking any substance, it’s perfectly valid HTML5 and XHTML strict. Two missing attribute/value pairs are of particular note: The method="get" on the <form> element, and type="text" on the <input> element. The defaults for those attributes are the ones I just mentioned. Although the user agent will serve those attributes and their respective values as defaults, and they’ll even appear in your developer tools as existing values from the user agent, you can’t target them using attribute selectors.

So, if you intend on relying on attribute selectors, be sure to explicitly declare in your HTML the exact attributes and values required for you to target them in all supporting browsers.

IE7 Can’t Target the “style” Attribute

Although IE7 does technically offer support for attribute selectors, its support is buggy, and it will not recognize the style attribute. This is quite a drag, since one of the reasons you might want to use attribute selectors is to target elements that have inline styles. Using a combination of the attribute selector and the !important declaration, in most supporting browsers you could override inline styles. But this will fail in IE7.

Of course, if you know what elements are going to have inline styles, then you could just use a different selector to override those styles, and it will work in IE7, but it won’t work if you use the style attribute in your selector.

<

p>This will fail in IE7:

a[style] {
  color: blue !important;
}

Value-less Attributes Can Be Tricky Across Browsers

Since HTML5 allows minified attributes, or attributes with no value (like disabled instead of the redundant disabled="disabled"), it will become more common to see this style of coding. But it should be noted that you may get different results in some browsers if you actually target the attribute with the implied specified value in the CSS.

For example, if you had an input element with the disabled attribute set to the implied “disabled” value, you might target it with the attribute selector in a number of ways, as shown below:

[disabled=disabled] {
  color: #ccc;
}

[disabled="disabled"] {
  color: #ccc;
}

[disabled] {
  color: #ccc;
}

[disabled=""] {
  color: #ccc;
}

input[disabled] {
  color: #ccc;
}

To give you an idea of how the above (all of which is valid CSS) behaves in different browsers:

• Opera 9.2 will accept all of the above examples, and will also accept disabled="true" to target the element in question
• IE7 will only match the element in question when using the last syntax example
• IE8 will not accept the fourth example with the empty quotes, and in my limited testing even caused some funky behaviour (I’ll have to do some further testing and see if that’s a weird unknown bug or something)

Case Sensitivity is Tricky Across Browsers

If an attribute has a case-sensitive value (as in the case of ID values), Firefox up to version 3.5 (in some cases) and Safari up to version 4 (in all cases) will target the value while ignoring the case. So in other words, in Safari 4, if you had and element with an ID of “myValue”, you could target it using any of the following selectors:

[id="myvalue"] {
  width: 500px;
}

[id="MYVALUE"] {
  width: 500px;
}

[id="myVALUE"] {
  width: 500px;
}

[id="Myvalue"] {
  width: 500px;
}

None of the above selectors should target the element in question, but evidently they do. As mentioned, this behaviour also occurs in certain versions of Firefox, but not as often as it does in Safari.

CSS3 Adds New Attribute Selectors

In CSS3, the following CSS selectors are now available:

The “starts with…” attribute selector, shown below, is identified by the characters ^=

a[href^="http:"] {
  color: blue;
}

The “ends with…” attribute selector, shown below, is identified by the characters $=

a[href$=".pdf"] {
  color: red;
}

The “contains…” attribute selector, shown below, is identified by the characters *=

div[class*="primary"] {
  clear: both;
}

Interestingly, while the bugs mentioned earlier still apply to these newer attribute selectors, the support for them across browsers is the same as the CSS 2.1 attribute selectors. So that means all attribute selectors (bugs aside) are supported in IE7+, Firefox 3.0+, Safari 1.3+, Chrome 2+, and Opera 9.2+. That’s not too bad.

Can They Be Used?

As always, with buggy stuff that isn’t completely cross-browser, just do the usual:

• Consider potential maintainability and performance issues
• Consider your known/potential audience for the project in question
• Test like your plane’s going down

Some Links for the Basics and More

• Attribute Selector on SitePoint’s reference
• CSS3 Attribute Selectors on SitePoint’s reference
• The Skinny on CSS Attribute Selectors on CSS-Tricks
• The official spec for attribute selectors in CSS2.1
• The official spec for attribute selectors in CSS3