Closed clarfonthey closed 5 years ago
yeah i've considered doing this. but the size gain would be small while the speed hit would be exponential and there would be perf landmines everywhere. a single *
, :not(.foo)
, div:nth-of-type(3)
and you're in for a bad time.
i'd like to see a convincing practical case on a realistic mid-size page where the wins outweigh the costs.
I feel like it'd be fairly easy to memoize the results and make it more efficient, although it'll still be way slower than if it weren't added. That said, I haven't looked to hard at the code and don't know how exactly that would be done.
I mostly put the issue here to see if there were decent use cases; maybe someone out there has a compelling example. :p
let's work through it on paper. the main idea is to ensure that a less qualified selector results in the same nodes as the full one. take #a .b > c.foo
. step one is to get a full set of nodes, let's call it Set0
. we then try to reduce the qualifiers right-to-left and test for equivalence to Set0
:
.foo
c
c.foo
.b > c
.b > c.foo
.b > .foo
...
...
#a b > .foo
#a c.foo
#a c
#a .foo
essentially it's a powerset of sub-selectors:
let sets = generatePowerSet([
"#a ",
".b >"
"c",
".foo",
]);
with the condition that at least c
or .foo
is part of the set, which probably means that ["c", ".foo"]
has to be a sub-powerset.
and this is just for a single selector. memoization (which dropcss uses extensively) won't really help you too much here. dropcss actually has all the internal functions needed: a selector parser, an html parser, and a matcher that can test a parsed selector against the parsed html. if you are interested in prototyping this and doing the memoization externally, i can expose each of these functions and it would simply be a matter of mutating the parsed selector array to test each case. this would also go a long way towards what's needed for #32.
i'm actually not sure this is going to work out even if all the above is done. the reason is that selector specificity matters. even if you can match the same set of elements in isolation, the order of your rules may prevent the same application of styles, and figuring out how to avoid this is simply not feasible without basically writing a spec-compliant CSS engine.
an easy example of this is removing li
from li.foo
in [1]. in isolation it would still only match a single element, but would fail to apply the styling.
Simple example:
In this case, dropcss should notice that:
p
arebody p
.body p
, all of the selectors onbody p
are either less specific thanp
or more specific thanbody p
.Therefore, it should just output:
One potentially more applicable case of this might be styles which differentiate
ul li
andol li
on a page which only usesul li
. In this case, we could drop theul
and just outputli
to shrink the size of the CSS. This could also apply to, for example,.page-type .element
, where only one variant of.page-type
is used in the HTML samples given.