Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parent dropping (hard optimisation) #36

Closed
clarfonthey opened this issue Jul 17, 2019 · 4 comments
Closed

Parent dropping (hard optimisation) #36

clarfonthey opened this issue Jul 17, 2019 · 4 comments
Labels
enhancement New feature or request

Comments

@clarfonthey
Copy link

Simple example:

<!DOCTYPE html>
<body>
<p>Hello, world!
</body>
body p { margin: 1em; }

In this case, dropcss should notice that:

  1. All p are body p.
  2. Besides body p, all of the selectors on body p are either less specific than p or more specific than body p.

Therefore, it should just output:

p { margin: 1em; }

One potentially more applicable case of this might be styles which differentiate ul li and ol li on a page which only uses ul li. In this case, we could drop the ul and just output li 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.

@leeoniya
Copy link
Owner

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.

@clarfonthey
Copy link
Author

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

@leeoniya
Copy link
Owner

leeoniya commented Jul 18, 2019

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:

https://stackoverflow.com/questions/42773836/how-to-find-all-subsets-of-a-set-in-javascript/42774138#42774138

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.

@leeoniya leeoniya added the enhancement New feature or request label Jul 22, 2019
@leeoniya
Copy link
Owner

leeoniya commented Jul 22, 2019

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.

[1] https://codepen.io/anon/pen/zgverp

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants