Global scope, Namespacing & CSS
Protecting your CSS from outsiders.
Some smart people came up with new ideas to fix it like that: Jonathan Snook’s SMACSS or the clever guys at Yandex with their BEM methodology & syntax which I prefer and started to use in all my projects.
But with the rise of OOCSS and trying to be as modular and flexible as possible and to make our selectors short and concise, the problem seems still existant. For example take the media object Harry Roberts mentioned in his article about BEM; the syntax looks like the following.
It’s still prone to conflicts, cause maybe another developers or even a third-party API decided to use .media class, selectors will conflict and the last one will win — I’m not talking about specificity here, my rules are no IDs & max two selectors per rule. I’m trying to write simplest specific rules as possible -, so I’m assuming that this component is first class citizen in your CSS.
I’m in the process of writing a small framework to act as my starting point for any of the projects that I’m working on. So my solution for it was to create a fake scope. I achieved this by prefixing all my selectors with something like an your project initials, or your initials if you work alone, framework initials, something that you & your team can understand. This should be documented of course.
|_ <your prefix>
|_ media object
You shouldn’t be using different prefixes in your project, you will only use only one per project. For example lets take the same .media object above and apply this idea to it, assuming that we are working on “realmadrid.com” website. the new code will look like that:
And you will need to apply this to all of your project objects, the pros of this approach are:
- Your selectors are protected scoped from new selectors by third-party plugins/APIs or from new developers
- Easily you will understand if this code was written by you/your team or by someone else.
- If you work on multiple projects at a time, it’ll make it easier for you to understand which project you are working on with a glance.
The only downside I can think of now, it’s more verbose especially if you are going to use multiple classes on the same object like so. Which I stopped caring about anyway. Code readability is much more important
<div class="rm-media rm-media—wide rm-theme—green clearfix">
<!—— code ——>
<!—— code ——>
Yes I used .clearfix without a prefix cause it’s not an object class & most probably when it’s used by someone else it is a clearfix, if you want to be on the safe side maybe you can prefix helper classes with .h- or something if you like
I’ll be using this technique in all of my upcoming projects & let’s see, but I’m optimistic about this approach. Let me know if you have any ideas about this or how can I improve it more.
YouTube is doing the same.
- About HTML semantics and front-end architecture
- MindBEMding – getting your head ’round BEM syntax
- The Evolution Of The BEM Methodology
- A New Front-End Methodology: BEM
Update #2 (2016):
Currently I don’t use or recommend using BEM with big apps, I prefer functional/atomic CSS, CSS modules or CSS in JS with React.
These are useful links:
This was posted before on my blog.