CSS classes

[lkrids]

I am a front-end developer and lately I have been reading a lot about css selectors performance and maintainable css.  Together all the articles seem to suggest when possible use at least one class for each rule set, and the corollary that all dom nodes that receive css style should have at least one class.  That means in css avoid ids, tags, descendant selectors, and basically all of these http://www.w3.org/TR/CSS2/selector.html#pattern-matching.  Do you agree with this?

[reedlauber]

Going all classes and no IDs and tags sounds like an overly dogmatic approach to me. I think maybe (MAYBE) if you're running a huge site with a ton of visitors, it might be time to see if you can trim just a little more performance fat off your page by simplifying a few descendant selectors to classes, but there are a lot of other considerations. I think basic maintainable, logical, readable code and code architecture are worth a lot - especially to a smaller team. I think a more sane approach is to know and understand those performance differences, know when it's important to use them in spite of maintainability, know to use them when it could go either way, and know when it's just not worth the microscopic benefit. Also, something to take into consideration is that without using element and descendant selectors, you're likely going to have to add a lot more bytes to the html to support all those class assignments. That might offset some of the gain in rendering performance. Finally, it might also be important to think hard about CSS3 enhancements that slow down rendering far more than other CSS performance issues. I would hate to see someone rewrite a whole app as classes-only, and then drench a page in shadows, gradients, and custom fonts. At that point, a few ID selectors isn't going to make much of a difference in your performance.

[Brian Moon]

I think you need to understand your document(s). If you have 400 A tags
like we do, you don't want descendant selectors like:

.content .sidebar a {
}

All A tags will be chosen from the DOM and their parents analyzed.
However, if you have very few A tags, it may not be a big deal. A tag
being an example. The same would be true of something like:

.foo .bar div {
}

Ids are still very usable. However, they are not RE-usable very easily.
I do not think they are bad for performance as much as they are bad for
maintainability.

Brian.
--------
http://brian.moonspot.net/

> <http://www.w3.org/TR/CSS2/selector.html#pattern-matching>. Do you
> agree with this?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Object Oriented CSS" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/object-oriented-css/-/Ml8SfDFStEYJ.
> To post to this group, send email to object-or...@googlegroups.com.
> To unsubscribe from this group, send email to
> object-oriented...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/object-oriented-css?hl=en.

[nicolechung]

I try to reserve ID's for javascript usage and (when possible) avoid them for CSS styling. 

I had a smallish site where I switched my ID's (for styling) over to CSS classes and it did make my stylesheet smaller and easier to maintain. And yes, my site did end up loading a lot faster just because I wasn't writing overly specific styles to override IDs. 

That being said, it would be a massive job on a bigger site to switch existing IDs over to classes, and there would be a lot of troubleshooting involved. Plus if you are working on a big site with a big team it would just be difficult to get so many people to adjust to not using IDs for CSS styling.

As far as other selectors...I can't see getting rid of pseudo selectors for :hover effects and there are many cases where you say, need to style a first-child differently from the rest of your page. 

[Matthew Browne]

I think the responses so far, taken together, serve to show that it's a question of balance, although you certainly want to favor classes over lengthy selectors. In many cases you can do without ID or deeply nested selectors entirely, but of course there are also plenty of times when they're helpful and make the code more concise and elegant, for example if you have section of a page that needs to override default styling and the CSS would most likely never need to be reused.

And the point about first-child is a good one - first-child and last-child are very handy.

Unfortunately I think this is one area where it's particularly difficult to give a cut and dried answer - just remember that when thinking about all the reusable "objects" (as in the first "O" of OOCSS) on your page you should generally be thinking in terms of classes, not complicated overrides or rules that assume a particular page layout/template.

--

You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group.

To view this discussion on the web visit https://groups.google.com/d/msg/object-oriented-css/-/R3t654Pxe1wJ.

[Reed Lauber]

Another opinion I'd throw out there about not over-using classes is that I think there's a really nice relationship between good, semantic markup, and tagname-based CSS. When we all moved to standards- and CSS-based layouts, we gained the ability to write nice, descriptive CSS like: navbar a { ... } or aside h1 { ... }. That relationship between markup and CSS gains us readability, maintainability, more readable markup (without IDs or classes), and most importantly, it makes it a lot easier to remove CSS as the layout evolves. When you create a class you are, by its nature, declaring that it is fair use anywhere that stylesheet is available. That makes it a lot harder to remove (or even alter), and this typically means we end up with CSS that grows and grows and becomes less maintainable. 

I worry that telling everyone - especially less advanced developers - that they should use classes only, encourages them down that path.

Similarly (but somewhat unrelated), I sometimes worry about preprocessors because I think they can encourage developers to write overly verbose CSS, since it's so easy to repeat values, instead of looking hard at what can be reused. That's what OOCSS is all about, to me. 

My approach is to do my best to figure out what is reusable and generalizable, and turn those into OOCSS-style classes. I find that between that, and more specific classes, I end up about 75% classes. The rest, I think usually is not a class for a good reason, and I prefer to leave it that way.

[Rick Lowes]

You may want to read Harry Roberts' (@csswizardry) excellent guidelines around CSS and also some of the links from this page as well - Harry's a big OOCSS proponent and contributor:

https://github.com/csswizardry/CSS-Guidelines/blob/master/CSS%20Guidelines.md 

@ricklowes