CSS Chat Summary: 16th July 2020

CSSCSS Cascading Style Sheets. audit status updates

What is the purpose of recurring reports, and what data is useful in recurring reports?

To summarize input from @isabel_brison and @ryelle, the purpose of recurring reports is check on the health of our CSS code regularly, and to monitor the code-base to ensure known problems do not recur. @ryelle‘s CSS audits tool seems like the right one for this job. We discussed stylelint which is good for ensuring issues aren’t committed, but the wp-adminadmin (and super admin) CSS code-base is such that we would have to disable too much for it to be useful. That said, @ryelle pointed out that the potential to write our own rules for autofixing with stylelint.

In terms of what data is useful, @isabel_brison suggested:

  • new values for e.g. colors, margins, etc. are being introduced as little as possible;
  • avoiding use of px units;
  • specificity isn’t increasing.

Action item: Add a comment to the CSS audit ticket with a list of what data should be tracked.

Additional Updates

@ryelle took a look into how Dashicons are added in CSS, but found the need for many edge cases that it would be futile to attempt to standardize. Considering that, and the fact that the icon font is slated to be replaced with SVG, it seems a clear decision to exclude Dashicons from the CSS audit, unless the use of pixels impacts responsivity or 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).

Color scheming updates

Is it useful to distinguish custom properties implementation work as #49930 and keep #49999 for iteration and naming exploration?

I started this conversation by clarifying the question as whether this experimental PR adding custom properties to color schemes in wp-admin based on the 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/ implementation was a separate initiative from than the further reaching color scheme work we have been discussing in #49999. We had some differing opinions here – where the implementation work could serve as an MVPMinimum Viable Product "A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia for color schemes, but on the flip side, it is not addressing the goals of the color scheme initiative, which are:

  • Creating a new color scheme should be similar to filling out a form with color values
  • All colors in the wp-admin should be controlled by the color schemes
  • Reduce the number of colors in use by providing default color palettes with varying shades

@youknowriad expressed that any scheme will require a main color, so this implementation does get us closer, and @ryelle expressed that we can’t expect a system designed around a main color and variations to work in every color scheme (see this example) when we are looking to support things like dark mode and high contrast color schemes.

The goal of the Gutenberg color scheme implementation was to support admin color schemes in Gutenberg components and UIUI User interface, and using custom properties to solve issues of duplication in the CSS. By adding this approach to CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., @youknowriad believes we can have more consistency in the way existing color schemes are used (they are currently not consistent).

Review screenshots annotations with options for naming

I shared these *rough* mockups for a start on how we might name colors that would apply consistently across color schemes:

Given they are very rough mockups, aspects like a namespace and other details will come later – I pointed to the aspects like base__text and base__text-active for feedback. @youknowriad expressed that he does not think that a color name should include its context because the design of wp-admin can change over time, while @ryelle (and I) think the opposite – that it should be possibly more specific that these are menu colors so that they are not unintentionally used in non-menu contexts.

We then discussed an example when changing the menu background color. With this approach, it would be assigning a new value to a variable like --color-menu-bg, but @youknowriad pointed out that that wouldn’t work because all the menus use color: white across admin schemes, which @ryelle pointed out is not the intent for #49999. The intent is that the color would also be controlled by a variable and updated accordingly.

Given this example, @youknowriad mentioned that this capability seems beyond the scope of admin themes and more like a “mode”. And perhaps the different admin theme colors should support a mode. I summarized this as something like Ectoplasm – Light / Ectoplasm – Dark. @ryelle expressed that all of this, regardless of the APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. semantics, needs to be part of the same infrastructure in order to support the flexibility required to implement both high contrast and low contrast color schemes.

That was all for this week!

#core-css, #summary