Attribute selectors have the worst performance of any selector. Coupling that with the =~ operator is even more cause for concern. This is why classes and id exist.

I'm not sure, but from the post it's actually ~=.

The =~ variant is used in Perl and Bash as a regex matching operator.

No, :nth-last-child(n) has the worst performance of any selector.

span:nth-last-of-type(2n+1):not(div) > span ?

Edit: I reversed my edits to maintain proper history.

Actually, I spoke to soon. Since selector engines work right to left, this would first narrow down the list of elements to all the spans in the document. Assuming thats a fairly small percentage of the overall tags in the document, this selector runs at .0023 ms on my MBP w/ 8 GB or RAM.

Sa'll good.

Edit: For the record, bGriz edited his comment, making my comment invalid.

Edit (2): Thanks!

Definitely fact.

Yea, thats slower for sure.

Not a chance, browsers can optimise lookup for ids and classes (or even elements by name) because they have spec-defined semantics, and they can be preprocessed based on those semantics (e.g. used to key maps). Custom attributes have arbitrary semantics, so they can't be fit into such a static structure.

Technically nothing prevents browsers from inferring specific behaviors from the way a custom attribute is used, and dynamically generate shortcuts (e.g. key objects by attribute name, value or computed value), but I doubt any existing browser does so, so you get a "universal selector" behavior: every element of the DOM has to be scanned and processed to apply the rule.

And it's not exactly an easy problem, it's essentially equivalent to auto-generating (and tearing down, since elements, attributes and CSS rules can be added and removed on the fly) database indexes except you've got way less usage to rely on (for cost/benefit estimations), and way less usage time to recoup your investment.

I imagine if it is optimized, using data attributes will be the most likely route. There's probably already benefits (and thus it may already be done) to cache which elements have specific data attributes set. Combining that with a lazy indexing of values of matching attribute selector rules on elements with matching data elements on first match may yield non-horrible performance.

Using data attributes is even less likely to ever be optimised as data attributes exist specifically to store browser-opaque programmatic content.

I imagine data attributes are already optimized in some respects (probably not as selectors though), since their intended usage is slightly different than other attributes. I only contend that if any type of attributes are likely to receive special treatment in the future (besides those already designated as so, such as id and class), data attributes may be a likely candidate. Then again, due to the lack of constraint on the value of the data tags, that would make future optimizations much harder (which may have been your point).

Maybe just using class-* as a namespace would be best, both from a point of clearly identifying intent and not conflicting with any current valid html attributes (AFAIK).

Right. Then the question is: does it matter enough in performance that the user might notice it? If it's just a few ms i would be willing to trade that for better maintainability of the CSS. Or maybe you could use some kind of preprocessor that would translate the attributes to regular ids/classnames.

Performance of long CSS files isn't really the (major) concern —its how many _elements_ are being traversed (size of the dom) that really effects CSS-selector performance.

After a certain point the number of selectors does affect parsing time and selector matching time, in a very significant way.

Performance has improved a bit since this post but it's still relevant: http://perfectionkills.com/profiling-css-for-fun-and-profit-...