CSS Chat Agenda: 6th August 2020

This is the agenda for the upcoming CSSCSS Cascading Style Sheets. meeting scheduled for Thursday, August 6, 2020, 5:00 PM EDT.

This meeting will be held in the #core-css channel in the Making WordPress 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/..

If there’s any topic you’d like to discuss, please leave a comment below!

  • Housekeeping
    • How can we help new meeting attendees to get up to speed with #core-css initiatives?
    • A different structure for meeting agendas
  • CSS audit update
  • Color scheming updates
    • Code-base colors compared with colors designers reference
  • CSS Link Share

#agenda

CSS Chat Summary: 30 July 2020

Full meeting transcript on Slack: https://wordpress.slack.com/archives/CQ7V4966Q/p1596142878412300

I (@notlaura) facilitated the meeting.

CSSCSS Cascading Style Sheets. Audit Updates

No CSS audit updates this week.

Color Scheming Updates

Global vs. UIUI User interface based color naming

tl;dr – We’ve gotten sidetracked by naming!

@ryelle pointed out @kburgoine‘s comment on the color schemes ticket #49999 – it gives an excellent summary of where are now and suggests a path forward. We discussed being sidetracked by the details in naming. While that will be important for an implementation, we aren’t there yet and as @kburgoine suggested in the ticketticket Created for both bug reports and feature development on the bug tracker., we first need to figure out a set of colors to work with based on what we have learned in the audit. @ryelle referenced this part of the comment for our next steps:

Look at the default colour usage in the adminadmin (and super admin) (which has been done as part of the audit already), identify the main colours (including colours not currently included in schemes i.e background-colour) and try to whittle it down to a usable/manageable colour palette

The goal here is to create a color inventory that can then be mapped into custom properties, which can then be used to implement one of the existing color schemes. I mentioned that I got access to the WordPress Figma library which can help us with the color inventory step.

@kburgoine‘s comment refers to this post about building a dark mode on StackOverflow and @ryelle mentioned it is a great read.

Dark mode as a toggle vs. a categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. for schemes

@danfarrow mentioned the concept of scheme categories makes sense to him, and @ryelle mentioned that we will likely start with default light and dark color schemes, and the others can be either. We can use some default detection for prefers-color-scheme and use the default dark scheme for users who have that preference.

But…this is all getting ahead of things again 🙂

I summarized our next steps for color schemes to be:

CSS Latest and Greatest Link Share

@danfarrow shared CSS Sweeper, an implementation of MineSweeper using only CSS and HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.!! This uses the Space Toggle trick to manage state without JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/.. So cool!

#core-css, #summary

CSS Chat Agenda: 30 July 2020

This is the agenda for the upcoming CSSCSS Cascading Style Sheets. meeting scheduled for Thursday, July 30, 2020, 5:00 PM EDT.

This meeting will be held in the #core-css channel in the Making WordPress 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/..

If there’s any topic you’d like to discuss, please leave a comment below!

  • Pronouns
  • CSS Audit Updates
    • Collecting tickets and docs about Stylelint and CSS coding standards
    • Media query counts with css-audit tool
  • Color Scheming Updates
    • UIUI User interface agnostic color naming (e.g. global-text-color vs. menu-text-color)
    • Considering unified approach for the editor and wp-adminadmin (and super admin) – e.g. dark mode toggle vs. dark mode as a scheme categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging..
  • CSS Latest and Greatest Link Share

#agenda, #core-css

CSS Chat Summary: 23 July 2020

Full meeting transcript on Slack: https://wordpress.slack.com/archives/CQ7V4966Q/p1595538061342900

I (@notlaura) facilitated the meeting.

CSSCSS Cascading Style Sheets. Audit Updates

@isabel_brison had a few updates to report!

  • Audited CSS in JSJS 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-adminadmin (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 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). 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

CSS Chat Agenda: 23 July 2020

This is the agenda for the upcoming CSSCSS Cascading Style Sheets. meeting scheduled for Thursday, July 23, 2020, 5:00 PM EDT.

This meeting will be held in the #core-css channel in the Making WordPress 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/..

If there’s any topic you’d like to discuss, please leave a comment below!

  • CSS Audit Updates
    • List of data to track in #49582
  • Color Scheming Updates
    • Discuss Themes vs Modes
    • Review round 2 of annotated screenshot
  • CSS Latest and Greatest Link Share

#agenda, #core-css

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

CSS Chat Agenda: 16th July 2020

This is the agenda for the upcoming CSSCSS Cascading Style Sheets. meeting scheduled for Thursday, July 16, 2020, 5:00 PM EDT.

This meeting will be held in the #core-css channel in the Making WordPress 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/..

If there’s any topic you’d like to discuss, please leave a comment below!

  • CSS audit status updates
    • What is the purpose of recurring reports, and what data is useful in recurring reports?
  • Color scheming updates
    • Is it useful to distinguish custom properties implementation work in ticketticket Created for both bug reports and feature development on the bug tracker. #49930 and #4999 is ongoing iteration and naming exploration?
    • Review screenshots annotations with an option for naming (#4999)
    • What data do we need to generate a color scheme? e.g. @mixin adminadmin (and super admin)-scheme($color-primary) – the lightness/darkness values for all color schemes will not be the same, so we need to pass more information to the mixin.
  • CSS Latest and Greatest Link Share
  • Open floor

#agenda, #core-css

CSS Chat Summary: 9th July 2020

Full meeting transcript on Slack: https://wordpress.slack.com/archives/CQ7V4966Q/p1594328432163400

I (@notlaura) facilitated the meeting.

CSSCSS Cascading Style Sheets. audit updates

There were no specific audit updates this week. I suggested starting a conversation about next steps for the audit since we have a good amount of data collected in the Google Doc, but that is not an ideal format for presenting the data. @ryelle indicated that once we figure out what data format will be useful, we can iterate on the CSS audit tool so that it can be run as a report.

@kburgoine asked about the purpose of regular audits – is it just about the numbers, or are there other conclusions we can makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). based on a regular report?

For now, we can think about what purpose regular audits would serve, and what data we would like to regularly audit (e.g. for tracking a certain initiative or progression in the codebase).

Color scheming updates

@youknowriad reported that has worked on a PR implementing the system of custom properties 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/ for wp-adminadmin (and super admin), and summarized the work in a comment on ticket #49999. @ryelle clarified that the intent of that ticketticket Created for both bug reports and feature development on the bug tracker. was to rethink color schemes to be fully flexible vs. re-doing current color schemes with custom properties. @youknowriad explained that having the variables working at least with one color can get us closer to a full featured system that can support dark mode.

@kburgoine asked if an overall strategy for using custom properties had been defined, and @youknowriad said that the deeper discussions are still to be had, but that having a concrete PR can be useful. He is looking for feedback on the PR regarding the base color, the naming (decided by the implementation in Gutenberg), and iteration / discussion on subsequent variables as needed. @ryelle mentioned that the naming is a sticking point since we have been discussing ways to rethink the naming system.

I asked how, in the Gutenberg mixin, the primary color had been selected since it was not based on a specific variable in the existing color schemes. @youknowriad replied that it was chosen as the most important colors of the color scheme, and @ryelle mentioned it likely had to do with contrast.

CSS Latest and Greatest Link Share

@danfarrow shared a run of CSS Stats on WordPress.org 🙂

I shared Style Stage, a project that is a reincarnation of “CSS Zen Garden” with modern CSS.

That was all for this (last) week!

#core-css, #summary

New CSS styles for buttons with disabled state in WP 5.5

[last modified on July 10, 2020 at 10:58 UTC]

In WordPress 5.5, the styles for both primary and secondary buttons were updated in the WordPress adminadmin (and super admin) to produce a more consistent experience when the buttons are disabled.

Previously, the disabled button styling was inconsistent in the WordPress admin between the default and alternate color schemes. Styling was also different between primary and secondary buttons.

Prior to WordPress 5.5 betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 was decided to simplify all disabled button states to use the same design. There is no need for disabled buttons to convey primary and secondary visual semantics since the disabled state denotes that status.

This change introduces new unified CSSCSS Cascading Style Sheets. declarations for disabled buttons:

color: #a0a5aa;
background: #f7f7f7;
border-color: #ddd;

Those above CSS declarations are used both in the WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. dashboard and the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor.

New styles for disabled primary and secondary buttons:

PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party authors and WordPress developers are encouraged to update the CSS styles they use for their buttons with disabled state for better consistency across the ecosystem. Of course, they are even more encouraged to not use custom styles and to rather user default core UIUI User interface styles instead.

Disabled state of buttons can be easily targeted in CSS, for example by using the following selectors:

button[disabled],
input[type=button][disabled],
input[type=submit][disabled] {
	color: #a0a5aa;
	background: #f7f7f7;
	border-color: #ddd;
}

For reference, see the related TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker.: #48709.

Props @whyisjake, @desrosj and @afercia for proofreading.

#5-5, #accessibility, #core-css, #dev-notes

CSS Chat Agenda: 9th July 2020

This is the agenda for the upcoming CSSCSS Cascading Style Sheets. meeting scheduled for Thursday, July 18, 2020, 5:00 PM EDT.

This meeting will be held in the #core-css channel in the Making WordPress 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/..

If there’s any topic you’d like to discuss, please leave a comment below!

  • CSS audit status update
    • Next steps brainstorming
  • Color scheming updates
    • Review screenshot annotations
  • Open floor
  • CSS latest and greatest link share

#agenda, #core-css