Opened 5 years ago
Last modified 4 years ago
#49637 new enhancement
Create a report outline for CSS audit
Reported by: | 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
!important
s - 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
#4
@
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)
This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.
5 years ago
#6
@
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
@
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
@
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.
I'd add a to the list:
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.