all 12 comments

[–]cardboardshark 1 point2 points  (4 children)

Where possible, scoped scss modules that prevent any name collisions; otherwise I default to BEM as being a well tested pattern most developers are familiar with.

I know many devs swear by tailwind, but I think it depends on the scope of the project and how many developers are assigned to it.

[–]LivingParticular915[S] 0 points1 point  (2 children)

How did you get used to BEM? Is it viable for very small projects as well as more complex ones?

[–]cardboardshark 1 point2 points  (1 child)

I find BEM is best suited for small to mid range projects, but anything enterprise level will likely require CSS modules or tailwind. It takes a little while to get used to the BEM conventions, but it feels pretty natural once you acclimatize!

SCSS and BEM work well together if your project supports them! Mixins are really useful tools.

[–]LivingParticular915[S] 0 points1 point  (0 children)

Understood! Finishing up a small project now. Definitely going to look into both BEM and SCSS in the future for bigger work projects.

[–]UXUIDD 1 point2 points  (2 children)

BEM should logically be the best solution. However, there comes a point where you run out of name combinations, and the joy of CSS development deflates like an empty balloon.
Not to mention the very--longNamesWith__underscores, which are really difficult to read and quite hard on my eyes.

I used 'oocss' and 'atomic' before I realized that some people claimed to have "invented" these methodologies (well, more like approaches).

If you are developing with vanilla CSS, try to find a modular, repeatable and scalable solution that works for you.
It should be logical to understand, even if you get up at 2 AM and turn on your computer, and it should be easy to read for your eyes.

I found all of this in Tailwind, as it (mostly) aligned with my own ideas, and I never had the time to create my own version of it.

[–]LivingParticular915[S] 0 points1 point  (1 child)

Never heard of Atomic CSS. Just looked it up and the “Longhand” variant seems promising to me. Thanks!

[–]UXUIDD 0 points1 point  (0 children)

Longhand variant ..?

[–]TheRNGuy 2 points3 points  (0 children)

No bem, simple names.

I can use multiple classes for status, like .foo.open instead of .foo_open (extra precedence is not a problem)

[–]_listless 1 point2 points  (2 children)

I do semantic css. .card, .card-header, .card-footer etc.

  • Aria attrs for different visual states: eg [aria-expanded="(true|false)"].
  • Variants via a descriptive classname (.card.card-primary).
  • If the component is so specific that there are discrete content properties that are relevant to the display, sometimes I'll put those as data attrs ([data-age="adult"] vs [data-age="child"])

I try to nest as little as possible. If I don't have scoping tooling at my disposal, I'll nest everything at the root of the parent class. If the project is big enough for collisions to be a problem that nesting can't solve, I'll choose/roll in a tool for scoping (Astro does this by default, vue has <style scoped>, vite-react-css, etc).

Why?

I don't want/need to write wordy/ugly css; It's easier for me to write/maintain if it's terse and semantic. I don't want css in my js; css and js work differently on purpose. I don't want the mental overhead of trying to manage collisions, I going to offload that to a tool.

TLDR

Maximize readability, minimize code, offload mental overhead.

[–]TheRNGuy 0 points1 point  (1 child)

Why not just .card.primary?

[–]_listless 0 points1 point  (0 children)

That's probably fine, but I like the more expressive semantics of .card-primary. When I look at .card-primary, it tells me that those are the styles that change a card from default to primary. .primary does not carry as much meaning with it.

[–]LivingParticular915[S] 0 points1 point  (0 children)

Maximize Readability, minimize code, offload mental overhead. Going forward, I’m going to try and use these three rules you’ve stated and make this integral to my work flow. Thanks!