On the other hand, my HTML tends to be a bit more complex, so I avoid the use of id except in rare cases where it’s absolutely needed.

I don’t mind being a hybrid of the old and the new so long as I know I understand all the new if I ever need to make a sudden switch.

Specificity matters a lot when you work in a team or when you come on to work done by another team. Its crucial you understand specificity and I’m not one for picking up and using whatever new fandangled naming convention is out right now however if you study up on ITCSS BEM (aka BEMIT) & CSS namespacing It will radically change the way you write CSS for the better. I was very much against BEM when I came across it, now I’m fully converted to it having seen how much issues specificity was causing us in work on large projects with a range of skill levels all pitching in over time. No system is perfect ITCSS and BEM certainly are not but their much better than traditional ways of working with CSS.

It will be a joy to use CSS on large projects. Follow people like Harry Roberts (CSSWIZARDRY). Oh and you’ll come across OOCSS, its a nonsense that doesn’t work in the real world, forget about it. OOCSS teaches us to be bone DRY which will cause all manner of issues down the line. Being just DRY enough is good enough….apply common sense.

Hi Brad. My main advice: don’t bother worrying about naming conventions like BEM or things that sound fancy like OOCSS etc, however popular they may seem. Also don’t worry about Sass. Just make sure you understand how specificity works. Discussions about ‘CSS architecture’ are mostly bikeshedding (and there is no clear best way), but if you really want to read something:

https://adamwathan.me/css-utility-classes-and-separation-of-concerns
https://www.smashingmagazine.com/2016/11/css-inheritance-cascade-global-scope-new-old-worst-best-friends/
http://nicolasgallagher.com/about-html-semantics-front-end-architecture/
https://csswizardry.com/2012/05/keep-your-css-selectors-short/

Main advice: keep specificity as low as possible, use classes a bunch, don’t use IDs for CSS.
So that example could be
.sidebar li {} (which is easier to overwrite later on if need be without the need for !important)

Actually this flaw (JS dependency) could be solved in future, as there is discussion about creating new tag, shadowroot → https://github.com/whatwg/dom/issues/510

That’s absolutely true, and a very important consideration. Perhaps you have some components that rely on JavaScript for their functionality – their very raison d’etre relies on javascript. For these things shadow DOM is great. You certainly wouldn’t style every element on a page with shadow DOM – which perhaps I should have made more clear!