CSS Cascading Style Sheets. 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 (and super 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 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/, 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 Core is the set of software required to run WordPress. The Core Development Team builds WordPress., accessibility 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), 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
