[wp-trac] [WordPress Trac] #49638: Determine methodology recommendations for CSS audit

[WordPress Trac]

#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