Joe8Bit on Don’t use IDs in CSS selectors? (2011)

Comment on Don’t use IDs in CSS selectors? (2011)

I have to admit to not feeling too strongly either way about this, but the argument I would have against the 'never use IDs in CSS selectors' is purely a semantic one.

An ID, by design, semantically references a single thing. This has important meaning when making HTML (amd CSS) readable and parseable. Now, I'm not necessarily saying this is a 'winning' argument, but throwing away a useful tool for declaring semantic meaning for hand wave'y arguments about 'britality' feels like overkill.

ratbeard 11y

A case where the "only 1 instance" assumption can break is on a styleguide page, where you might want to include multiple instances of a singleton element to show it in different states, say for your #header for example.

Multiple elements w/ the same id will pick up css styles, though.

lcmatt 11y

That's exactly the problem - you're referencing a single element which can't be reused. I bet all the styling being used on the element could be broken down in to reusable classes leading to cleaner code and less specificity.

Joe8Bit 11y

I would argue about cleaner code, in my view doing something like:

    // HTML
    <div id="myLoginWidget">...</div>
    
    // SCSS
    #myLoginWidget {
      @extends #baseWidget;
      @extends #somethingElse;
      @include rounded-cornders(0.5rem);
      background: darken($base-blue, 20%);
      ...
    }

Is 'cleaner' than:

    // HTML
    <div class="baseWidget somethingElse small-rounded-corners dark-blue-bg">...</div>

    // SCSS
    .baseWidget { ... }
    .somethingElse { ... }
    .small-rounded-corners { ... }
    .dark-blue-bg { ... }

It achieves the same reusability (in code) without polluting the content (HTML) with the presentation (CSS).

talmand 11y

Are we saying "cleaner" as in "more efficient"? You have to keep in mind the resulting CSS generated after compiling. There is a balance to be had between clean CSS and efficient CSS.

If you are using the classes from the second example in more than one place in your HTML and then depending on your actual CSS in those classes, then the second option may be more efficient then your first. In SASS, it will totally depend on how you write the actual CSS, not just the class versus id debate.

But a question from the article comes to mind in your example, what if you are requested to insert a second login widget to the page? Even worse, if your Javascript uses the ID for targeting the login code then you have to reconsider that code as well.

Joe8Bit 11y

If the SASS compiler wasn't smart enough to deduplicate several references to a mixin it would unquestionably mean redundant properties and more weight in the compiled CSS, but it wouldn't be any less efficient from a page paint POV.

There's a completely valid argument that any "improvements" in the above sense are outweighed by the extra time in downloading and parsing a larger cold-cached CSS file, but in my case I am happy to rely on the browser cache and the compiler to be smart (and maybe sacrifice a small amount of resulting CSS weight if it's not) resulting in "cleaner", more semantic HTML (and arguably CSS).

In terms of the second login widget, you're absolutely right, my implementation would fall down, but then it would be a VERY simple refactor. However having n of something on a page would have a semantically different meaning than my case, so therefore classes are indeed the right specificity method!

nirvdrum 11y

Maybe I've just seen some particularly bad JS, but I often see a lookup by class name and then just fetching the first element. This pattern would suffer the same fate, without the semantic hint that there should only be a single element that an ID provides. Likewise, in my experience, a lot of code gets more convoluted when trying to be more general than it needs to be (the YAGNI principle) or by trying to be DRY by happenstance rather than by semantics.

Comments