Reimagine Atomic CSS

Re:Reimagine Atomic CSS by sodapopcan on Wednesday November 17, 2021 @01:25PM (#29256829)

As I addressed in another branch of this thread, you're actually missing the point and his article does a poor job communicating it off the bat with its first two examples.

In your example, `.m-0` and `style="margin: 0"` aren't equivalent in this paradigm (even though they happen too be technically equivalent). `.m-0` really just means "no margin". If you look further down the article, you'll see:

  .m-1 { margin: 0.25 rem; }
  .m-2 { margin: 0.5 rem; }
  /* ... */
  .m-10 { margin: 2.5 rem; }

As you can see, the numbers don't match their values, the class names are meant to be relative to one other.

A better way is to use constraint-based design and come up with a system where you would only have `.m-none`, `.m-xs`, `.m-sm`, `m-md`, `.m-lg`, `.m-xl` (for example).

Libraries like Tailwind give you WAY more than you're going to need and you should only really be using a subset.

[ Parent | on HN ]

Re:Reimagine Atomic CSS by yakshaving_jgt on Wednesday November 17, 2021 @01:37PM (#29257006)

I'm not sure I am missing the point actually. As a class name, `.m-none` is pretty terrible, because it says what the thing looks like rather than what it does. I can't see how in practice this doesn't lead to a much greater mess, and even in the best case you would end up with

    .m-none.br-kinda-rounded.p-a-bit.bw-pretty-thicc.bc-old-mauve

The clever example in the article with using a loop to define values is not something I find particularly compelling either. The whole point with specifying relative values, e.g., percentages, ems, root ems, etc., is that they can change relative to an element they inherit from or from the root of the document.

Furthermore, using class names is not the only way to achieve the effect in the example you pulled from the article. Sass (and just about any CSS superset from the past decade) can achieve the same with mixins, which would spare the resulting document from all the selector noise.

[ Parent | on HN ]

Re:Reimagine Atomic CSS by cjpearson on Wednesday November 17, 2021 @01:56PM (#29257281)

Atomic CSS class names have no semantic information and they are not meant to. If you need a class to describe what an element does, you're free to add one.

The amount of class names is off-putting at first, but you get used to it pretty quickly. (I'd also recommend using numbers or sm, md, lg etc for your size increments, but to each their own.)

Tailwind and friends aren't trying to solve the CSS Zen Garden problem. Their focus is on re-usable CSS rather than re-usable HTML. Depending on your needs that may be better or worse.

[ Parent | on HN ]

Re:Reimagine Atomic CSS by sodapopcan on Wednesday November 17, 2021 @02:10PM (#29257470)

Right. The point is to turn what we’ve taught on our head and use CSS to describe what things look like and use components to describe what they do (a component can be a web component, frontend framework component, partial, etc). In fact, using this style of CSS without components is probably not the best experience (but I’ve ne er tried).

As stated in another thread, it’s not necessarily better but it works very well, and I personally find it nicer having everything my component needs in one file.

[ Parent | on HN ]

Re:Reimagine Atomic CSS by aarpmcgee on Wednesday November 17, 2021 @07:24PM (#29260704)

+1 to this. It makes a lot of sense with a component-based library or framework like React, Svelte, etc. I've never been more productive, and its a bit of a bummer to work on projects that aren't using this kind of thing. I enjoy this general approach whether powered by Tailwind or some style-props based ui library (chakra ui for instance).

[ Parent | on HN ]