I (@isabel_brison) facilitated the meeting based on this agenda.

Full meeting transcript on Slack

First point: how to set standards for using CSS grid in core, especially regarding browser support

I launched the question: why use grid? 

And proposed its main advantage for us is in complex multi-column layouts, in particular if they have dynamically sized columns (such as the columns block).

@laras126 mentioned grid may be more performant in rendering versus flexbox, based on this blog post.

@peterwilsoncc suggested using grid with @supports-based fallbacks, whether using the non-standard IE implementation of grid or otherwise.

I suggested a progressive enhancement approach, assuring basic functionality for IE.

@laras126 pointed out that using the IE implementation of grid is not recommended, referring to this blog post.

@afercia mentioned we could simply wait until WP stops supporting IE, and questioned whether we actually need to use grid. 

I mentioned some complex, buggy flex layouts could be fixed by using grid, but there’s no need to refactor all our layouts.

@peterwilsoncc proposed some parts of the admin could benefit, as grid reduces complexity for responsive layouts.

@afercia showed support for a redesign/refactor of WP admin if implemented in a mobile-first way.

@itsjonq considered that grid makes for cleaner, easier to understand code, so improves maintainability and stability.

Second point: how to approach using CSS variables in core, also regarding browser support

I introduced the topic by sharing the global styles proposal as example of the benefits of variables for theming and user customisation, and lamented the total lack of IE support.

@afercia manifested concern that this discussion may be overly Gutenberg-centric, based on the global styles proposal.

@itsjonq added that the current polyfills for variables don’t work 100% for all cases.

@laras126 suggested leveraging the cascade and Sass variables as fallbacks.

@peterwilsoncc proposed that use of @supports and its JS equivalent could make a progressive enhancement approach easier than with grid, e.g. colour schemes could switch to variables and be available only where supported.

I raised the question of dynamic styles, and suggested variables are extremely useful to use in this case, because they are easier to override than inline styles. However, this approach could only be used as an enhancement, with no IE support.

@peterwilsoncc reminded us that for the front end, IE compatibility is crucial, as ignoring it would force all our users to stop supporting IE themselves. Bearing this in mind, inline styles cannot be fully removed from the front end.

@afercia showed concern that CSS variables have already been introduced in core (on the About page), with no prior discussion.

Third point: should we adopt CSS-in-JS? 

I introduced the topic by pointing to my list of prior experiments and discussions about CSS-in-JS and stating two perceived advantages to it: reducing specificity and making it easier to reuse components anywhere.

@peterwilsoncc advocated for the importance of using a library that allows “easily styling state based styles without a tonne of mucking around with helper classes”, but expressed a preference for libraries that allow for the CSS to be precompiled rather than modifying the styles in the document, such as CSS Modules or CSS Blocks. He added that toggling classnames requires less re-rendering than stylesheet changes.

@laras126 suggested utility classes as an alternative approach to specificity issues and bloated stylesheets.

I observed that we’re not likely see a reduction in specificity until most or all of our CSS is refactored to CSS-in-JS, something very unlikely to happen.

@itsjonq clarified that he proposed CSS-in-JS specifically for wordpress/components because that package has unique style requirements: its components need to work everywhere, without additional styling. 

@afercia mentioned that CSS-in-JS is too coupled with proprietary JS library implementations, so it’s not future-proof enough in terms of conforming to web standards. He also pointed out that these solutions break the cascade in CSS, which is a fundamental aspect of the technology.

@itsjonq mentioned that there are attempts from these libraries to standardize approaches, though the proprietary aspect is indeed a concern. He reminded that we already use Sass, which is also a “non-standard” tool.

I reminded that standards can change in response to proprietary implementations, if they prove popular enough.

At this point, we reached the hour, but the discussion continued.

@peterwilsoncc pointed out the benefit of pre-compiled CSS files for future compatibility: the generated code can still be used if a technology changes.

I asked if it’s possible to precompile CSS-in-JS, to which @itsjonq answered there’s no good solution to do so yet.

@laras126 shared a movement to standardise design tokens that could be incompatible with a CSS-in-JS approach.

@afercia elaborated on his concern that CSS-in-JS breaks the cascade, as each individual element would need to be styled separately.

I suggested that issue can be avoided by using a combination of global and component-specific styles.

@afercia asked where CSS-in-JS can actually be helpful? To which @timothybjacobs replied: being able to reuse the Gutenberg wordpress/components outside of Gutenberg with reliable styling.

@itsjonq also replied that a lot of the internal Gutenberg styles are messy and overly specific, and that it’s difficult to reliably target UI that render at different locations in the DOM tree, e.g. Popovers.

@afercia reminded that specificity in Gutenberg is often because it needs to override wp-admin styles.

@itsjonq pointed out that the low specificity enforcement only works when starting from a clean slate, but there are workarounds available for integrating with legacy code (such as namespacing new styles to bump up specificity if needed). He shared his own helper library for this.

@afercia replied that this would create more specificity bloat, and @itsjonq observed that although that is the case, they would be sure to render correctly, i.e. there would be no clashes between old and new styles.

@laras126 made a helpful summary of needs that CSS-in-JS can help us meet:

• Enforcing low specificity
• Scoping styles
• Bundling CSS with components
• Enabling developers with varying backgrounds to write CSS safely

and offered to write up some notes about using single-declaration utilities as an alternative .

I also pointed out that CSS-in-JS makes it easier for JS devs, but harder for more UI-focused devs and designers to touch the code.

@laras216 asked if we should make this meeting a regular one, or at least have a follow-up. It was agreed to make it regular, and @noisysocks suggested same time next week.

@laras126 also shared a w3c proposal for selectors to reset specificity.

And that was it for this time!

#core-css-2