Full meeting transcript on Slack: https://wordpress.slack.com/archives/CQ7V4966Q/p1595538061342900
I (@notlaura) facilitated the meeting.
CSS Cascading Style Sheets. Audit Updates
@isabel_brison had a few updates to report!
- Audited CSS in JS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. files
- Values/counts for font-family and letter-spacing (only 3 for the latter!)
- Values/counts for z-index
This data can be seen in the audit report Google Doc. It looks like the remaining items are media query counts and the history of CSS coding standards and the stylelint configuration. @isabel_brison suggested collecting related documentation and tickets for this history piece, and using @ryelle‘s css-audit tool to accommodate the media query counts.
List of data to track on a recurring basis
For the CSS audit of wp-admin (and super admin), #49582, we have discussed running recurring reports, and this agenda item was to determine what data should be tracked in a recurring report. We decided that, for now, we can place to include the same data we are including now where the collection is automated with the css-audit tool or stylelint. These items can be seen in the audit report Google doc.
Color Scheming Updates
Themes vs. Modes
One outcome of the meeting previous to this one was the concept of color “themes” vs. “modes”. I started off the conversation with this question:
Do you see a distinction between the nature of admin color schemes and something like dark mode, in the way we treat colors? For example:
- Ectoplasm – Dark
- Ectoplasm – High Contrast
(where “Ectoplasm” = any of the admin themes)
@tellthemachines said that she saw “dark mode” or “high contrast” to be a collection of themes that support that criteria. We discussed that “modes” are most like a way to categorize themes, and are not a separate implementation.
I shared a link @youknowriad posted during the last meeting to a prototype of dark mode in the editor. In this prototype, dark mode is a separate toggle that can be applied on top of themes. I also shares a code snipped @youknowriad posted before as an example of themes and modes treated separately:
.button {
color: var( --wp-admin-theme-color );
background: white;
}
.is-dark-mode .button {
background: var( --wp-admin-theme-color );
color: white;
}
.my-admin-scheme {
--wp-admin-theme-color: blue;
// potentially other variables
}
We discussed that the rigidity of this approach will be restrictive for other themes and accommodating they variety of user needs required for 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). In this case, the text for .button in dark mode will always be white, but we need to accommodate lower contrast dark mode themes as well. @tellthemachines mentioned that the “decisions not options” motto of WordPress, and that regarding accessibility, it should be the opposite (and after the meeting @ryelle followed up with the phrase “options not restrictions” … nice!).
So, to conclude here:
- The notions of “dark mode” and “high contrast” seem like categories for color schemes – they are characteristics of a color scheme, not separate features.
- In order to provide options, not restrictions, regarding accessibility, it will be important to have control over all colors in the implementation of color schemes.
CSS Latest and Greatest Link Share
I shared a link to CSS Scroll Snap – the possibility of slider-like interfaces with only CSS is not so far in the future!
#core-css, #summary
