Always prefer classes is a bad practice

[spiritix]

First of all, nice article! I agree with most of it, only that "Always prefer classes" is not obviously always a good practice. This is mostly due to the bad performance of class based selectors.

Regarding CSS, the rendering time of ID-based selectors compared to class-based selectors is < -5% in modern browsers, so quite insignificant. However, in JavaScript (especially using selector engines of libraries like jQuery), the performance difference of using $('#my-element') vs. $('.my-element') is massive. And since this article mostly affects large-scale applications, the browser rendering time should not be neglected.

Additionally to that, there are other things to consider, for example, IDs have a higher priority over classes. So if your element has an ID and a class, the styles of the ID will override the styles of the class. If you'd use two classes instead, it would depend on the specified order of the classes which is pretty bad. Finally, it is easier to understand a layout that uses classes and IDs, simply because you don't have to check if an element may be used multiple times or not.

The major downside of using IDs is of course, like already correctly mentioned in the article, that one must not use IDs like id="box", all IDs must be namespaced like id="myapp-mymodule-box".

[jaasum]

This is mostly due to the bad performance of class based selectors.

If you want to use an ID to hook your JavaScript into you can do so. You don't have to share classes used for styling with your JavaScript hooks.

<div id="jshook" class="csshook"></div>

The two can simultaneously exist, and I'd prefer it this way. It's more semantic.

IDs have a higher priority over classes. So if your element has an ID and a class, the styles of the ID will override the styles of the class. If you'd use two classes instead, it would depend on the specified order of the classes which is pretty bad

Yes, which is why you want to avoid the use of IDs. Embracing the cascade and understanding specificity is precisely why css architecture matters. Using IDs will result in more complex and confusing overrides.

simply because you don't have to check if an element may be used multiple times or not.

I'm not sure what the benefit here is. Why arbitrarily limit yourself with CSS hooks? The use of IDs with JavaScript, again, I can see the benefit of and agree with. The assumption that CSS hooks need to follow the same rules seems without merit.

[jareware]

Hey @spiritix, thanks for the feedback!

I'd have to say I agree with @jaasum here, in that it's totally possible (and even preferable) to have co-existing selection schemes along with the one you use for styling. The most common ones I'm aware of are:

• Using a separate class namespace (or indeed even ID's) for hooking in JS functionality
• Using data-attributes (e.g. data-test="user login") or ARIA attributes for driving a test suite

The idea with both is to decouple styling (CSS) from functionality (JS), which is a commendable practice, just like @jaasum already pointed out.

However, in JavaScript (especially using selector engines of libraries like jQuery), the performance difference of using $('#my-element') vs. $('.my-element') is massive. And since this article mostly affects large-scale applications, the browser rendering time should not be neglected.

The rendering performance gains from optimizing CSS selectors have repeatedly been classified as mostly snake oil by noted experts in the field, for example:

sweating over the selectors used in modern browsers is futile; most selection methods are now so fast it’s really not worth spending much time over. Furthermore, there is disparity across browsers of what the slowest selectors are anyway. Look here last to speed up your CSS.

-- Enduring CSS author Ben Frain

“Used in moderation pretty much everything will perform just fine from the style matching perspective.”

-- WebKit code developer Antti Koivisto

The difference in speed between an ID and a class is almost totally irrelevant.

-- The original CSS Wizard Harry Roberts

That is not to say there aren't performance related issues with CSS, just that selector performance is at the very bottom of the list of optimizations you should consider.