Re: [css-selectors] :contains()

On Thursday 19 April 2012, Sebastian Zartner wrote:
> > 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'.
I think that can be solved using already existing features of CSS selector, 
especially level 4.

p:contains('important'), p! *:contains('imporant')

This is what I meant. The only thing really missing right now to be able to 
match against the content of text-nodes. Only :empty does that right now.
(Technically you will also miss the opportunity to match 'word' in something 
like: <span>wo<em>rd</em></span>, but is that needed?)


Appropos :empty though. We end up with the same question in :contains. Should 
the match happen before or after text-transformations? After is not very 
feasible, but if matching happens before then white-space might not be what 
you expect it to be.

`Allan

Received on Friday, 20 April 2012 08:48:31 UTC