loading...

Improve your CSS with these 5 principles

Adrian Bece on October 07, 2019

Writing CSS is really simple and straightforward, so why is there a need for principles and best-practices while writing CSS? As the project scope... [Read Full]
markdown guide
 

Adrian I have another principle that conflicts with some of your own, but I feel would solve some of the problems you're sharing.

Don't Unset Yourself.

That is – do not contradict a previous style that you have applied.

Your example:

.card {
  padding: 1rem;
}

.blogList__card {
  padding: 0.5em 1rem;
}

Would be much better served as:

.card { … }
.card--default { padding: 1rem; }

.card--blog-list, // OR
.blog-list__card 
{ padding: 0.5em 1rem; }

This way you do not have to worry about the order of properties to ensure that your classes work as intended. You only ever add styles, instead of setting and then unsetting them.

 

Nice overview - It's good to know the actual names of these tips (like "Low specificity"); that helps with remembering it :)

Also, didn't realize that browsers search for selectors from right to left! That's interesting... I wonder how much overhead it saves once you realize that - do you know of any studies / tests that show that?

 

Thank you. Glad you found the article useful.

Regarding the performance studies, I am not aware of any, but if you come across any, please link them.

 

Generally the number of elements in a DOM is not going to be a significant performance problem to anyone (especially as its a client-side issue and thus not clogging a shared server). But, you can mess things up if you're unlucky (or really careless) so there's one trick you can use to fix nearly all performance issues:

As browsers read selectors from right to left, the right-most one is the key to good perf. Make sure it is the one that excludes most of the DOM.

eg. if you have "#myid div" as the selector, this will look through the DOM and generate a list of all the div elements, and then will look through that list (which will be many) for any that have the myid id.

if you rewrite this to be 'div #myid' then it will look through the DOM for all elements matching myid and then look through that list (of 1) to find any that are a div.

guess which is faster and more efficient.

But as mentioned, chances are you won't have any perf issues unless you have a DOM comprised several thousand repeated elements, that also have the slowest selectors (pseudo-classes or *).

It also means that many levels in your CSS isn't a problem - because they all apply to reducing scopes, if your rightmost selector produces a small set to match, then there is no problem. You can have 10 levels of CSS selector and if they rightmost one is an ID or class that matches few DOM elements, its going to be fast.

stevesouders.com/blog/2009/06/18/s...

Thank you for the very detailed and insightful answer. I guessed as much regarding the performance and the worst-case scenario. In any case, I think that having a single selector is the best way to go in terms of performance, code readability and flexibility.

In any case, having several levels of CSS selectors brings up some other issues, as described in "Open/Closed principle".

 

"Writing CSS is really simple and straightforward" = BS.

CSS is getting better but it is still a mess. Brower compatibility probs, compiler-generated CSS, resets, browser pre-fixes, box type, and old legacy days from when they let print designer sit at the table to develop specs...

Oh ya and silly issues reading selector from right to left when we read it top to bottom and the browser typically reads everything else from start to finish . . . etc etc.

CSS is almost as much of a mess as JavaScript.

 

This article deals with the basics of how we write CSS (selectors and properties concept) and how to write flexible and scalable CSS, not browser compatibility issues, CSS compilers, vendor prefixes, etc.

 

I wasn't saying anything like that. I'm just saying that CSS is not simple and straightforward anymore. I still enjoyed your article though and look forward to seeing another.

Thank you for clarifying and I'm glad you've enjoyed the article.

CSS indeed had a messy history and the syntax suffered for it, but it keeps improving year after year.

 

I teach webdesign basics and this was incredibly helpful and gave me some ideas on how to approach things with my students. Specificity often is something that leave them scratching their head.
Thanks!

 

Thank you, glad you found it helpful. I wish my teachers would show me these best practices from the start.

 

Everytime i see BEM I can't stop thinking how ugly, inconvenient and repetitive it is.

 

That is very true for BEM, but generally it's not a problem if you don't nest classes more than 2-3 levels.

I sometimes combine BEM with the "old ways" in order to not have deep nesting of BEM on complex elements. Works fine, still namespaced (but you need to have control of the whole project and be reasonable enough not to write a global ".specificelement" class.

.block__element--modifier .specificelement {}

 
 

Nice. Thank you for sharing. I might use it as well on my projects

 

There is definitely some good takeaways, I highly recommend it.

 
 
 
code of conduct - report abuse