4 ms·

What also helps a lot is to keep in mind that classes are for classifications (categories) and id's for identifications (unique). I see a lot of people using c

by huuu 10y ago

What also helps a lot is to keep in mind that classes are for classifications (categories) and id's for identifications (unique). I see a lot of people using classes to create unique styles for specific elements. This will make a mess of your stylesheet. Also try not to think too much in subcategories (nested classes) because it will remove flexibility from you stylesheet. For example: .button {} .button.text-center {} is used to create buttons with centered text. But now you need to create another class for other elements that need centered text. So instead this would be more flexible: .button {} .text-center {} In both cases you can use <element class="button text-center">.

tangue 10y ago
Sadly using only classes is now considered a "Best Practice" and some employers forbid id or are considering it as an antipattern [1] resulting in a clusterfuck of classes in the html. But best practices in CSS changes so often that I wouldn't be surprised if people starts to use id again in two or three years. [1] https://github.com/airbnb/css https://github.com/airbnb/css
- dexterdog 10y ago
  That's why just like not growing sideburns I'm not listening to this trend either. Use classes where there may be multiple. Use ID when it's a Highlander.
- madeofpalk 10y ago
  ids do have some fortunate side effects, like magically creating global JS variables.
akavi 10y ago
I disagree. If you're stuck using vanilla CSS, that's probably the best you can do. But if you have a preprocessor that allows mixins (and god, you really should), I find life is made infinitely better if you have very specific class names, ie. every element with a given class name should be styled exactly the same. Any styling that's shared across multiple classes (both in the literal sense of a selector, and in the sense of "grouping of alike elements") belongs in a mixin that gets mixed in appropriately. If you're certain that's unique, you can use ids if you like, but I don't really see the point. Plus, like all feelings of certainty in programming, the future will love mocking you for having it. (On reflection, the same frequently applies to OOP classes...)

by huuu 10y ago

tangue 10y ago

Sadly using only classes is now considered a "Best Practice" and some employers forbid id or are considering it as an antipattern [1] resulting in a clusterfuck of classes in the html. But best practices in CSS changes so often that I wouldn't be surprised if people starts to use id again in two or three years. [1] https://github.com/airbnb/css https://github.com/airbnb/css

dexterdog 10y ago
That's why just like not growing sideburns I'm not listening to this trend either. Use classes where there may be multiple. Use ID when it's a Highlander.
madeofpalk 10y ago
ids do have some fortunate side effects, like magically creating global JS variables.

akavi 10y ago

I disagree. If you're stuck using vanilla CSS, that's probably the best you can do. But if you have a preprocessor that allows mixins (and god, you really should), I find life is made infinitely better if you have very specific class names, ie. every element with a given class name should be styled exactly the same. Any styling that's shared across multiple classes (both in the literal sense of a selector, and in the sense of "grouping of alike elements") belongs in a mixin that gets mixed in appropriately. If you're certain that's unique, you can use ids if you like, but I don't really see the point. Plus, like all feelings of certainty in programming, the future will love mocking you for having it. (On reflection, the same frequently applies to OOP classes...)