CSS Chat Summary: 19th March 2020

Full meeting transcript on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.: https://wordpress.slack.com/archives/CQ7V4966Q/p1584651672176800

I (@isabel_brison) facilitated the meeting. 

CSSCSS Cascading Style Sheets. 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 accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/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 GutenbergGutenberg 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/ 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 CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. in mind, based on existing styles and in alignment with PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher and JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. 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 committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. to own the work.

The discussion then shifted to use of Grunt and Sass in Core. Sass is mainly used for theming in wp-adminadmin (and super 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 ticketticket Created for both bug reports and feature development on the bug tracker. 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