Multiple files as an antipattern? Good luck with that.<p>If you use BEM, one of the many React style libraries, or any similar methodology for simulating local scope, any big problems with multiple files evaporate, and you get to reap the rewards of modularity. Granted, you still inherit styles from parent document elements, breaking modularity a bit, but for my purposes, it's close enough.<p>As a bonus, almost any perceived need to nest styles is also obviated.<p>On a side note, I found the tone of the article pretty obnoxious.
"Considering it’s a point of professional pride to avoid nested structures as much as possible in other languages..."<p>Nested loops can be bad. Nesting logic deeply in other languages is bad.<p>Nesting style rules that belong together, well, together isn't nesting as much as it is putting like stuff together.<p>I may create section.myawesomesection {...} and everything to do with the stuff in there is in there, not leaking out. I don't accidentally use a class name used somewhere else and globally change it, I don't change all global UL tags to be flat, inline, no list-style. I change them in context of section.myawesomesection.<p>Not to mention allowing me to put my breakpoints together in context (particularly useful with a mixin like breakpoint(small) or something).<p>Yes you can really go nuts with the nesting and create a giant pile of crap. But then that's you being a bad planner (not even going to say coder here, as CSS/SASS is more about planning than coding).
I have to disagree with the first two points and concur with the last two.<p>Modularity can be achieved in CSS with ease (with Sass or any other capable preprocessor) and I do it all the time and I haven't come across a problem like he cited in his prose. The extended «@import» keyword/statement handles this perfectly and you can do wonders with it, you just have to keep a mental record of the hierarchy in your head (You already do that with the order of <link> and <style> elements as well as the CSS individual rules within a single file) and aim for well encapsulated components that are as loosely coupled as possible to the surroundings in the markup and you will have a true piece of mind.<p>As with nesting, yeah this could be a source of annoyance and inconvenience but I usually set a ceiling of 3 levels deep maximum for any component with rare exceptions when the need arises but most of the time I don't exceed the 3 level nesting limit and the codebase is still very very manageable.
This article demonstrates that the author has not worked a large-scale web application. Modularity in CSS has been difficult to acheive, and there has yet to be a perfect solution. However, I'll gladly work with an intermittent solution. If I stepped into a project that followed these recommendations for building an app of scale, I'd likely go insane.
As the author says, in SASS, nesting that produces deeply nested selectors like `body#homepage header .navbar:first-child li>a` should definitely be avoided. However, you can do BEM style selectors quite neatly in SASS:<p><pre><code> .navbar {
&__element {
&__hover {
...
}
}
}
</code></pre>
which will produce a selector like:<p><pre><code> .navbar__element__hover { ... }
</code></pre>
This is a great compromise between readability, maintainability and performance.<p>Also, the first point about keeping all your CSS in the same file works for smaller projects. But on bigger projects, managing a 5000 line CSS file is a nightmare. Better to break your project into multiple files, and import them as mixins or straight includes. Again, using BEM-style CSS helps with that.<p>In the end, managing CSS is always a pain whatever approach you use. Too much of the advice on CSS doesn't talk about the context in which to apply or ignore the advice. What works for for a massive team working on a high-profile, big-budget, mission critical website will be enormous overkill for a small project with one front end developer.
I've recently started keeping my CSS together with the UI components that I create in React. Essentially doing what is being advocated here: <a href="https://speakerdeck.com/vjeux/react-css-in-js" rel="nofollow">https://speakerdeck.com/vjeux/react-css-in-js</a><p>It defies existing good practices, but once I tried it I quickly realized that things that are tricky in CSS are mostly trivial in JS (namespacing, dependencies, code elimination / minification, isolation, constants, the whole tooling in general etc.). As a programmer and not a designer, I also find it easier to reason about JS.<p>You end with something that looks very much like Web Components, but fully usable right now. In practice it means you can add a 3rd party component with "import TimePicker from 'material-ui/timepicker'", slap a <TimePicker/> into your JSX and you're done. See <a href="http://material-ui.com/" rel="nofollow">http://material-ui.com/</a> for a complete toolkit of React components created this way.
Using sass splitting files is not a big deal. The author is living in the past, component based CSS is becoming the norm. For more info I'd suggest reading about SMACSS by Jonathan Snook.
>A lot of web development seems to be about splitting things up into manageable chunks or “components”. [...] This doesn’t work so well for CSS.<p>I'm not a web developer by any means but I'm pretty sure there's a way to manage CSS "components" that then are compiled into a single, minified stylesheet, no?
Multiple files<p>Considering everything is global in CSS, the importing order isn't important. It only is when using Sass where you have variables and mixins that must be defined before using them. And with Sass, it's very easy to setup separate files that you import all at once in a single file. Structure example: <a href="http://tech.streethub.com/styleguide/css/app.html" rel="nofollow">http://tech.streethub.com/styleguide/css/app.html</a><p>Nesting<p>One of the biggest issue you encounter when writing CSS is _specificity_. Not only does nesting allow to match your Sass hierarchy with the HTML one, but it also naturally creates more specific selectors that saves you from keeping mind which rules are going to be applied.<p>Pixel units<p>Oh yes, using "em" is very elegant... but a pain in the long run. Font sizes need precise pixels to render correctly. Images need pixels for alignment. Borders need to be defined in pixels or end up disappearing. And you'll avoid crazy calculations with 4 decimals. I actually just wrote an article about it: <a href="http://jgthms.com/in-css-use-pixels-not-em.html" rel="nofollow">http://jgthms.com/in-css-use-pixels-not-em.html</a><p>Device breakpoints<p>Breakpoints aren't meant for _devices_ but for your _element's_ size. It doesn't matter how your layout will end up looking on a 320px-wide screen. What matters is how your element will look like until 500px, and beyond that. With Sass I have 2 responsive mixins: +from($breakpoint) and +until($breakpoint). That's all you need.
The no nesting thing is huge! We refactored a lot of CSS earlier this year and that was one of the biggest pain points. Coupling the structure of your template to your CSS makes changing things very painful. Nesting also creates ambiguous classes that have no obvious connection, consider the following:<p>.my-component {<p><pre><code> .header {
...
}
</code></pre>
}<p>You would just see header floating around in the markup, unsure of where it's namespaced.<p>Also I disagree that you shouldn't modularize your CSS. We now create a CSS file who's name corresponds with the class name.<p>/styles<p><pre><code> /components
my-component.css
</code></pre>
and in the markup<p><div class=".MyComponent-wrap"><p><pre><code> <div class=".MyComponent-title">
...
</div>
</code></pre>
</div><p>With CSS like that you always know where a style is declared, and the order of the classes do not matter.<p>More on the issue: <a href="http://nicolasgallagher.com/about-html-semantics-front-end-architecture/" rel="nofollow">http://nicolasgallagher.com/about-html-semantics-front-end-a...</a>
"Then, when I wanted to scale things up at a min-width breakpoint, I’d just adjust the root font size, upon which everything else is proportionately based."<p>The problem is that scaling everything up or down proportionally looks bad. <a href="https://css-tricks.com/rems-ems/" rel="nofollow">https://css-tricks.com/rems-ems/</a>
There is nothing wrong with nesting in SASS. As with anything in life you just have to keep thinking about what you are doing. Nesting too much or to deep can make things hard to maintain or debug, but you can't say 'nesting is evil' just because you think you are not supposed to like it.
The rationale from this post for not-nesting is incomplete and I personally think nesting has advantages (grouping markup together and mixins for example). Sure avoid the pyramid of doom and unnecessary nesting, but in general, nesting is not bad.<p>Aside, BEM is a nice pattern but doesn't need to be followed religiously, you could say the same for most patterns; put together the best for your project/problem you are trying to solve... and if you have time, understand all the design decisions behind a pattern in order to do so appropriately. imvho
I have been using a percentage value to set width size for four year, since the day I first used HTML. I used to get confused with pixel. Percentage provides me a better estimate always.
only recently started using less.js and thought nesting was helpful: i had a not-so-well organized css file, and systematic nesting quickly enforced a sensible grouping of statements.<p>also, if you want to change an id attr in your html, say, being thorough about nesting ensures that you only have to change your styles in one place. that's a small win for maintainability?<p>i agree that mixins are a much cooler feature of less/sass than nesting. it's not so much that avoiding nested structures is "a point of pride" in general-purpose programming languages (certainly not in lisp!) as it is that logical modularity makes stuff easier to read, maintain, and reuse.<p>and as a practical matter, i can see how nested styles could make things difficult to read if there are too many levels of indentation.
I have to disagree heavily with the idea that all CSS should be in one file. Therein lies madness. Use multiple files, and be <i>sensible</i> about it - scoping each file in a way that it won't overwrite other files.
the author seems to be missing what HTTP/2 brings to the table [1]<p>#1: <a href="https://http2.github.io/faq/#why-revise-http" rel="nofollow">https://http2.github.io/faq/#why-revise-http</a>