I (@isabel_brison) facilitated the meeting based on this agenda.
Full meeting transcript on Slack
First point: how to set standards for using CSS Cascading Style Sheets. grid in core Core is the set of software required to run WordPress. The Core Development Team builds WordPress., 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 Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.).
@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 Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. 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 (and super 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 The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/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.
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 User interface 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!