W3C home > Mailing lists > Public > www-style@w3.org > April 2007

Re: Select a parrent node with s CSS selector?

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 25 Apr 2007 10:10:40 -0400
Message-ID: <462F6160.1000200@inkedblade.net>
To: www-style@w3.org

Boris Zbarsky wrote:
> 
> Steven Pemberton wrote:
>> Are you sure about this? CSS is currently designed so that you can 
>> decide when you are at an element which styles apply, and presumably 
>> implementations use that knowledge.
> 
> Yes.  Furthermore, the style of a node only depends on its ancestors.  
> So when something about a node changes, you only need to recompute style 
> on its descendants.
> 
>> since the selector ">" and the proposed "<" are symmetrical, I would 
>> expect at worst only a linear increase in complexity. It would just 
>> need a different algorithm.
> 
> For computing style on a single node, yes.  But for deciding what nodes 
> to restyle when something about a node changes, the presence of both "<" 
> and ">" means having to restyle the entire document tree (modulo 
> memory-consuming optimizations).
> 
> Again, the performance issues with all the "parent" proposals are not in 
> computing style for a single node.  They're in handling DOM mutations.  
> Which happen a good bit out there.

The way I'd implement it is given the selector
   $A > B
that selects A the parent of B, have the style algorithm try matching
as if it were
   A > B
and when it matches B, instead of computing style on B, tell A it
needs to recompute its style with the addition of this rule.

I'm not saying it's easy to do it this way, but it would avoid the
algorithmic complexity problems of trying to match that rule against
A directly. The hard part would be deletions rather than insertions.
Doing that fast would involve some caching. But, I'd say it's possible.

~fantasai
Received on Wednesday, 25 April 2007 14:10:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:50 GMT