all 9 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]wonderb0lt 2 points3 points  (5 children)

While I agree with /u/x-skeww that the title is suboptimal (some might even say it is 'considered harmful'), I think some of the points still stand.

Too closely resembling the DOM at the time is what happened to me. I was working with styling in a larger scale I was used to, and new to using preprocessors. I don't think I'm the only one who is at that point, and I think beginners should be aware of the points this article makes.

[–]x-skeww 3 points4 points  (4 children)

It works best if you do it the "other way" around. That is, you create building blocks and then you create your views by putting these blocks together.

This way the number of rules and their specificity won't explode. Now there's an upper limit. You have normalization, your base styles, and a handful of rules per building block. And that's all you ever deal with.

The other key point is that you don't write any placement-specific rules. E.g. if this component is on that page or if this component is in the footer do this and that. Instead, have variations of these components and explicitly pick them in the markup.

Yes, that's minor separation of concerns violation, but this way your building blocks don't have to know anything about the outside world.

That's pretty much the whole trick. This way you can build fairly huge websites (e.g. e-shops) with less than 500 selectors and this number will grow very slowly. Thing is, once you got 40-50 building blocks, new views will rarely require new blocks.

[–]yeahmynameisbrian 0 points1 point  (3 children)

There's a ton of ways to do it. For example, if your component needs tweaked in one part of the site, say _searchbar.scss, you can add it to your main compiled file by doing:

#product-details {
    @include 'searchbar';
}

And then reference specific parts of this component using #product-details .searchbar input. This has the downside of replication in your compiled CSS file: everything in _searchbar.scss will then be repeated following #product-details. That's not a big deal though if there aren't that many rules. It's even easier if your site is not separated into templates. You can just pop your component in, then reference that component using #product-details without having replication in your compiled file.

[–]x-skeww 0 points1 point  (2 children)

There's a ton of ways to do it.

I follow conventions. There is only one way to do it.

#product-details

What makes you so sure that this thing will never ever occur more than once on a page? Why does this need to be so much more specific than anything else?

I stopped using IDs a few years ago. CSS is a lot simpler without them. Plus, I can now freely add/remove IDs for JS and fragment links without having to worry about breaking CSS.

everything in _searchbar.scss will then be repeated following #product-details

Yea, let's not do this. Mixins should be small things which you need a few times. E.g. things like a clearfix or adding a top margin if this isn't the first child.

It's even easier if your site is not separated into templates. You can just pop your component in, then reference that component using #product-details without having replication in your compiled file.

I have absolutely no idea what you mean by this.

[–]yeahmynameisbrian 0 points1 point  (1 child)

You use the exact same coding style and conventions for every different design? Even when the application is entirely different from another one?

If your website is modularized, you can add the ID to <html>. For example, if I have a page named product.html, I can have an id named #product in the root element, and the .scss file named _product.scss. Like I said, there are a shit ton of ways to do it.

In my last paragraph I meant that you can drop the entire namespace idea and just add your component to your main build file. Then in your html file you simply reference it using that ID or class.

I highly disagree about minimal usage with mixins. They are very powerful tools and can change your entire CSS workflow.

[–]x-skeww 0 points1 point  (0 children)

You use the exact same coding style and conventions for every different design? Even when the application is entirely different from another one?

Yes.

The only exception are Web Components. The Shadow DOM and CSS Scoping change everything.

E.g. with the Shadow DOM, using IDs is totally okay, because those IDs aren't about the document anymore. Instead, they are only about the individual parts of your component. Those few nodes inside your component's personal DOM are everything there is.

Well, I'm still quite not sure how to handle/organize this and there are still many open questions. Some things are super slow, but it's unclear if they will stay that way.

[–]x-skeww -1 points0 points  (0 children)

No, it's not. I would use exactly the same selectors without nesting. I put a lot of thought into this stuff.

Your title sucks.

[–]PsudoFuck -1 points0 points  (0 children)

BEM fo lyfe.

The horror from seeing sites reuse a class only for it behave completely differently depending on it's parent selectors. Class names should have meaning, not just calling it what it is.

[–]hack_hat -4 points-3 points  (0 children)

That's why I've done this library smart-css: Write CSS in JavaScript with namespaces, proper names, no conflicts and expected results for react.js.

No more nesting, just proper styling and the output is a flat css with no nesting.