Re: Proposal: parent selectors

On 1/21/10 11:36 AM, Eduard Pascual wrote:
> Fact #1: whatever that can be achieved through jQuery, could be done
> faster through a native implementation within the UA.

Agreed.

But people aren't asking for a jquery-equivalent feature (that is, one 
where you would perform the selector-match once and be done).  They're 
asking for a feature where one has to constantly track which nodes match 
the selector in the face of DOM mutations.  That's something jquery does 
NOT do last I checked.

> Question: if :has() (or any equivalent feature regardless of syntax)
> was implemented, would it need to take profit of progressive
> rendering?
> Answer, Fact #2: No.
> Proof: Those authors who really need :has()'s functionality rely on
> jQuery, so they don't get progressive rendering. It's a trade-off, and
> the volume of web authors relying on jQuery are a proof that it's a
> good deal on many cases. Even for newbie authors who don't understand
> the efficiency costs of this feature, if they have a minimum idea of
> what they are doing they'll test their pages on at least one browser,
> so they'll get an idea on how fast or slow they load.

It's not just progressive rendering.  DOM mutations happen after the 
document has loaded.  On some sites, every 10ms, forever.  On other 
sites, thousands or tens of thousands at once.

> Based on the above, here it goes:
> Suggestion for UA vendors: implement some version of this feature
> experimentally (maybe a limited version, such as the "child" and/or
> "next-sibling" versions that have been discussed previously), with
> vendor prefixes or whatever, that defers processing of rules using
> this feature until the rest of the document has been loaded.

So process them once at DOMContentLoaded and then never process them 
again?  If the DOM changes, ignore any effect that might have on :has() 
matching?  Is that the proposal?

-Boris

Received on Thursday, 21 January 2010 16:49:06 UTC