- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 26 Apr 2012 03:11:24 -0400
- To: www-style@w3.org
On 4/26/12 2:31 AM, Sebastian Zartner wrote: > As I understood the subject marker this is incorrect. You would only have to style the<ol> in dependency of having exactly one<li> in it. The<li> (or any other descendents) wouldn't be affected. Sure they would, because some styles inherit. So changing 'color' on the <ol>, say, might change it on all descendants. Or might not, depending on their styles. > But what's the difference to 'OL LI:only-child' here? There you also have to walk up the ancestor chain looking for<ol>s. The only difference is that you style the<ol> and not the<li>. Yes, that's the difference. When something changes about the <li>, right now you know you don't need to restyle any ancestors of the <li> (modulo :empty), so you can constrain your search for the set of things that need to be restyled. With subject markers, the set of things that might need to be restyled for a change is much bigger (and in fact is the whole document, generally). >> And with some of the other proposals people want to combine this with, >> you could end up restyling arbitrary other nodes in the DOM that are >> far away from the 'OL'. > Do you have examples for these other proposals? They basically come down to things that allow you to select some arbitrary descendant of an arbitrary ancestor of some node that matches a given selector. In other words, any change to any node might affect styles anywhere in the document. > Of course finding out which selectors start and which stop matching is not a trivial task, but it can be optimized in most cases. Yes, I'm obviously well aware. The point is that even _after_ optimizing it's not that fast. > In the example above the style stops matching as soon as another child element is inserted or all child elements are removed. Based on this information triggers can be written that execute at these events and restyle the elements they are applied to. If these elements are the ones you matched against or any others of the selector shouldn't be a difference then. I suggest you think through the set of special-cases like this needed to deal with all the selectors in CSS. Then think about how long it'll take to check for each of the special cases on each mutation.... >> Again, the subject marker may well be worth it. Just please don't >> pretend it doesn't cost anything performance-wise: it makes every >> single mutation somewhat slower. > When you think this is going to be slow in many cases, then it might help if you gave examples. Examples of what? Again, the biggest cause of slowdown is restyling a large part of the DOM on some mutation. The second-biggest cause is spending too long figuring out that you don't need to restyle things. Any selector which makes the former more likely and the latter harder means performance problems unless a great deal of effort is spent on mitigating them. > This sounds like we agree on allowing the subject marker and :contains() within querySelector(). I think it would be fine there, yes. It might be find in dynamic contexts too; it's just that no one has figured out how to make it work well. If you have a selectors implementation that deals with the problem that you're willing to share, I'm sure people would be very interested! -Boris
Received on Thursday, 26 April 2012 07:11:58 UTC