Comments on We Write CSS Like We Did in the 90s, and Yes, It’s Silly

17 Reader Comments

Back to the Article
  1. Well, I think you’ve managed to convince me to alphabetise my declarations. I like logical groupings cuz I’m a logical guy, but I’ve yet to create a set of groupings for CSS that’s consistent enough for me to remember. Maybe it’s time to give up :D

    And I agree on principle that using declarations multiple times all over the place is ugly and un-DRY. Of course, DRY CSS would be better; it creates fewer maintenance problems.

    But I’ve got two problems with super-granular CSS like ACSS and Tachyons. The first is that, every time I want to add a CTA button to a page, I don’t want to have to remember… “was that last one a <button class="padding-1-em rounded-0.5-em font-size-large"> or was it a <button class="padding-0.75-em rounded-0.25-em font-size-large">?” In this case I’m just pushing the duplication (and the maintenance hassles) from one place to another. This is where I think a CSS preprocessor can come in handy—your atomic classes get mixed into logical/‘semantic’ classes, and it’s the latter that get used in your markup. Duplication in the outputted code, but DRYness and composability in your source files.

    The second case where the atomic approach is troublesome is when you don’t control the markup. I’m thinking of the weary masses of WordPress, Drupal, Magento, and Joomla developers out there who are stuck with CMS-created classnames, or plugin-created markup that you can’t even create your own replacement templates for. They don’t even have the option to use atomic classnames in their markup.

    I had a similar situation on a project from a few years ago. We had one codebase but built and deployed websites for many clients, each with their own themes. There was so much good stuff (UI patterns, accessibility, semantic embellishments) in our templates that to duplicate and modify as needed for each client would’ve been a maintenance nightmare. And let’s not forget that templates are usually tightly coupled to domain models, and what happens when you refactor the domain model? In this case, the only sane thing I could think of was to think up good logical classnames for all the elements.

    In both of these latter cases, there’s plenty of room to be atomic and DRY in your Sass/Less source files (which is what we did), and accept a bit of duplication in the compiled CSS. (That stuff gets gzipped anyway.)

    Copy & paste the code below to embed this comment.
  2. Thanks, for the blog post.It’s true about the points you mentioned about CSS.

    Copy & paste the code below to embed this comment.
  3. Though I do appreciate the simplicity of alphabetical, alphabetical makes it difficult to understand at first glance what is being done. Width and height go together. Separating bottom and right is an obstruction to efficiency. I prefer to group by relationship. Positioning, Display/Box Model, Typography, Colors, … CSScomb can help for teams.

    Copy & paste the code below to embed this comment.
  4. Wonderful work, Jens!

    Copy & paste the code below to embed this comment.
  5. Paul has it right, pushing style into HTML tags is not the answer. It’s a huge regression infact. There have been decades of work toward the ideal of having zero styling in HTML.

    sherrybcreative, I get your point that alphabetising CSS can make it difficult to understand what the CSS is doing. I’d argue that nobody knows what the hell CSS is doing, just from reading it. CSS is *not designed* to be understandable by humans. CSS is designed purely and specifically for browsers to interpret in some reasonably efficient way. The cascade is difficult to interpret from a straight reading, even for simple sites.

    Alphabetising is therefore not adding any extra complexity to the understanding of CSS, but it is adding some ease of maintenance and development.

    Copy & paste the code below to embed this comment.
  6. The author seems wary of CSS pre-processors, yet they help solve many of the issues he describes.

    The two features of pre-processors such as SASS / LESS that are most relevant to this discussion are the ability to compile multiple SASS / LESS files into single CSS sheets, and the ability to nest selectors. Both are strong organizational tools.

    With respect to the first, developers can organize styles into separate files for things like reset, base, specific components, etc. This is superior to taking monolithic raw CSS files and using something arbitrary like alphabetizing to determine where selectors should go. It also makes it easier to kill off legacy markup. For example, consider a codebase with a “foo” component that corresponds to a foo.scss file. If the component is deprecated you simply delete the foo.scss file!

    With respect to nested selectors, they reduce the chances that developers will reuse the same selectors. Consider a group of selectors like .foo {}, .foo ul {}, and .foo ul li {}. In pure CSS those could end up being sprinkled in anywhere leading to duplicate declarations. For example, we might have a .foo ul {} in the middle of the CSS file and then another .foo ul {} down at the bottom. The likelihood of this kind of mistake increases as CSS files get bigger and bigger.

    In SASS (or LESS) .foo{} would be a top-level selector in a file. Things like .foo ul {} and .foo ul li {} would be nested within .foo {}. It’s not completely idiot-proof, but it’s much less likely that one will have duplicate top-level .foo {} selectors in a small nested file—and these files generally ARE small because they are not whole CSS sheets; they are modular pieces that compile to whole CSS sheets.

    With respect to alphabetizing declarations, it’s not so important to me that every selector’s styles are declared in the exact same order. What is important to me is that things like display, position, and width are placed at the top of a selector’s styles because those are generally the most important values I need to ascertain when tweaking something. I don’t want to have to wade through a dozen declarations to find out that an element was absolutely positioned.

    In terms of big-picture methodology, SMACSS, BEM, and OOCSS are a couple of good mental models for how to write your styles. I’m not going to argue which is best. People have their preferences. But reading up on any of those will surely lead to writing better CSS than just winging it.

    My final piece of advice is to avoid overly specific use of selectors. The more specific you make your selectors, the harder they are to override. This is one of the things that leads to developers using !important, which should be avoided at all costs! Overly complex selectors can also slow down paint time. I find that this is especially important to enforce when people use SASS or LESS. Just because you CAN write nested selectors with SASS / LESS does not mean that everything SHOULD be nested. It’s quite easy to go into auto-pilot mode and just keep nesting and nesting when you write SASS. My rule-of-thumb is to never nest more than four levels.

    Copy & paste the code below to embed this comment.
  7. This is the one I have the biggest problem with

    > Try to use declarations just once.

    There is no reason for DRY to be goal in itself. DRY is a tool, to achieve some real goal, like smaller file sizes, better maintainability, etc.
    But I don’t see any real benefits to use it just for the sake of it.

    And your listed benefits are not benefits at all:

    > 1. It reduces repetition to a more acceptable amount.

    This is simply not a statement of a benefit. It would be if repetition was an absolute evil by itself, but it is not. DRY is not a gospel. It is, again, a tool, which is applicable somewhere, and not applicable in other places.
    And even when it is - it is only to a point.
    And yes, redundancy is not the same as repetition. You seem to conflate these two in your reasoning a bit, maybe even intentionally since redundancy has nothing to do with repetition.

    > 2. It reduces the pseudo need for variables.

    The need for variables being ‘pseudo’ is pretty outlier position that you had to link to your own reasoning about it. Which in turn relies back on this. Color me surprised. 
    But in any way it is not a benefit for any person, who does not need native css variables.
    And even if I need native css variables, there are better ways around it than mangling whole css codebase. And not even to solve the need, just to reduce it. Wow.

    > 3. Excluding outliers like Yandex, it reduces file size and payload (10–20% according to my own experience—we looked at the effects years ago at Google).

    Link is broken, and I don’t believe that gzip wont solve every repetition problem that you might have.
    1% of savings sounds more believable. What a benefit.
    And Yandex example proves you wrong, but you are quick to declare it as an outlier.

    > but we also know that in many other cases it does make them smaller and more compact.

    Where are these cases? The only case you show proves you wrong.

    So you haven’t listed any real benefits for fighting this windmill, besides very suspicious 10-20% savings, for which the link is broken, and excuse me if I don’t believe you on your words on that after all of this.
    Nothing in your approach indicates any potential increase in maintainability. But is screams about sacrificing maintainability to the god of DRY for the sake of it.

    No, thanks.

    Copy & paste the code below to embed this comment.
  8. I completely agree with you, we need to get organised!
    I’ve been around for those 20 years you’re talking about and that’s true, I still see people coding in the order it comes to their mind. Nice for them but hard to read for others or their later self.
    But thanks to this great idea of the alphabetical order, I can now see large declarations where the “colour” is just beside the clearing, “text-transform” sits with “top”, and “font-size” chats with “floats”.
    You understand that I completely and strongly disagree on the choice or the alphabetical order.
    The alphabetical order has one and only advantage: everybody knows/understands/can reproduce it. But it has absolutely no meaning. Alphabetical ordering is the choice when you precisely have no idea how to order things.
    Yes, then everybody can find what he’s looking for, but that’s about it. It doesn’t help developing, it doesn’t help understanding what you’re trying to achieve, and if you have a bit of logic when you build something, you end up writing a line, jumping 2 lines above to add something, go back at the end for a new line, change something in the first line…
    Practical example:
    “position: absolute” will surely be followed in your mind with something for left and top. Do you have to jump around your declaration to put them in the alphabetical order? I don’t think you should, it should be one single movement.
    When you deal with the appearance of your text, why would “position” be between font- and text- declarations?

    My personal choice is what I would call the box model (what I guess you threw in the bin with the breakfast thing): going from the outside of the element, how it sits in the layout, regarding the context, then the element itself, then the content of the element, and finally what may happen because of the element. More precisely:
    1) How the element will behave in the layout (display, position => top/left/z, floating/clearing…),
    2) From the outside to the inside of the element (margins, borders, dimensions, background, padding),
    3) Text (it’s the content of the element) (text-, word-, font-, letter-, etc.),
    4) All the rest: content, cursor, animations, etc.

    This way, when I try to achieve a positioning, everything gets together, one thought, one global coding. And when I come back on it, everything that is in relation sits together, you don’t have to parse the whole declaration to see if there is not a float somewhere of if you forgot the positioning.

    I do use the alphabetical order as well, between “similar” declarations like font-size, font-style, font-weight as they apply to the same kind of things and I see no logical precedence in any of them.

    There is no need to remind a perfect order of declarations to achieve this ordering, the understanding of what you do and how it applies is enough. From the outside to the inside. Period.

    Copy & paste the code below to embed this comment.
  9. Copy & paste the code below to embed this comment.
  10. I agree with mcbenny on the sorting idea. We’ve been using the box-model at my company and through the aid of a linter don’t actually have to remember what that exact ordering is. Neat side effect is how quickly you start to just write in that order without the linter having to correct you. This has another benefit for juniors who come aboard. Just enforcing that order teaches them about the box model. This grouping also helps identify parts that can be abstracted. If you’re always redeclaring the same the set over and over, you’re going to notice it right since it’s always in the same order!

    Copy & paste the code below to embed this comment.
  11. Lots of people are speaking out against the alphabetical ordering because it seems unnatural. When you get used to it, it feels totally natural, and it’s much easier to find things. I’ve been doing this since 2009 and it’s made my code much easier to read—and when my team did the same, it made things easier for all of us. I don’t think a lot of people are just haphazardly throwing their properties in there—most people have their own system—but no two systems look alike. A standard organizational system like the alphabetical one is great because everyone will code it the same way and there’s no guesswork on what goes where. A lot of people are scared to try it, but as someone who has done it for years and had a team who did the same, it really works.

    Copy & paste the code below to embed this comment.
  12. Even though I think it’s silly, I’d be happy to switch in the face of wide community shift toward alphabetical sorting. <- sorry, I just had to :)

    Copy & paste the code below to embed this comment.
  13. Great post. It has reminded me of my old days retouching the CSS of many of my old websites, hehe.


    Copy & paste the code below to embed this comment.
  14. yes its true, but i think we used 90s css type its because to many people has been learned this css type, and doesnt feel need more change.

    Copy & paste the code below to embed this comment.
  15. Hmm.. I don’t write like the 90’s.

    I use ITCSS, BEM, smaller and organized files, I order alphabetically… repeat when I think I should and rewrite to abstract something before things get ugly.

    Tachions and others are good ideas and have my respect.
    But still, push to HTML the definition of a button it is just not right.

    You have to define the frickin’ button somewhere.
    You have to define its appearance somewhere. As far as I remember, CSS is used to do that.

    With so many classes, you are defining it in HTML. Please, it is no use to think “But the [group of] classes are defined in CSS” because padding alone won’t define the button.

    As Paul d’Aoust said: what was like, the last button I used?

    I agree with Mikhail about the lack of examples that worked… more info, better debate.

    Thank you for writing.

    Copy & paste the code below to embed this comment.
  16. without the linter having to correct you. This has another benefit for juniors who come aboard
    طراحی سایت

    Copy & paste the code below to embed this comment.