Interesting article that summarizes quite well the criticism aimed at CSS you come across periodically on the web.<p>The way CSS is written amongst the web developers and designers depends on whether you have easy access to the HTML or not.<p>If I work on a Tumblr or WordPress theme, I can strip down my HTML structure to the minimal and work my way around with <i>context</i> selectors (for example having global styles for my .post-title, and add specific adjustments for #sidebar .post-title or #single .post-title).<p>But if I need to send HTML/CSS templates to a client's developers, I will need to turn my components into reusable and <i>independent</i> objects (like in a Bootstrap file), that will carry their style while being moved around to prevent them from being altered by the context in which they end up. I would also increase the density of my HTML to cover for all the possible cases, and give the developers some flexibility.<p>As a front-end developer only working on HTML and CSS, keeping content and style completely seperate is the goal I aim for everytime I start a new project. But maintaining such a division is hard when working with developers because they generally don't touch the CSS at all. So I need to provide styling directly into the HTML because that's what developers generate and have their hands on. I don't blame the working process for making me write a different kind of CSS. It's just how it has to be done. Neither type of CSS is better than the other: they are just suited for 2 different situations.<p>And that's why I don't believe there is a perfect way to write CSS. There are useful tricks and smart shortcuts but, although having been a dedicated front-ender for 4 years with no programming skills, I don't think CSS is meant to be discussed too thoroughly.
The best point in this article is that you need to take your CSS seriously and treat it as an equal to any other piece of code. A common practice in companies is to rigorously code review application code while basically giving CSS a pass.<p>Obviously your CSS might be less important than core business logic, but just ignoring any sort of practices will make developing new features take longer and less efficiently. It will also come back to haunt you at some point.<p>A key metric of any company is how fast you can develop new features while keeping quality, consistency and reliability. Following good CSS practices will only help out that cause.
I don't agree with some points. For example, he mentions this to be a good practice<p><pre><code> /* Bad */
.widget { }
#sidebar .widget { }
/* Good */
.widget { }
.widget-sidebar { }
</code></pre>
In my opinion, it's <i>best</i> to use a "sidebar" class for the widget.<p><pre><code> .widget { }
.widget.sidebar { }
</code></pre>
Now, you might be worried that the "sidebar" class affects the widget in unwanted ways. Well, it shouldn't. That class should have generic/basic styling that anything in the sidebar should have.<p>Maybe you want to have special font styling for things in the sidebar. The ".widget.sidebar" is a special selector for a widget in the sidebar. You can also have the following<p><pre><code> .separator
.separator.sidebar
.separator.footer
</code></pre>
That makes elements easier to maintain and debug. Well, just my opinion.
Looks like he just rewrote the ideas of [Nicole Sullivan](<a href="http://stubbornella.org" rel="nofollow">http://stubbornella.org</a>) and [Harry Roberts](<a href="http://csswizardry.com" rel="nofollow">http://csswizardry.com</a>).
Kind of a side issue to the article.<p>CSSLint is useful, at least for me. The only problem is I find myself disabling a lot of rules.<p>There are certain rules that <i>would</i> be useful if you could easily specify their parameters. For example, there is a rule that says that you can only have 10 font-size declarations in your CSS sheet, which is completely and utterly arbitrary. What if I need 11? Or what if I ONLY want 3? It would be useful if I could specify that. In fact I should be able to do that for any property.<p>Developers need to be able to enforce standards in their JS, CSS and even HTML. The fact, however, is that certain standards aren't ubiquitous across every webpage, and need to be set by the developer.
I think theres is not enough of the understanding of what CSS is. And a lot of times trying to make "reusable CSS" is like trying to have make-up that is reusable among many ladies.
CSS is intended to be highly targeted and there are tons of "it depends" so the best you can do is to try and spend some time trying really understand CSS and what result you need. Writing CSS for widget is one thing, styling the page where every byte off HTML counts is another.
Take any rules and advices with massive grain of salt, especially the moronic "no IDs allowed" kind ones.
And yes, do use preprocessors.
This is a very good article that trying to define some really good practices.<p>I'd like to add another practice that has served me well over the years; Separate layout from style. Doing this will make your CSS much more modular and reusable.
Some of this sounds like it really complicates the layout code, but I'm not sure I'm reading it right. Take, for example, a standard dialog template. If I have a large number of dialogs for editing user/products/whatever, all with the same basic `<div><label><span><input>` layout, it sounds like he's saying that I can't rely on the dialog template to format my labels, I have to apply the `dialog-label` class to every label in every dialog. Almost every tag in my doc will have a class attribute, since I can never rely on selectors to apply the right styling. In general, selectors are almost never used and classes do all the work.<p>Am I reading this right? Or are templates an exception? I need to re-read the template/component thing a few times to figure out exactly what nomenclature he's using here. But in general, I'm not sure I see the advantage of `.modal__form__item` vs. `.modal .form .item` except that the first is exponentially more verbose in the html.
I love articles like this, I would like something like this but more concise and indexed, does anyone know of anything like that?<p>There are so many things I do that are described in this article and I class myself as a seasoned CSS developer.<p>Every project I do I try to improve my layout and modularisation of my code. The one thing I find really difficult is naming, I always fall short on naming my elements.<p>I like to group stuff too so I know where it is but grouping is sometimes difficult, do I group buttons with buttons or inside the associated container it is in?<p>I've just done my second full responsive site and have learnt a lot about reusing code in this one due to the nature of responsive sites so on the next one I really want to come up with a routine.
Good article. I'm not much of a front-ender, so I always ended up with completely unreusable and unmaintainable CSS. I've been trying to write more maintainable and reusable CSS the last year, but I'm still struggling with best practices.
I disagree with this rule as phrased, though I agree with the examples: "MODIFYING COMPONENTS BASED ON WHO THEIR PARENTS ARE"<p>In the example there is a 'regular' version of widget and a couple 'special cases'. I think if it was treated as .mainContent>.widget{...} vs .sideBar>.widget the granularity and expectations are the same, you can still have a more generic .widget that sets common values. In general I think this is more readable and concise than having a .mainContentWidget and .sideBarWidget separately.<p>2c. :-)
I write all my CSS using BEM (Block-Element-Modifier) now and it's helped quite a bit with making updates (no more specificity wars) and maintaing contextual style rules.<p>I was thrown off at first by the ugly naming convention and "classitis" that the pattern produces, but the gains are worth it.
CSS rarely gets mentioned in skill assessment because it's more akin to a syntax than an actual <i>language</i>. Though this seems to be changing as more advanced features are added at a snails pace.<p>None of your examples break anything, thought they should be considered if writing something from the ground up, maintenance is another story. CSS semantics don't even make it into the bug tracker unless you have nothing to do, or your sole job is to write CSS. There is always more important things to do.<p>This is similar to how you can always spot a "new" web dev over how they obsess over WC3 validation. Sure it's important, but it's not that important.
I guess I was doing it right the whole time. Somewhere along the line I decided recently that I didn't like putting too much into the "namespace" and started transitioning towards relying more on parent containers (especially if sections where properly id'd), but it looks like this might be bad practice.
How about applying the common aesthetic/architectural standard: 'of the medium' == good. With CSS that means declarative, not procedural i.e SASS/LESS etc would be considered a bad thing.
Working on a project to improve CSS architecture: betterfrontend.com<p>I haven't had a lot of time lately but it's all Open Source - hoping the community will start working together on it.
Having used Appfolio for managing a small investment property portfolio, I wish they would spend a little less time analyzing the philos of CSS and a little more more time on high-priority features that customers have been waiting for. There are a million things in life we can spend time on, and the real challenge is to prioritize. Do we a) Get a PhD in CSS, or b) Deliver features that 90% of our paying customers have been asking for? To quote Steve Jobs, "I'm proud of the things we did; I'm even more proud of the things we didn't do." You didn't catch Steve Jobs writing a dissertation on CSS... he had more important things on his mind. As a customer, you can't help but get frustrated when priorities are being so mismanaged and you're paying $4000 a year for it.