Principles we use to write CSS for modern browsers

A bit meta, but I need this off my chest: I love how this document starts off saying &quot;this is for react apps&quot;. IMO every discussion about CSS coding standards needs to start with context.<p>A lot of old CSS lore came from people who build websites. I mean those fairly uninteractive things, focus on content. Blogs, restaurants, newspapers.<p>Building an application that happens to use the DOM as their UI toolkit is totally different. The whole &quot;reuse the same classes but with different content&quot; thing that CSS classes were designed for becomes less important, and &quot;reuse pieces of <i>behavior</i>&quot; makes a lot more sense.<p>There&#x27;s probably more domains or subdomains that warrant their own CSS best practices. But I&#x27;m totally tired of a blog designer and a react app coder fighting on HN about how the other one is doing it wrong, when really they&#x27;re just solving different problems.

IMHO, naming conventions such as SUIT, BEM, OOCSS and the like are NOT a good practice, but merely a workaround for dealing with the limitations of a global namespace.<p>My preferred solution are CSS Modules[1], Vue&#x27;s scoped styling[2] or something similar.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;css-modules&#x2F;css-modules" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;css-modules&#x2F;css-modules</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;vuejs&#x2F;vue-loader&#x2F;blob&#x2F;master&#x2F;docs&#x2F;en&#x2F;features&#x2F;scoped-css.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;vuejs&#x2F;vue-loader&#x2F;blob&#x2F;master&#x2F;docs&#x2F;en&#x2F;feat...</a>

Some thoughts:<p>- Good CSS design needs zero !important statements. Fix your specificity or your component architecture if you have a need to use !important.<p>- DRY is a good thing, not a bad thing. Maybe straight CSS isn&#x27;t quite there yet but...<p>- Why not use the tools at your disposal to aid in development (and DRY) such as SASS&#x2F;LESS?<p>- Flexbox will be great once IE dies the well-earned death it deserves.<p>I&#x27;m very happy the author had great success with their setup. What works, works. But I hesitate to assume that just because it works without using DRY principles or other tooling, it means you shouldn&#x27;t.

&quot;.ComponentName-descendentName&quot; nested inside &quot;.ComponentName&quot;?<p>Remember kids, the cascade is TEH B4DZORS - so always include everything you would have gotten from it in every class name. <i>headdesk</i><p>Solidly delivered on the &quot;no DRY&quot; premise. Maybe they should coin a new acronym like &quot;WET&quot;: &quot;Write Everything Thrice&quot;

A random brain dump prompted by this statement: &quot;No DRY. It does not scale with CSS, just focus on better components&quot;<p>All programming involves resolving a conflict between two different principles and a lot of the fiercest disagreements are between people that weight the importance of these two things differently:<p>1. Reducing repetition<p>2. Reducing dependencies and side effects<p>The language and it&#x27;s tooling&#x2F;ecosystem can affect the importance of these.<p>The project&#x27;s complexity, rate of change and lifespan is also a factor that might push you one way or the other.<p>But anything that helps one of these harms the other.<p>Thoughts?

&gt; Flexbox is awesome. No need for grid framework;<p>Yes, great, if you can ignore all the IE users. Is that what &quot;modern&quot; means?<p>I&#x27;d love to use flexbox where I work, but it&#x27;s just not feasible to give up all the customers we would lose.

Plug for test-driven CSS: <a href="https:&#x2F;&#x2F;github.com&#x2F;jamesshore&#x2F;quixote" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jamesshore&#x2F;quixote</a><p>I&#x27;ve experimented with it on a green field project and got promising results. Found I could refactor my CSS with confidence.

I agree with the Flexbox and DRY principles, but it&#x27;s weird to still rely on arbitrary naming conventions like SUIT when CSS modules have been around for a while now.<p>Naming things has always been difficult, especially in CSS where it can lead to merging&#x2F;overriding&#x2F;precedence issues. <i>Not</i> having to <i>think</i> about what CSS class names are either available or possibly conflicting is a benefit from CSS modules that increases productivity by an order of magnitude I&#x27;ve rarely seen in CSS, especially in large codebases.<p>You&#x27;ve got a button and want to call it &quot;button&quot; and style it using &quot;.button&quot;? Go ahead. It will only inherit styles if you <i>explicitly</i> say so. The global namespace remains healthy for each component you write.

Personally, I very much dislike using CSS classes unless required. I prefer having a clean markup with classes used only where they make sense.<p>For a context, I somehow can&#x27;t wrap my head around writing something like:<p><pre><code> &lt;div class=&quot;nav nav-inverse nav-hide-xs&quot;&gt; </code></pre> when `&lt;nav&gt;` makes more sense. Sure, if you have a case with alternate &quot;inverse&quot; navbar, go ahead with a class `&lt;nav class=&quot;inverse&quot;&gt;`.<p>About the flexbox, ah, well, even now they have undefined behaviour on several elements such as a `fieldset` [1].<p>[1]: <a href="http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;28078681&#x2F;why-cant-fieldset-be-flex-containers" rel="nofollow">http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;28078681&#x2F;why-cant-fieldse...</a>

FWIW, I&#x27;m using Angular (1.x) on a project at work, rather than React. One of the things I did recently was take the CSS file used in the project (&quot;Few Pages App&quot;, rather than SPA, which <i>had</i> a common .css file), and turn it into an Angular (javascript) &quot;directive&quot;.<p>I wish I had done this earlier. I have no &quot;compile&quot; step, it&#x27;s just straight js plus the framework. However, I now have a mechanism to use variables for any (new) stuff with repeated settings, inserted into the rest of the text in the &quot;&lt;style&gt; ... &lt;&#x2F;style&gt;&quot; template.

I&#x27;ve developed my last 5 projects (corporate websites with many different layouts) with SASS + Foundation 6 an no naming convention. Instead I relied on nesting selectors.<p>I can behave and usually not go deeper than 4-5 levels. It&#x27;s a really neat way unambiguously tell a CSS rule where it should belong to. For example I can create a<p><pre><code> section.hero-block{ &#x2F;* things inside are scoped *&#x2F; } </code></pre> CSS selectors who live outside are pretty basic, utility style ones, they exists on one level, so they can be easily overwritten by the scoped ones if needed.

So, I don&#x27;t do any front end work in my day-to-day, so this may be a stupid question. This article starts out with how CSS gets a lot of negativity. What alternatives are there? Do browsers understand anything but CSS for styling?

I think an important thing to note here is that this individual&#x27;s team is very small. If you have a small team that closely collaborates then scaling things which take discipline (like CSS) becomes vastly simpler.<p>CSS is difficult because it takes so much effort to do things the &quot;right&quot; way. It requires a good set of linting and testing tools or constant vigilance to maintain a correct, robust system.<p>As the codebase or team grows the difficulty of that task increases. That, to me, is why CSS often viewed in a negative light.

Recently I got into functional CSS:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;chibicode&#x2F;react-functional-css-protips" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;chibicode&#x2F;react-functional-css-protips</a>

Funny how all the original markup and languages are becoming the machine code of the web. No one writes js anymore, just compiles into js. No one writes css anymore, just SASS -&gt; css. Html? Nope, directives or shadow dom.