Re: [css-selectors] :contains()

> I see a few things that needs to be clarified and could potentially make 
> :contains() work better. Back when I did the CSS3 selectors for KHTML (I
> still believe the one of the only implementations of :contains()). I made 
> it match against innerText. Today I am starting to think that if 
> reintroduced :contains perhaps should only match on direct text node 
> children of the element. 
> 
> Currently text nodes are one of the only parts of the DOM not matchable 
> by CSS selectors, but there is no reason to make :contains 
> computationally expensive by allowing it to match innerText. If it only 
> matched direct text-nodes it would still be useful for the listed 
> examples but much faster.
I assume you mean the 'textContent' property.
This would be a speed boost in many cases, though you would also lose functionality. E.g. imagine something like this:

<p>This is an <strong>important</strong> sentence.</p>

Then you wouldn't have the possibility to style the paragraph by searching for the word 'important'.
Also I imagine that in cases were you just have a single text node like the e.g. the red numbers example (td:contains("-")), there wouldn't be any difference in performance.
Anyway, maybe there could be two different syntaxes for covering both to allow performance enhancements.

> Making it regular expression based on top of that would make it even 
> more useful. In fact without regular expression it is still quite 
> limited in usefulnes.
That's why I mentioned it. There will be cases, in which you need to do more than a simple substring check. E.g. somebody might want to highlight a table row depending on whether it contains an email address.
Though this feature might raise further security issues besides costing more time to evaluate.

Sebastian
-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

Received on Thursday, 19 April 2012 11:08:25 UTC