3 ms·

Very nice. But does it react dynamically when I update the DOM? One of the reason we do not have the subject selector or :has() yet is that it is very hard to

Very nice. But does it react dynamically when I update the DOM? One of the reason we do not have the subject selector or :has() yet is that it is very hard to implement efficiently for dynamic updates. In the general case with :has(), you have to check the whole document for every DOM change.

bkardell 14y ago
Yes, Simon, yes it does :) In certain cases you have to check the whole DOM, in others not. We make our best effort to not if we don't have to, or at least to only do it once from up high in the tree if DOM changes are hot and heavy. Is it efficient enough? So far it seems to be - but on a paradoxically hard page (like the HTML5 living standard, single page edition) with the wrong query, maybe not. But that's ok because a whole lot (far the majority I think) of Web pages should perform reasonably.
- SimonSapin 14y ago
  > but on a paradoxically hard page (like the HTML5 living standard, single page edition) with the wrong query, maybe not. Yeah, I use that page as a crash-test too :) Anyway, I haven’t dived in the source yet but I’m very interested in how this is implemented. How much can you hook into the browser’s selector engine / how much functionality do you have to duplicate? (I took over the cssselect project for WeasyPrint, but it is in Python without dynamic updates so the context is very different.)
  - hitchjs 14y ago
    We'll have to write up an article about how it works. I'm sure we'll be iterating on the source quite a lot now that we have a nice working set of things... Essentially though, we look at the modification to narrow down the potentially matching rules, then we use querySelectorAll/matchingfns at the appropriate spot in the tree. Each selector (like :-hitch-has) then has a filter function which merely returns true/false (just like jquery) and based on that we toggle an associated class on the element and the rest is just the browser's native CSS doing what it does.

bkardell 14y ago

Yes, Simon, yes it does :) In certain cases you have to check the whole DOM, in others not. We make our best effort to not if we don't have to, or at least to only do it once from up high in the tree if DOM changes are hot and heavy. Is it efficient enough? So far it seems to be - but on a paradoxically hard page (like the HTML5 living standard, single page edition) with the wrong query, maybe not. But that's ok because a whole lot (far the majority I think) of Web pages should perform reasonably.

SimonSapin 14y ago
> but on a paradoxically hard page (like the HTML5 living standard, single page edition) with the wrong query, maybe not. Yeah, I use that page as a crash-test too :) Anyway, I haven’t dived in the source yet but I’m very interested in how this is implemented. How much can you hook into the browser’s selector engine / how much functionality do you have to duplicate? (I took over the cssselect project for WeasyPrint, but it is in Python without dynamic updates so the context is very different.)
- hitchjs 14y ago
  We'll have to write up an article about how it works. I'm sure we'll be iterating on the source quite a lot now that we have a nice working set of things... Essentially though, we look at the modification to narrow down the potentially matching rules, then we use querySelectorAll/matchingfns at the appropriate spot in the tree. Each selector (like :-hitch-has) then has a filter function which merely returns true/false (just like jquery) and based on that we toggle an associated class on the element and the rest is just the browser's native CSS doing what it does.