Re: Proposal for limited :matches pseudoclass

Eduard Pascual wrote:
> I'm confused now. Let's put some example: given a markup like this:
> <ROOT>
> <A><whatever>...</whatever></A>
> <B><C>...</C></B>
> </ROOT>
> and a stylesheet with a single rule, whose selector is
> B:matches( C) { ... }

So this is matching elements which have a descendant matching C, yes?

> would changes within <whatever> be impacted by the presence of such selector?

It wouldn't, but if the selector looked like:

   A:matches(+ B:matches( C))

then they would.  The problem is detecting the difference between the 
two cases.  More precisely, the problem is to correctly, quickly, and 
with small memory use determine, for any DOM mutation and set of 
selectors, what parts of the tree (if any) need style reresolution.

Just to put this in perspective, the dead-simple and quite fast such 
determination that Gecko does right now is a noticeable fraction of the 
time DOM mutations take up (edging up towards 10% in some cases as we 
speed up other parts of the code).

So you end up with a tradeoff between the complexity and slowness of the 
code that determines what needs to be redone and the slowness of the 
actual redoing...

> In a more general approach, given a SOMETHING:matches(anythinghere)
> selector, would changes to the DOM *outside* of SOMETHING's subtree be
> impacted by the presence of the selector?

Yes, see above with A:matches(+ B).  If it were A:matches(~ B) then any 
change to any following sibling of A would mean A needs to be reresolved.

> That's exactly what I'm trying to figure out; but I need to see the
> implementor's side before I can reach any conclusion.

I think it's really hard to tell based on philosophical arguments, 
really.  At some point someone would need to sink the time in to try 
implementing this and see what the costs are....

> Of course, everything has a cost. It's just a matter of *how much*
> that cost is, and *how much* would we get for that cost.

Of course.

> Anyway, your "only affects the authors who want to be affected" has
> given me an idea (not sure how doable would it be, it just popped up
> from my brain's backgroundWorker): what about having some sort of
> "@allow-matches" at-rule?

That seems no different from just the use of the :matches selector from 
a UA point of view, and I don't see how it's different from the author's 
point of view either...

 > and if it's present
> authors know* what to expect (* on the part of the spec that defined
> such a rule, some warning like "Enabling the :matches pseudo-class
> with this rule may have a serious performance impact." would be
> appropriate).

We could stick that text on the :matches selector itself: "use of this 
selector can make everything slow."  That won't have any effect, since 
authors don't read the spec (and for the most part don't try to avoid 
slow things, as far as I can tell, with a very few exceptions).  It's 
users who end up paying the costs of the resulting performance problems, 
for the most part.

>> Possibly, but that doesn't seem very desirable (esp. given the number of
>> pages out there that never finish loading).
> Well, with the "yes" answer above, this question becomes pointless.
> However, you got me intrigued: pages that never finish loading? Is
> that even possible? If you are saying it, I guess it is possible, but
> I'm still surprised.

<html>
   <script>
     window.onload = function() {
       document.write("I never plan to document.close()");
     }
   </script>
</html>

The page generated by the implied document.open() never finishes 
loading.  This is not an uncommon pattern, actually.

-Boris

Received on Thursday, 22 January 2009 01:48:01 UTC