21 comments

  • Renato de LeãoRenato de Leão, 7 years ago (edited 7 years ago )

    You got me with the title, but Immediately stopped reading when I saw the line don't reuse. I'm not here to tell you what approach you should follow: if it works for you and your team, just great and keep it up.

    Specificity may save from HTML bloat, but gives you CSS bloat and on massive apps or fast-growing/iterative ones, it will be a nightmare to update every single component just because your client want to experiment something new.

    At the time of writing I tend to do a mashup of OOCSS, some utility (responsive) Atomic Classes and flavor everything with BEM Syntax.

    Either way i'll leave here some articles, that sum up my approach better than I can possibly explain on a DN comment:

    Actually read the hole blog of Harry Roberts csswizardry. Nope i don't have a referral program with him, he's just really good at what he does.

    11 points
    • Hamish TaplinHamish Taplin, 7 years ago

      The Salesforce design system doesn't get mentioned enough. It's an amazing example of the principles of a modular design system actually working incredibly well in the wild.

      4 points
  • Dominik PoradaDominik Porada, 7 years ago

    Clearly, the author of that resource has never worked with large apps—how is that scalable?

    7 points
    • David ÖhlinDavid Öhlin, 7 years ago (edited 7 years ago )

      This is more or less the opposite of how I think you should write css.

      EDIT: I just realized this seems like a dick comment and I'm sorry, I'll try to expand when I get off work.

      7 points
      • Terry OTerry O, 7 years ago

        Agreed. The more I think about it, the crazier it sounds. If anything, it goes against what it is trying to solve.

        2 points
      • Hamish TaplinHamish Taplin, 7 years ago

        Same here. There's no evidence for any of this and most of the reasoning seems to be based around vague concepts like "semantics" and "bloat".

        Nice to see an opposing point of view but I'm not convinced by any of the arguments presented in the "semantics" and "reuse" chapters.

        2 points
    • Terry OTerry O, 7 years ago

      I agree this is overly dogmatic, I think there's a happy medium here (in my experience at least) where you have objects as well as utility classes for common, repeatable styles e.g. something like Harry Roberts' ITCSS.

      2 points
      • Hamish TaplinHamish Taplin, 7 years ago

        I've started using pure utility classes a lot recently (with responsive suffixes eg @m) and find this a really nice way to express simple bits of layout, type and whitespace.

        I don't understand this at all:

        If you have utility non-semantic classes that describe the look then when you edit one of these classes, they will propogate to every single element with that class

        That's the whole point of utility classes, they follow the single responsibility principle and you would be incredibly unlikely to edit them.

        5 points
  • Surjith S MSurjith S M, 7 years ago

    That camelCase though !!!

    3 points
    • Adam Silver, 7 years ago

      ha ha - what do you suggest instead? :)

      0 points
      • Surjith S MSurjith S M, 7 years ago

        Its better to use hyphens as you wrote in your CSS. or underscores like BEM.

        camelCase is often used in JS :)

        1 point
        • shaune westshaune west, 7 years ago

          "better" is quite subjective to whom is writing the CSS and what team is reading it.

          I use a very similar naming convention as the Author and prefer it to BEM, neither methods are incorrect and both should be appreciated.

          0 points
  • Zachary Meredith, 7 years ago

    CSS bloat is way more expensive than HTML classes. If you're templating properly utility classes are the way to go for most situations imho.

    What really sold me on utility classes is that if you create a thoughtful system you can create many new components without writing new CSS. If you didn't reuse anything you would need to write all new CSS anytime you wanted a new type of component. As your project grows your CSS would continue to expand way more than it has to.

    This is a really good piece on CSS & scaling it. Check it out.

    Also with regards to the complaints about things like '.red' not telling you if it referred to color or background, Solid from Buzzfeed solves that with simple prefixes. It's also a really good example of a pretty complete & thought out utility based system.

    Obviously whatever works best for your situation & works best for your product is what you should do. But in most situations I'd go with a thoughtful system of utility classes.

    2 points
  • stl s, 7 years ago

    This technique would be useful only for people who excessively use Ctrl+F while working with the CSS file. :)

    Usually websites have consistent design, i.e. repeating styles for active, for example. Styles repetition comes handy in such cases, so I wouldn't drop it, so that I stuff the HTML with new classes and spend half of the day copying the same styles. Also, repetition makes the code longer, thus less maintainable.

    Sharing experience and practice is great, this is how we make progress, however, CSS specificity is not that scary or hard to grasp and this is the only argument I find reasonable for using Maintanable CSS on the website.

    1 point
  • Marcel van Werkhoven, 7 years ago

    I'm a big fan of functional CSS myself: https://blog.colepeters.com/building-and-shipping-functional-css. Basically 'write out' the classes you are using and bundle them in objects (if there's too much class 'bloat'). Start out with the seperate classes and you rarely write unnecessary CSS.

    That way you can both use objects as well as alter them with additional classes. I've tried a bunch of different ways of writing CSS but this is the easiest to maintain and use so far. Also with classes like : top-0, h-100vh, no one has to 'guess' what it does when looking at the code. Even when someone messes up, you still get a pretty good idea of what they tried to accomplish.

    0 points
  • Nathan NNathan N, 7 years ago

    Personally I'm a fan of the atomic design philosophy http://patternlab.io/

    0 points
  • Thomas Michael SemmlerThomas Michael Semmler, 7 years ago

    Could you please elaborate on how this differs from BEM?

    0 points
    • Dominik PoradaDominik Porada, 7 years ago

      Looks like written by someone who doesn’t like the syntax of BEM.

      1 point
    • Adam Silver, 7 years ago

      Your comment is a fair one so thank you for that. There are similarities to BEM. There are also similarities to ecss.io so go check that one out too.

      A few small notes: The terminology is different - I think this is more readable (but then I would, wouldn't I? :)...and for me readability is very important (something I talk about early on in MaintainableCSS)...the rationale behind it comes from a different viewpoint (mine) and there are more chapters to come all of which I think are beneficial.

      For the benefit of the comment below...there are many methodologies "out there" of which many are similar but I don't think that is reason enough to not to share the approach. Myself and other people I have worked with for many years have found value in it, so getting this out of my head and sharing it with the community feels like a positive thing to do.

      1 point
      • Thomas Michael SemmlerThomas Michael Semmler, 7 years ago

        The Terminology is different, yes - and its fair enough that you basically just shared your modified BEM-Approach, which is basically an iteration of smacss, which is basically an iteration of oocss (As far as I see it). But besides the terminology and the fact that you use single dashes to separate the .module-component-state { }, there is no actual difference. But I personally think there doesn't have to be a major difference. It works for you, thats great. I personally would deem this kind of code highly unreadable, but I am very used to writing BEM - so I guess thats only natural then :P

        For the benefit of the comment below...there are many methodologies "out there" of which many are similar but I don't think that is reason enough to not to share the approach

        And you should also never stop sharing, no matter how salty any comment gets. Not because other people profit from it, but because it demonstrates acting based on values.

        But also understand, that people criticize things heavily nowadays based on the fact that more and more people share recycled and useless things in the content bubble we are in, in order to get exposure, which will translate into money, eventually. Such people are basically exploiting the humans who work in this industry. That is in a way of course no different from countless prototyping tools who all just try to get our money, despite how noble their goal to solve that one problem that nobody truly has: animation in wireframes and mockups might be marketed.

        btw, thanks for sharing ecss.io - I had not heard of it before!

        0 points