CSS Chat Summary: 26th March 2020

Full meeting transcript on Slack: https://wordpress.slack.com/archives/CQ7V4966Q/p1585256425000800

I (@isabel_brison) facilitated the meeting. 

CSS audit updates

  • I looked into our possibilities for visual regression testing and found that jest-image-snapshot integrates very well with our existing e2e testing tools. I’m preparing a prototype branch that I will share on the ticket soon.

Open Floor

@sabernhardt requested feedback on a patch for adding print styles to wp-admin. Discussion ensued, and we agreed that:

  • Currently, when printing out wp-admin, the only thing that doesn’t show is the admin bar. This is not optimal, and print styles should remove all interface features not relevant to page content.
  • The print styles should apply to all wp-admin pages that have content and/or lists.
  • Work on the initial ticket should attempt to hide all common interface elements for print
  • If much further work is needed on individual pages, we should create sub-tickets for easier tracking/review.

And that was all for this week!

#core-css, #summary

CSS Chat Summary: 19th March 2020

Full meeting transcript on Slack: https://wordpress.slack.com/archives/CQ7V4966Q/p1584651672176800

I (@isabel_brison) facilitated the meeting. 

CSS audit updates

  • I tested some automated tools we might use for the audit and updated 49638 with my findings;
  • @notlaura attended the design meeting and asked what designers would find useful with this audit (summary here).


  • Create a doc for the audit outline.
  • Ask the accessibility folks what they would find useful as an audit outcome.

We also discussed and agreed on reviewing, as part of the audit, where we are using px units and others that might have a detrimental effect on responsive behaviour. 

Coding standards

I asked about the history of stylelint-config-wordpress, which is used in Gutenberg but predates it by a few years. 

@netweb later replied with some informative context that I will add here:

  • The Stylelint config was created with Core in mind, based on existing styles and in alignment with PHP and JS standards.
  • It was then updated when added to Gutenberg, especially the Sass-specific rules.
  • It wasn’t added to Core because it was picking up lots of errors that would need to be fixed, so needed a committer to own the work.

The discussion then shifted to use of Grunt and Sass in Core. Sass is mainly used for theming in wp-admin, and the design team are looking at replacing its use with CSS custom properties. 

(@netweb later added that because Sass is widely used in Gutenberg this may be up for discussion, but likely Core will be dropping Grunt and moving to native npm scripts and @wordpress/scripts.)

This led to a discussion on IE support and graceful degradation. I suggested defining a set of rules for what is essential functionality that we need to support in IE, so we can be more confident in using shiny new tech for non-essential functionality. @michael-arestad suggested creating a ticket for that.

@michael-arestad expects that the biggest challenge post-audit will be implementing a predetermined selector format in a way that doesn’t break plugins with custom admin sections that depend on wp-admin styles. 

#core-css, #summary

CSS Chat Summary: 12th March 2020

Full meeting transcript on Slack: https://wordpress.slack.com/archives/CQ7V4966Q/p1584046820150600

I (@isabel_brison) facilitated the meeting. 

Following on from last week’s discussion about meeting times and daylight savings changes, no one expressed a preference so we decided to keep meeting at the same time relative to UTC.

CSS audit status update

Progress this week was essentially creating tickets:

I also reviewed a ticket for removing some !importants from the common.css file: https://core.trac.wordpress.org/ticket/47569

@notlaura suggested checking in with design at the weekly meeting regarding any particular pain points they might be having with core CSS.

There was nothing for open floor, so we finished early 🙂

#core-css, #summary

CSS Chat Summary: 5th March 2020

Full meeting transcript on Slack: https://wordpress.slack.com/archives/CQ7V4966Q/p1583442173087500

I (@isabel_brison) facilitated the meeting. 

We started by discussing if we should change the meeting time to accommodate daylight savings changes coming soon. No decision has been made yet; if you have an interest in this meeting and changing/not changing the hour would enable you (or not) to attend, please leave a comment below!

Open Floor

@notlaura started by asking how best to kick off a CSS audit as discussed last week. Based on last week’s discussion, I had already created a Trac ticket to start thinks off: https://core.trac.wordpress.org/ticket/49582 and asked everyone to add to it if I missed anything.

@notlaura asked about workflows for regression testing. There is no automated visual testing in core yet, and we discussed setting up visual snapshot testing before making any changes to existing CSS. 

We agreed that adding snapshot testing will not block the audit, as the outcome of the audit will be a set of recommendations, but we should have tests in place before we start acting on those recommendations.

We also discussed how to divide up the audit into sub-tasks, and agreed to create smaller tickets to tackle each part as needed. 

@notlaura also suggested leveraging static analysis tools for the audit, suggesting this collection of resources: https://github.com/mre/awesome-static-analysis#css

@sabernhardt suggested running the audit on a public version of WP (5.4 when it’s ready, or one of the RCs if we start earlier), and shared a report on plugin testing for 5.3: https://make.wordpress.org/core/2019/10/15/report-wp-5-3-admin-css-changes-tested-against-top-20-plugins/ .

At which point we hit the hour, and wrapped up. 

#core-css, #summary

CSS Chat Summary: 27th February…

CSS Chat Summary: 27th February 2020

Full meeting transcript on Slack.

I (@notlaura) facilitated the meeting. The agenda was:

  • Idea for a CSS audit
  • Open Floor

CSS Audit

I began the first agenda item, “Idea for a CSS audit” with some general information about CSS audits, and this could be a useful way to inform an approach for reducing specificty and using newer CSS features in WordPress. I also mentioned that, for WordPress specifically, an audit might include understanding the experience of CSS contributors since CSS can be a powerful way to bring in new folks.

I posted a few resources to information on CSS audits:

Initial thoughts were positive. @bemdesign said that reducing specificity would make things easier for the future, and @marybaum identified it would be valuable to know how much of the codebase is in use, and how much of it is something we could modernize.

The following comments indicated the scope of an audit would also be something to take into account: is this only admin CSS, or does it include themes and plugins?

@marybaum mentioned CSS in the default themes is an opportunity to model practices for other themes.

@afercia reminded us that large parts of admin CSS are also used by plugins, so we don’t want to refactor for the sake of introducing new features because it could break many plugins.

I added that the intent of a CSS audit would be to inform and update ongoing CSS standards, not solely introduction of new CSS features, and @peterwilsoncc emphasized the distinction between recommendation and accepted recommendation, and that the outcome of an audit would be more like a wish list and documentation of ideals.

I then asked about current conversations around design systems and coherence in the code-base, and linked to the Color Foundations in the Design Handbook.

@afercia mentioned that there is an additional color palette used in Gutenberg, and that the co-existence of the two palettes is an ongoing issue.

@peterwilsoncc emphasized that this type of project would involve all teams, editor, design, core, accessibility, at the very least.

These historical tickets came to light related to the audit conversation:

Open Floor

@xris asked about the importance of comments in CSS, and that most of the Core CSS seems to uncommented or that it does not follow commenting guidelines. They mentioned that the well-commented files – such as this one – are much easier to read.

The conversation then turned to the role of comments in general, and @afercia mentioned some history of the WordPress CSS comments: all CSS used to be a single, large file, and was commented when it was split into multiple files. Some of these legacy comments remain and are out of context.

I linked to the Comments section in the CSS Standards section of the handbook, and identified another high-level outcome of an audit could be to see where these standards are and are not followed throughout the code-base.

@afercia mentioned that we should publish this recurring meeting on the official / @peterwilsoncc followed up a few days later that this has been completed!

And that concludes the meeting summary!

#core-css, #summary

Dev Chat Summary – February 19th, 2020 (5.4 week 6)

@francina facilitated the chat on this agenda

@cenay took care of publishing the summary notes. Special thanks to @valentinbora, @amykamala and @audrasjb for the peer review on these summary notes. 

Full Meeting transcript on Slack

This devchat marked week 6 of the 5.4 release cycle.


WordPress 5.4 Beta 2 was released yesterday, February 18, as scheduled.

  • 5.4 Beta 3 is scheduled to be released on February 25, 2020. (Note to committers and maintainers, the cut off time to get bugs fixed and into WP 5.4 is February 25th, 20 UTC)
  • 5.4 is intended to be released March 31st, 2020.


  • Status report on the About page – content and design
  • Dev Notes status and how to proceed to get them all published in time for RC1 and the Field Guide. 
  • Highlighted Posts: XML Sitemaps Kickoff Meeting Announcement 
  • Component Check-ins

5.4 Beta 3 to be released on February 25th

As mentioned, WordPress 5.4 Beta 2 was released on February 18th, 2020. 

Please help by testing the Beta and reporting any bugs on WordPress Trac (or the Gutenberg GitHub repository).

@audrasjb suggested it would be great to schedule one or two bug scrubs before the next beta so we can punt/help the 134 remaining tickets in the milestone. @francina “seconded” with a call out for anyone who has spare time to help organize a bug scrub (See this post for how to run one). Open tickets for 5.4 can be found here (in order of priority). The Bug Scrub schedule for 5.4 lists scheduled scrubs for anyone to join in. 

Status Report on the About Page – Content and Design

@karmatosed stated everything is lining up to start the About page earlier this release. There will also be a push to document this. @melchoyce and @elmastudio are leading the design charge on this with @marktimemedia riding along to observe. @marybaum added they’ve got chunks of the copy written and she promised to share it with major-release-squad.  

Dev Notes Status 

..and how to proceed to get them all published in time for RC1 and the Field Guide.

@audrasjb reports since the last dev chat, four new dev notes were published:

@audrasjb also reports to date, they have a dev note published for about 50% of closed tickets with the `needs-dev-note` keyword in the milestone and 4 drafted dev notes ready to publish. He is very confident they’ll have all dev notes published by the end of the month (during last week before RC1)

@jorgefilipecosta reports he is tracking the progress of the block editor related dev notes and requests that any feedback before the dev notes are published would be great as the content there was not yet reviewed and is just what the original people involved in a PR think the dev note should contain.

@johnbillion asks that if anyone sees changes going into core that they think need a dev note, to leave a comment on the ticket. @audrasjb adds “if you think there are some important tickets that don’t have the `needs-dev-note` keyword, please get in touch with me”. @azaozz asks that you ensure the dev notes are really for developers and are concise and to the point and preferably with a code example of changed usage. @jorbin reminds us to remember the guidelines for posts and the need to have a peer review. 

@francina thinks having a separate page with guidelines on submitting dev notes would be helpful. @earnjam mentioned @desrosj would have a draft written up on the subject.

Highlighted Posts

@francina announced the highlighted post. There were no comments. 

Component Check-ins

  • News from Components
  • Components up for adoption (i.e. looking for maintainers): Filesystem API and Rewrite Rules
  • Components that need help
  • Cross component collaboration

News From Components


@valentinbora reports 1 week after he took up Administration, 40+ tickets have been triaged with 2-3 moved to other components. Per the previous meeting’s discussion regarding the very existence of the Administration component, @valentinbora thinks it’s here to stay.


@jeffpaul raised the issue of Gutenberg development overlapping existing Core components and how to best communicate with their respective maintainers/teams. @francina proposed a continued discussion about the cooperation between Components and Gutenberg out of the meeting.  

Widgets & Menus

@audrasjb noted 3 bug fixes with `commit` keyword and concerns about managing the transition and backward compatibility with tickets referring to current widgets/menus and new tickets referring to full site editing (FSE). 

@noisysocks recommends that maintainers of the widgets, customizer and editor components get involved and look at the relevant labels in the Gutenberg repository. 

Open Floor – Announcement

@pbiron announced that a new version of the WordPress Beta Tester plugin was released earlier today with a new feature. On the settings screen (`Tools > Beta Testing`), once you’ve already updated to either `Point release nightlies` or `Bleeding edge nightlies`, you’ll see a new option for `Beta/RC`. Once you’ve set that as your current stream, you’ll only be updated when the next beta or RC (or official) is released rather than the nightlies. 

One advantage of this new feature is that you’ll be able to update to beta or RC packages right in the Dashboard (Dashboard > Update) as soon as the packages are built during the release parties if you’re not comfortable using wp-cli.  Hopefully, this will increase the pool of testers during the release parties.

As the meeting was over time, the remaining two topics from today’s agenda were not started. 

Action Items

These items were discovered within the content as stated action items.

  • @francina to add the bug scrubs to the meetings page (like she did for 5.3)
  • @francina to add “creating a separate page with dev note guidelines, adding comments to a ticket” to her desiderata. Check with @desrosj who might have a draft of a page with details about how to write a good dev note.
  • @audrasjb and @welcher should look at Widgets/Menus issues/PR on Gutenberg
  • @noisysocks to add a ‘call for volunteers’ to the next core editor chat to implement proactive communications from Gutenberg to those component maintainers to help find ways to work together.
  • @jeffpaul suggests we call out notice to the new WordPress Beta Tester plugin in the Beta 3 blog post (and future posts as well) so folks looking to help test have a starting place. 
  • @clorith wants to chat about how to move more things into a React world and how to do it outside of Gutenberg.
  • @noisysocks to “put something up” on Make/Core to continue the conversation about cooperation between Components and Gutenberg (i.e. Cross Teams Collaboration).

Next Meeting

Meetings for #devchat take place weekly in the #core channel. The next meeting is Wednesday, Wednesday, February 26, 2020 at 21:00 UTC

#5-4, #summary

CSS Chat Summary: 20th February 2020

Full meeting transcript on Slack.

I (@isabel_brison) facilitated the meeting. 

The agenda was empty except for Open Floor.

I proposed a question to reflect on for this and future meetings: “What, if anything, should we improve about our CSS in core and/or gutenberg? And what, if anything, are we already doing particularly well? “ (If anyone reading this would like to contribute an answer, feel free to pop into the next meeting, or just add a note to the agenda if you can’t make it to the actual meeting!)

@bemdesign expressed concern that the adoption of modern development approaches, especially CSS-in-JS, and the build tooling necessary for React apps, might over-complicate the process for new developers to get started.

We discussed how to ease the learning curve and make it easier for new developers to get involved: 

  • Choosing tools with an easier syntax (in the CSS-in-JS case)
  • Education and documentation
  • Out-of-the-box build configs, such as @wordpress/scripts

Then, going back to the initial question, @peterwilsoncc suggested overly high specificity of some CSS selectors could be improved, and ideally we should have a consistent level of specificity throughout.

@youknowriad added that we should try to create style variations in components instead of trying to override default component styles with additional classnames.

@laras126 suggested using single-declaration utility classes that sit further down the cascade, and passing in classnames as props.

We agreed backward compatibility may make it hard to change our current approach completely.

Open Floor

@laras126 shared a link to a CSS working group discussion on the benefits of introducing a new CSS version.

We briefly discussed how a new version (CSS4) might be useful to us: adding visibility to current best practice approaches and as an encouragement to developers to learn the spec better.

That was all!

#core-css, #summary

WP Notify Meeting Recap – February 03 2020

This is a recap of the WP Notify meeting held on Monday, February 17, 2020, 14:00 UTC. You can read the meeting discussion here.

We opened by reviewing the Use Cases section. We moved an item related to which users plugin or theme notifications should be shown to, down to a later section in the document (Wish List Items), to be discussed at the relevant time.

@folletto noted that “here we are a bit playing a double role, use cases for users and use cases for developers. These luckily overlap a bit, and I think what we have is a good compromise”. @psykro left a comment that we might need to expand on use cases. We also had a brief discussion about the section on state changes. While the ultimate goal would be for WP Notify to replace those as well, this might not happen in our first release.

We reviewed the current status of the new Current Status section and had a discussion on the terminology related to the different types of notifications. @folletto suggested the following:

  • Notification = a notification hub, with maybe a dropdown or a container of some sort, that shows alerts across pages
  • On Page = a local notification, shown only on a specific page, and contextual to the page content

Finally we removed the admin_notices graphic from the Current Status section.

As always, we invite the community to share their feedback on any of these changes to the document, either here in the comments or on the document itself.

Next Slack Meeting

📅 Monday, February 24 @ 14:00 UTC

#feature-plugins, #feature-notifications, #summary

WP Notify Meeting Recap – February 03 2020

This is a recap of the WP Notify meeting held on Monday, February 03, 2020, 14:00 UTC. You can read the meeting discussion here.

This was a very quiet meeting, with only @psykro and @hrmervin attending. We continued along with the planned items in the requirements document.

The Objectives section seems complete, and no one has added any further comments on the document or the recap post, so we’re going to move forward and accept this as it stands

We reviewed the current status of the new Use Cases section. @psykro added a comments on the State item as well as comments around how we see notifications being sent to users based on their role.

Based on the fact that there were no other voices in the meeting, we ended the meeting early. As always we welcome feedback from the community in the current progress of finalizing the requirements document.

Next Slack Meeting

📅 Monday, February 10 @ 14:00 UTC

#feature-plugins, #feature-notifications, #summary

JavaScript Chat Summary: January 28, 2020

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack transcript).

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Create block package

(Slack conversation)

New @wordpress/create-block package was merged in the past week: https://github.com/WordPress/gutenberg/pull/19773. The package is meant to help plugin developers scaffold new blocks with a single command npm init @wordpress/block.

It is already available on NPM. It was published today as part of the next Gutenberg plugin release process that started on Monday.

Playwright vs Puppeteer

(Slack conversation)

Last week, Microsoft announced its new “Playwright” tool, which is very much like Puppeteer and created by many of its original contributors. The main draw here is that it supports multiple browsers, whereas we’ve always been limited to just Chrome using Puppeteer.

We discussed whether we should consider migration from Puppeteer to Playwright but we decide to postpone the decision for some time. The reason for that is the uncertainty about how those two projects evolve. The fact that the Puppeteer team has just released a new version that supports the Firefox browser makes it even more interesting. We plan to revisit this topic in the future.

#core-js, #javascript, #summary