[wp-trac] [WordPress Trac] #49638: Determine methodology recommendations for CSS audit
WordPress Trac
noreply at wordpress.org
Fri Mar 13 05:26:58 UTC 2020
#49638: Determine methodology recommendations for CSS audit
------------------------------+------------------------------
Reporter: notlaura | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Build/Test Tools | Version:
Severity: normal | Resolution:
Keywords: | Focuses: css
------------------------------+------------------------------
Comment (by isabel_brison):
I had a play with stylelint: installed it in a local branch, and added a
very basic config to test the rules that seemed useful for audit purposes.
Here are my takeaways:
* `no-descending-specificity` doesn't help much because it compares
different selectors, e.g. `Expected selector ".about__container p" to come
before selector ".about__section .column p:last-of-type"`, which doesn't
tell us a lot because we have huge files with sections related to
different components of a page, so specificity levels naturally go up and
down.
* `no-duplicate-selectors` returned quite a few results. This is worth
looking into to check whether duplicates are accidental or if they are
leveraging the cascade to override previous rules.
* `selector-max-specificity` is the most useful of the lot. I ran it with
a limit of "1,3,2" (that's one id, three classes and two element
selectors) and got a scary big amount of results. Here is where we
probably want to go file by file and break down how much of that selector
bloat we can get rid of. Ideally, we should be aiming for something like
"0,2,0", but if that's too much to ask for, then let's see how low we can
bring it without having to rewrite everything 😅
Also, for a neat visual overview of specificity in files, this tool is
quite nice: https://isellsoap.github.io/specificity-visualizer/
Regarding dead code removal, we can try running something like
[https://github.com/purifycss/purifycss], to get some idea of where to
look at least.
For removal of old IE-specific code, I think there's no option but going
through everything manually 😟
What I'm thinking is, if we're going to come up with actionable
recommendations, we'll have to do quite a bit of manual testing, changing
stuff and checking what breaks. The visual regression testing would be a
good helper for that, so perhaps we should set it up sooner rather than
later.
Also, I have a question: should we take plugins into account at all at
this stage? If we're not changing any of the actual styling in wp-admin,
is it even possible for there to be side-effects for plugins?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/49638#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list