CSS Chat Agenda: 2nd April 2020

This is the agenda for the upcoming CSS meeting scheduled for 2nd April, 21:00 UTC.

This meeting will be held in the #core-css channel  in the Making WordPress Slack.

If there’s any topic you’d like to discuss, please leave a comment below!

Agenda

  • CSS audit status update
  • Open floor

#agenda, #core-css

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 Agenda: 26th March 2020

This is the agenda for the upcoming CSS meeting scheduled for 26th March, 21:00 UTC.

This meeting will be held in the #core-css channel  in the Making WordPress Slack.

If there’s any topic you’d like to discuss, please leave a comment below!

Agenda

  • CSS audit status update
  • Open floor

#agenda, #core-css

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

Todoes

  • 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 Agenda: 19th March 2020

This is the agenda for the upcoming CSS meeting scheduled for 19th March, 21:00 UTC.

This meeting will be held in the #core-css channel  in the Making WordPress Slack.

If there’s any topic you’d like to discuss, please leave a comment below!

Agenda

  • CSS audit status update
  • Coding standards: differences between Core and Gutenberg
  • Open floor

#agenda, #core-css

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 Agenda: 12th March 2020

This is the agenda for the upcoming CSS meeting scheduled for 12th March, 21:00 UTC.

This meeting will be held in the #core-css channel  in the Making WordPress Slack.

If there’s any topic you’d like to discuss, please leave a comment below!

Agenda

  • CSS audit status update
  • Open floor

#agenda, #core-css

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 Agenda: 5th March 2020

This is the agenda for the upcoming CSS meeting scheduled for 5 March 2020 9pm UTC.

This meeting will be held in the #core-css channel  in the Making WordPress Slack.

If there’s any topic you’d like to discuss, please leave a comment below!

Agenda:

  • Open Floor

#agenda, #core-css

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