Re: Proposal for limited :matches pseudoclass

François REMY wrote:
> From: "Eduard Pascual" <herenvardo@gmail.com>
>> It appears to me (please, someone correct me if I am wrong) that the
>> main concern applies to page-loading, rather than arbitrary
>> modifications from script

The concerns apply to some of both, actually.  UAs currently make 
various attempts to optimize behavior in the face of post-load DOM 
modifications too (possibly with fallback to "just give up and recompute 
it all" in some cases).

 >> so something like a full :matches wouldn't
>> really hurt: scripts can anyway tweak the class or id of the root
>> element.

While true, right now toggling the class on some non-root node is a lot 
faster than toggling it on the root.  The simplest general :matches() 
implementation would make any DOM mutation (any attribute change, node 
insertion, node removal, etc) just as costly as changing the class of 
the root.  There are some obvious optimizations there (e.g. checking for 
attributes that are actually selected on), but DOM modification in 
general will get slower, or there will be a good bit of complexity, with 
a general :matches.

Now maybe the complexity is worth it, of course.  But in practice 
complexity means you pay either performance or memory or both; that will 
be the real cost from the point of view of web pages.

>> Actually, if authors try to rely on javascript emulation of
>> the :matches capability, the impact is even greater

While true, it only affects the authors who want to be affected.  Of 
course one could have optimizations based on whether anything on the 
page uses :matches...  But then adding a single CSS selector will 
inexplicably degrade your DOM performance.  You get that somewhat now 
with :nth-of-type and company, but only in the affected subtrees.

>> - If the blocks containing ":matches" on their selectors were ignored
>> during initial page loading, would the concerns still be there?

Yes.

>> - Would it be actually doable to skip such blocks during the initial
>> loading, and "review" them once the page has been loaded?

Possibly, but that doesn't seem very desirable (esp. given the number of 
pages out there that never finish loading).

> My thought is that the ‘normal way’ can be as fast as the 
> ‘reversed way’, and can be simpler to implements.

I welcome actual data to this effect.  I'd even welcome a theoretical 
argument past "that's my gut feeling".  I believe such theoretical 
arguments against this claim were already presented, but if not I'm 
happy to do so.  Can't present data, since that would involve actually 
having a "normal" (in your terminology) matching implementation.

> Complaining about speed problems is a 
> false argument since editing the class of the root element also can 
> change the whole DOM.

But in this case the web page authors _expects_ it to.  The problem is 
slowness that the web page author doesn't want.  If he's just having a 
little ticker off in the corner, he doesn't expect each tick to cost the 
same as rebuilding the entire presentation.  Nor should it.

-Boris

Received on Tuesday, 20 January 2009 17:27:29 UTC