> No, the primary reason is that IDs prevent reuse.
Reuse of what, exactly? Selectors? Properties? My assertion is that if you need to re-use properties a lot then you should make use of a preprocessor framework and then use a combination of mixins or extends. Re-use of selectors is an unnecessary artefact of how OOCSS (and similar) suggest you should write your code.
> If you want to build a library of reusable components, IDs are obviously not what you want.
If you're building components that could end up on any page entirely outside of your control, I agree. But: horses for courses. It still has valid uses, and avoiding it entirely isn't necessary.
> Secondly, if you use IDs which were added for JavaScript or fragment links, you'll introduce some coupling which really shouldn't be there.
You're looking at this backwards: IDs exist for many purposes, not just CSS. Selecting elements by ID in JavaScript, or using a fragment identifier to link to within a page are just two other examples of how they can be used, and not considering the other purposes of the attribute is part of the problem (see also ‘CSS classes’).
> Same thing with JavaScript. If you need a class, you should add a prefixed one (e.g. "js-foo").
How does the developer benefit from writing the classname like this? Why is a prefixed classname any more informative to you than a selector that tells you a little about the context in which the element appears? I've actually come around to the view that if you're using this class to select on any other criterion than the semantic purpose of the element is wrong, and it would be more appropriate to use a data attribute to contain the hooks for additional behaviour.
Building blocks or legos. You create a library of these and then you just use them.
Soon, you reach a point where implementing new features/views doesn't require any new CSS. You just use what's already there.
As a result, the total number of rules is kept at a minimum, which helps with performance and also with maintenance.
>If you're building components that could end up on any page entirely outside of your control, I agree.
Well, I don't write every template/view/whatever.
>How does the developer benefit from writing the classname like this?
If you change the JS, you can freely add/remove those "js-" classes.
If you change the structure of the markup, those classes will warn you ahead of time of potential issues. They will also give you something for grepping.
Also, using those classes on the CSS side can be easily identified by tools.
Basically, it's just a naming convention which tells you something about the purpose of this particular class. In languages like Java, C#, etc. you also use naming conventions to communicate something useful. In CSS, I do the same thing. There is UpperCaseCamelCase, lowerCaseCamelCase, _withLeadingUnderscore, and x-prefixed. All of these things mean something specific.
Apart from reset/normalization and base styles, everything is written in the same mechanical style. This makes the code really easy to navigate. It's very organized.
> Basically, it's just a naming convention which tells you something about the purpose of this particular class. In languages like Java, C#, etc. you also use naming conventions to communicate something useful. In CSS, I do the same thing. There is UpperCaseCamelCase, lowerCaseCamelCase, _withLeadingUnderscore, and x-prefixed. All of these things mean something specific.
What does those four styles mean then, respectively? I'm curious.
Subtree root node, descendent, modifier, and not CSS.
A modifier changes one or several aspects to make it more suitable for a different purpose.
You can stick subtrees into the leafs of other substrees. There is no overlap or interweaving.
So, if you look at some node, you just travel the tree up until you hit the first UpperCaseCamelCase class. That's the structure this node belongs to. It's also the name of the partial.
E.g. this is the "bricks/_Pagination.scss" partial:
You have an accessibility issue in your example markup. Having links adjacent to each other without either non-linked readable characters, or an appropriate markup structure leads to screen readers reading out the numbers 1 2 3 4 in a "linked" tone, and it is impossible to distinguish that from a single link containing all four numbers.
That's why the web development best practice here is to mark up a list of links with a list. And before we had web standards people used to separate adjacent links with the | character, so at least screen readers would have the numbers read out in a link voice, and the 'bar' read out in a non-linked voice.
If your intention is to create reusable components, then it's essential that you're not introducing accessibility issues by default.
There's a second accessibility issue with the pagination. Why is the active page a link? What does it link to, considering that you are already in the view that should be that page. That feels like a link that does nothing. For a generic pagination, this feels like another accessibility issue to trip up developers.
Also, there's the obvious anti-pattern of using # as the href, instead of an actual URL. That leads to developers assuming that everything is handled with JavaScript. It's easy to fix in documentation, by putting in realistic looking URLs in there.
Good examples of documentation are ones that demonstrate good practice, and not encourage bad habits.
I know, good documentation is not easy. That's why we have to be careful of falling into these sorts of pitfalls. Especially when developers have no choice but to rely on documentation being correct.
I think most of the advocates for OOCSS would agree with you that preprocessors make them better. But the principles they're proposing are made better by preprocessors, they're not invalidated by them. Preprocessors let you get the benefits of reusable components without polluting the DOM with classnames. Which is better than plain OOCSS in most cases. But OOCSS allows you to have those reusable component benefits without tying you into a specific preprocessor (or any at all), and that is a benefit as well, even if you personally don't think its worth the semantic tradeoff.
Basically
OOCSS with preprocessor => reusable components + minimum DOM impact
OOCSS without preprocessors => reusable component + potentially messy DOM
CSS without OOCSS => potentially clean DOM + potentially non-reusable CSS
Reuse of what, exactly? Selectors? Properties? My assertion is that if you need to re-use properties a lot then you should make use of a preprocessor framework and then use a combination of mixins or extends. Re-use of selectors is an unnecessary artefact of how OOCSS (and similar) suggest you should write your code.
> If you want to build a library of reusable components, IDs are obviously not what you want.
If you're building components that could end up on any page entirely outside of your control, I agree. But: horses for courses. It still has valid uses, and avoiding it entirely isn't necessary.
> Secondly, if you use IDs which were added for JavaScript or fragment links, you'll introduce some coupling which really shouldn't be there.
You're looking at this backwards: IDs exist for many purposes, not just CSS. Selecting elements by ID in JavaScript, or using a fragment identifier to link to within a page are just two other examples of how they can be used, and not considering the other purposes of the attribute is part of the problem (see also ‘CSS classes’).
> Same thing with JavaScript. If you need a class, you should add a prefixed one (e.g. "js-foo").
How does the developer benefit from writing the classname like this? Why is a prefixed classname any more informative to you than a selector that tells you a little about the context in which the element appears? I've actually come around to the view that if you're using this class to select on any other criterion than the semantic purpose of the element is wrong, and it would be more appropriate to use a data attribute to contain the hooks for additional behaviour.