Make WordPress Core

Opened 5 years ago

Last modified 4 years ago

#49637 new enhancement

Create a report outline for CSS audit

Reported by: notlaura's profile notlaura Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Administration Keywords:
Focuses: css, coding-standards Cc:

Description

This ticket is under the umbrella CSS audit ticket #49582, and is for creating a report outline for the audit.

The work to create a report outline consists of:

  • Decision making regarding what the report should contain,
  • Creating follow-up tickets for collecting data to populate the report,
  • Creation of a "Report Outline Document" or similar, that can be updated with results or changes in requirements as the audit is performed.

The report outline document is essentially a list of what we want to know as a result of the audit. For example:

  • Determine method of categorization of existing CSS (e.g. by files, area in admin)
  • Category (from above) that contains highest specificity
  • List of unique values for each of a list of properties, and number of occurrences
  • Locations and total count of !importants
  • State of CSS comments in each of the categories
  • Location of outdated or brute-force layout practices (e.g. floats, positioning and pixel nudging)
  • Longest selector

Change History (10)

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


5 years ago

This ticket was mentioned in Slack in #design by notlaura. View the logs.


5 years ago

#3 @michaelarestad
5 years ago

I'd add a to the list:

  • Number of IDs used in selectors
  • Number of unique colors and instance counts of each color

Something a bit harder to identify (and maybe unnecessary) will be identifying where there are repeated instances of a design pattern using different CSS with similar results. I suspect this is unnecessary because if actions are taken to refactor/clean up the CSS based on the above list, this will likely be resolved on its own.

It would also be interesting to identify the various selector patterns used, but again I'm not sure that's necessary.

#4 @notlaura
5 years ago

Additions mentioned in #core-css meeting on 3/19/20:

  • History of core CSS coding standards and stylelint configuration
  • Units
    • instances of px/em/rem/%age and count of use with properties - automated finding
    • inspection/evaluation of those areas with pixels and brute force layout approach
  • < IE 11 Hacks (todo: find list of hacks to keep an eye out for)
Last edited 5 years ago by notlaura (previous) (diff)

This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.


5 years ago

#6 @notlaura
5 years ago

Let's use this Google doc for the report outline - I've added what's mentioned in this ticket so far: https://docs.google.com/document/d/1afy5gOZ6qZLs7ud2mzqHAo1ZI7stP5LRDMzm2IwJV04/edit?usp=sharing

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


5 years ago

#8 @isabel_brison
5 years ago

Adding a few questions/notes here:

Determine method of categorization of existing CSS (e.g. by files, area in admin)

I would propose files, as that will simplify obtaining the data with automated tools. Files already correspond roughly to admin areas anyway.

List of unique values for each of a list of properties, and number of occurrences

Which properties should be checked here? I’m thinking we could detect usage of fixed (px) widths and heights, and that would help determine problems with responsive behaviour. We can also check for use of e.g. floats, to locate outdated layout practices.
I'm wondering if unique values should be an item in itself, because it seems more like a tool to help with other items.
I'm also tempted to add an item for responsive problems.

State of CSS comments in each of the categories

Not sure how we can measure this in a useful way. Outside of weird hacks that are usually commented, it’s unclear to what extent the CSS needs additional documentation.

Dead code

I suspect this is where we'll get the biggest benefits performance-wise. It also needs a bit of investigation into the best way of detecting dead code, short of actually removing code and checking for changes 😅

Units

Will these be useful outside of responsive/layout concerns? We might not need a separate section for them.

#9 @notlaura
5 years ago

Noting that in CSS Chat 6/4/20 we discussed that when auditing JS and PHP files that contain CSS, we should keep a specific watch for CSS that contains units related to design - specifically colors.

This ticket was mentioned in Slack in #core-css by isabelbrison. View the logs.


4 years ago

Note: See TracTickets for help on using tickets.