CSS Tools Meeting Notes

Owned by Adam Butterworth (Deactivated), created
Last updated: Feb 02, 2021 by David Joy (Deactivated)
3 min read

Let’s discuss CSS in JS, CSS Variables, CSS Modules for Paragon (and therefore MFE adoption)

Feb 2, 2021

References:

GitHub - css-modules/css-modules: Documentation about css-modules

What problem are we trying to solve? Why would we consider these tools? What challenges do we have in styling?

  • Increase approachability of existing styling code

    • Naming html classes is seeming randomly done throughout the org.

    • Does this bullet mean semantic class names?

    • Why name things that don’t need names?

    • complexity/worry of css collisions makes people use un-necessarily complex class names

    • Colocating/tighter coupling between component to be styled and its styling information (+1) Approachability

      • Difficult to know where to put CSS/SASS and if it’s not near the javascript it’s hard to locate

    • Sometimes bootstrap util classes aren’t enough

  • Prevent bloating the css devlierable

    • including the same css/scss twice or otherwise

  • Runtime theming.

    • Runtime style extensions/overrides.

  • Prevent style collisions/Scoping

    • 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

      • gradebook

  • 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

  • IE support?

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?

      • styled-components

      • emotion

    • Are writing styles inside a JS template string a good DX? -djoy

    • 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.

 

Action items

Decisions