Love the contrast 🙌

sounds like an oxymoron to me...

does this count? https://github.com/lambdaisland/ornament ;)

@U07FP7QJ0 maybe!

@U052852ES I couldn’t agree more. I do OK in CSS, but it often feels like an abyss of doubt. E.g.: “How can I style this so that it is scalable when you only scale the text, scalable when you scale everything, whilst keeping it kind towards screen readers, and having the CSS be understandable, organized and maintainable? Also, I’d like to do so in a way that does not introduce too much conversion churn when receiving design from UX’ers. And it should fit in with the existing CSS. And the component must be reusable in different contexts.”

I read a tongue in cheek reply on stack overflow where the replier vastly simplified the design to the horror of everyone but those who want functionality delivered quickly. I kind of liked that.

Have you worked with https://cube.fyi/? I think it sounds promising, but I haven’t had the chance to apply that particular CSS strategy yet.

haven’t done catch-up on this part… my memory stayed on those SMACSS stuff etc (basically kind of design pattern approach to a css framework to improve maintainability)

I suppose css is a bit like low level programming (e.g. complexity of x86 instruction set)

What I have found helps, is to take a component-first approach. In practice this means, one CLJS namespace maps to one SCSS file. We enforce this by convention only so far.

@U0522J5HN no, I haven’t. Seems like an OK strategy to me.

@U7PBP4UVA I think I like this. Does it mean that you lower reuse? I think one of my gripes with CSS is that reuse is nice in theory, but hard in legacy. If I want to change some CSS that’s used in lots of different contexts, that’s a heavy test burden. But what’s worse? Unintended consequences by missing contexts when changing heavily reused CSS, or neglecting to align changes across the board because CSS is not reused? 🙂 As an aside, I think another issue is testability, but that’s not directly related to CSS. In my work application, it’s (sadly) a bit difficult to visit every context; arriving at a particular page or popup might require a series of business logic steps in order to create the right context. In retrospect, we could have put much more effort into making components testable. We have a “test page” where you see some common components in various states, but it’s a very small subset.

I think normal engineering practices on what is reusability are key here. • A piece of CSS that's used in lots of different contexts by itself is OK. Example: a color definition, it could be a class or a SCSS var. • A piece of CSS that's used in lots of different context, but only needs to change in SOME of them is an issue of the wrong abstraction.

What we ended up doing is creating low-level React components, e.g. Text , Column , Button etc etc. Those are well defined in a design system in Figma, and they are implemented in a stateless way.

These low-level components are tightly coupled to the design system, e.g. the Text accepts a :variant argument that can be e.g. Body/Long, Heading/Small etc etc.

Also sounds good. Stateless = easily testable, and it sounds like you have a direct communication channel with your designers.