Scoping (how do I guarantee my styles won’t impact other things)
Djoy: is css name collisions a problem today? : example: Modal css styling collisions
Reuse of styles (of mixins, sass variables, class utilities) make it difficult to upgrade styles
Mixins change without breaking change versions in libraries
Style reuse is difficult if it’s not in paragon.
solveable w/ CSS-in-JS or shared scss modules w/ mixins/variables
Sharing styling motifs/variables across components, in a way that can be shared/re-used across projects. (e.g. A particular type of card might have a special border or banner in it). It was a one off from design
What requirements do we have for css tooling?
supports theming (e.g., overriding a button color in Paragon)
Support some kind of public reuse of styles (Importable outside of Paragon)
Logo for project is not terrible. (-1) (minu)sone
Prevent bloating the package css
increase not decrease approachability of styling (both for reading and writing)
Doesn’t break webpack hot reloading
Standards based approaches are good
CSS Variables is standard
Free for all and hot takes
BW: if we incorporated the css modules into our build workflow, it can become silently enforced.
Theme-ing through global classnames (.btn-primary) removes it from the concern on css tooling/sharing
CSS-in-JS approach requires more investment, but provides alot of power.
Can we describe what power it has above and beyond what we have today?
Programmatic control to change styling in the component
How often do we need this?
no need to name anything styles are directly applied to js components
Is there any a11y consideration here? Do screen readers or the like use CSS information at all? (I don’t think so, just trying to poke holes)
Which implementation would we choose?
Are writing styles inside a JS template string a good DX? -djoy
(That sounds like a pain to me) -djoy
Its not super great, but can be wrapped super easily by dumping objects into those strings, and THAT is a good (BW)
^ this is exactly the thing we went through as an industry with jsx
Is our goal to get to 100% adoption of CSS-in-JS? If not, is it a good place to be to have two separate styling systems?
If we adopt CSS-in-JS, are we inviting an ugly blending of styling vs. functionality? i.e., is there value in keeping styling info out of our components? Will we provide best practices for this? (in the same way that we have containers/presentational smart/dumb components today to help keep presentation decoupled from data management?
why would we not use css variables?
I’m not yet clear what we get out of it, since we already have SCSS variables… except the runtime theming thing, I think? -djoy (+1 BW)
Standards-based approach, rather than SCSS
It’s also not a “one vs. the other” thing; could have css variable that is the same thing as the SCSS variable, providing flexibility to use one or the other where relevant.
CSS-in-JS is a much less reversible decision than adoption of CSS Modules and CSS Variables
Is CSS-in-JS compatible with static site generation? (I think so?)
Lukewarm take: I think mixins are incredibly destructive/difficult to reason and should be generally avoided at all costs
In CSS-in-JS, is it possible for a component to be unaware of themes? A virtue of stylesheet replacement/overriding is that the component no knowledge that it’s being themed differently.
I’m not sure if CSS-in-JS gives us much that we can’t accomplish via the classnames package.