CSS selector specification drafts at some point had a concept of "dynamic specificity" where the specificity of a selector depended on the element it matched. It was only ever used with :matches and :nth-child pseudo classes and has subsequently been removed. Selector specificity can now always be computed statically. There is a ton of code to support this obsolete feature. It can be removed.
Created attachment 396264 [details] patch
Created attachment 396265 [details] patch
Created attachment 396266 [details] patch
Created attachment 396267 [details] patch
Created attachment 396268 [details] patch
Comment on attachment 396268 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=396268&action=review > LayoutTests/fast/css/is-specificity-3-expected.html:6 > +<div style="color: purple; background-color: blue;">Text</nottarget> Mixing div and nottarget tags? > LayoutTests/fast/css/matches-specificity-3-expected.html:6 > +<div style="color: purple; background-color: blue;">Text</nottarget> Ditto. > Source/WebCore/css/CSSSelector.cpp:95 > +static unsigned selectorSpecificity(const CSSSelector& firstSimpleSelector) Would be nice to have a typedef for "specificity" rather than using 'unsigned' everywhere.
Created attachment 396298 [details] patch
> Would be nice to have a typedef for "specificity" rather than using > 'unsigned' everywhere. Or even wrap it into a class.
Committed r260024: <https://trac.webkit.org/changeset/260024> All reviewed patches have been landed. Closing bug and clearing flags on attachment 396298 [details].
<rdar://problem/61724793>
Re-opened since this is blocked by bug 210480
Created attachment 396398 [details] patch Reduces scope a bit so compiled selectors still cache the specificity.
Committed r260069: <https://trac.webkit.org/changeset/260069> All reviewed patches have been landed. Closing bug and clearing flags on attachment 396398 [details].