On 7/11/13 11:21 PM, Tab Atkins Jr. wrote: > Both. More specifically, it's "anything that browser vendors have > complained about implementing for CSS due to it being > slow/expensive/whatever, but which are cool enough to still be worth > speccing for qSA/etc (and which may have already led a long life in JS > selector libraries)". OK. To the extent that these things are "slow" in different ways we may need different solutions for allowing them... > I'm handwaving in that paragraph, alluding to the more folk conception > of selectors and styling as involving the browser continually going > through all the selectors and matching them against the document. OK, no browser ever does it that way. I think we should avoid about thinking about it this way, because it will lead us astray in terms of how we design solutions, I suspect. > My thought for that was that, normally, the deferred styles are > excluded from matching anything during style recalc. When you call > the function, the browser runs the selectors of the deferred styles to > find the nodes matched by each, and then freezes that list - from then > on, those selectors are interpreted as matching exactly that list of > elements, no more and no less, regardless of what changes in the > document. Calling the function again refreshes this information, > changing what elements are considered to match each selector. I see. This is ... pretty weird behavior if those nodes move around in the DOM, right? -BorisReceived on Friday, 12 July 2013 03:45:46 UTC
This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:32 UTC