Full meeting transcript on Slack: https:\/\/wordpress.slack.com\/archives\/CQ7V4966Q\/p1595538061342900<\/p>\n\n\n\n
I (@<\/span>notlaura<\/a>) facilitated the meeting.<\/p>\n\n\n\n @<\/span>isabel_brison<\/a> had a few updates to report!<\/p>\n\n\n\n This data can be seen in the audit report Google Doc<\/a>. It looks like the remaining items are media query counts and the history of CSS coding standards and the stylelint configuration. @<\/span>isabel_brison<\/a> suggested collecting related documentation and tickets for this history piece, and using @<\/span>ryelle<\/a>\u2018s css-audit tool to accommodate the media query counts.<\/p>\n\n\n\n For the CSS audit of wp-adminadmin<\/span> (and super admin)<\/span><\/span><\/span>, #49582<\/a>, 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<\/a>.<\/p>\n\n\n\n One outcome of the meeting previous to this one was the concept of color \u201cthemes\u201d vs. \u201cmodes\u201d. I started off the conversation with this question: <\/p>\n\n\n\n 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:<\/p>\n\n\n\n (where \u201cEctoplasm\u201d = any of the admin themes)<\/p>\n\n\n\n @tellthemachines said that she saw \u201cdark mode\u201d or \u201chigh contrast\u201d to be a collection of themes that support that criteria. We discussed that \u201cmodes\u201d are most like a way to categorize themes, and are not a separate implementation.<\/p>\n\n\n\n I shared a link @<\/span>youknowriad<\/a> posted during the last meeting to a prototype of dark mode in the editor<\/a>. In this prototype, dark mode is a separate toggle that can be applied on top of themes. I also shares a code snipped @<\/span>youknowriad<\/a> posted before as an example of themes and modes treated separately:<\/p>\n\n\n We discussed that the rigidity of this approach will be restrictive for other themes and accommodating they variety of user needs required for accessibilityAccessibility<\/span> 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 \u201cdirect access\u201d (i.e. unassisted) and \u201cindirect access\u201d meaning compatibility with a person\u2019s assistive technology (for example, computer screen readers). (https:\/\/en.wikipedia.org\/wiki\/Accessibility)<\/span><\/span><\/span>. In this case, the text for So, to conclude here:<\/p>\n\n\n\n I shared a link to CSS Scroll Snap<\/a> \u2013 the possibility of slider-like interfaces with only CSS is not so far in the future! <\/p>\nCSSCSS<\/span> Cascading Style Sheets.<\/span><\/span><\/span> Audit Updates<\/h2>\n\n\n\n
List of data to track on a recurring basis <\/h3>\n\n\n\n
Color Scheming Updates<\/h2>\n\n\n\n
Themes vs. Modes<\/h3>\n\n\n\n
\n.button {\n color: var( --wp-admin-theme-color );\n background: white;\n}\n\n.is-dark-mode .button {\n background: var( --wp-admin-theme-color );\n color: white;\n}\n\n.my-admin-scheme {\n --wp-admin-theme-color: blue;\n \/\/ potentially other variables\n}\n<\/pre><\/div>\n\n\n.button<\/code> in dark mode will always<\/em> be white, but we need to accommodate lower contrast dark mode themes as well. @tellthemachines mentioned that the \u201cdecisions not options\u201d motto of WordPress, and that regarding accessibility, it should be the opposite (and after the meeting @<\/span>ryelle<\/a> followed up with the phrase \u201coptions not restrictions\u201d \u2026 nice!).<\/p>\n\n\n\nCSS Latest and Greatest Link Share<\/h2>\n\n\n\n