Comment by talmand | Hacker News Reader

Comment by talmand | Hacker News Reader

Parent Full thread

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.

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!

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.

Reply on news.ycombinator.com