My fourth book, ‘Enduring CSS’ is out now

6 comments:

1. I don’t really build sites large enough for this to be a concern for me but I am curious about what you have against using element selectors. Why is .btn{} better than button{} for example?

   Reply

   • Hi Oliver, obviously it’s covered in detail in the book. However, in brief, using elements is more specific plus you will then be tying styles to a particular element. With a class you could apply the same styles to an a, div, span, button etc

     Reply

2. Hi Ben,

   I have a question for you, regarding variants/modifiers in your ECSS approach. I’ve been using a similar approach in a product I’m developing and, inside the team, we struggle a lot about this. How should variants/modifiers be implemented. Let’s say we have a “Module_Component”, with a variant “Module_Component-variant”. DOM-wise, should we:

   1. Add both the base and modified classes to the element (i.e. ); or
   2. Switch the base class for the modified on (i.e. changing to ) ?

   And, CSS-wise, should we:

   – Make a multiple class selector (i.e. .Module_Component.Module_Component-variant {} ); or
   – Code the “variance” inside a single class selector for the variant (i.e. .Module_Component-variant {} ); or
   – Following the second DOM-approach (switching classes) and giving all the styles for the base and the variant (e.g. .Module_Component, .Module_Component-variant { /* Basics for both here */ } and .Module_Component-variant { /* Variant specifics here */ }) ?

   Oh, and regarding the “extras” for your book, I’d vote for a sample CSS framework built to illustrate the ECSS approach – something hosted in Github would be great.

   Reply

   • It seems my comment was sanitized for HTML stuff, in the DOM alternatives part. 🙂 I’ll try with HTML entities:

     DOM-wise, should we:

     1. Add both the base and modified classes to the element (i.e. <div class=”Module_Component Module_Component-variant”>); or
     2. Switch the base class for the modified on (i.e. changing <div class=”Module_Component”> to <div class=”Module_Component-variant”>) ?

     Reply

     • Hi Paulo, thanks for the comment. Great question 🙂

       For me, I always add two classes on the element. So <div class="ns-ModuleOrComponent_ChildNode ns-ModuleOrComponent_ChildNode-variant"></div>

       Then in the CSS I have the styles for each like this:

       .ns-ModuleOrComponent_ChildNode {
           /* styles for node */
       }
       
       .ns-ModuleOrComponent_ChildNode-variant {
           /* styles particular to the variant */
       }
       

       Hope that helps!

     • It’s helpful, indeed. That was the impression I had from your previous posts and slides, but I’ve been preaching the opposite to my team. I’ve been following the one class approach, although I may need to review my position. My rationale is:

       1. “One class per element” is stricter and maybe easier to understand, as rule. Team compliance is hard to get, and I was afraid that “allowing” more than one class per element would bring our code back to the previous state (many utility-like classes piled upon each other);
       2. Performance, although the difference should be negligible – this is, probably, a moot point. We have to support many old Android handsets, but compatibility should be a bigger problem than performance;
       3. Avoiding “order”-related issues – it both the base and modified classes define e.g. background-color, then it would be mandatory for the modified class to be placed after the base one. This seems a problematic point for me, probably even more so when using a JS framework which might toggle the classes dynamically (i.e. it shouldn’t happen but I can’t guarantee so).

       Anyway, thank you for your ideas. Your posts have been food for thought in my journey to better CSS architecture.