# CSS Chat Summary: 9th…

Chat Summary: 9th April 2020

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

I (@notlaura) facilitated the meeting. A bit delayed in posting the summary – will do better next week!

CSSCSS Cascading Style Sheets. audit updates

We reviewed the process for the audit and discussed the high-level ticketticket Created for both bug reports and feature development on the bug tracker. “Create a report outline for Audit” #49637. What should a report outline look like? Currently it exists in this Google Doc as a place to collect data and gradually organize it.

@joyously asked if the report would be an ongoing process or pinned to a specific releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. which brought up an idea and conversation around how to express the audit data. @michael-arestad suggested a publicly hosted page that runs and updates on each release. This could be immensely helpful for tracking improvements to the codebase! That hinted at another high level ticket, “Determine methodology recommendations for audit” #4963 – which may be a mixture of automated processes and manual work depending on the data we need.

How would we pull off recurring, release-based audit results? I proposed that the first steps are getting the data the first time and keeping track of how we did it, while determining how we want to present the data e.g. by edit screen or by categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging., other, or all of the above.

@joyously suggested incorporated the automated audit results alongside the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 reference in the developer subdomain and .org.

To close up the audit update, I identified the following as some items that would be good starting points for contributors willing to do some manual code inspecting:

  • < IE 11 Hacks – maybe start by finding an example of a few and seeing if they are in mutliple locations
  • State of comments – what are the comment styles that are used
  • Location of outdated or brute-force layout practices (e.g. floats, positioning and pixel nudging)

Open Floor

@joyously posed the age-old question: “When does our browser support for IE11 go away?” @michael-arestad answered with “When fewer users use the browser. Tell your friends.” Wise words! We reviewed the browser support best practices and that when IE 11 is < 1% usage, we can abandon support. Current usage information can be seen here.

The conversation then turned to custom properties and replacing the adminadmin (and super admin) color schemes with custom properties which seems like a great candidate for introducting them to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. No ticket for that … yet! @michael-arestad mentioned the benefits of keeping in sync with the NPM components 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/. After the meeting, we discussed the intricacies of using the JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. components in wp-admin, and if you’re interested, check out the meeting transcript here!

That was all for this week!

#summary #core-css