Re: Proposal for limited :matches pseudoclass

http://www.w3.org/TR/2001/CR-css3-selectors-20011113/#content-selectors

We already have a pseudo-class based on element's content and it's only based on the child elements.

It's quite stupid to think :matches cost more than :contains since :matches en :contains are both to be reevaluated when an element is added to the DOM from the element which have :matches/:contains. The difference is that some elements only are matched by the subselector of :matches while all elements (TextNodes too) must be evaluated for :contains.

    That can be verified by (the first is more complicated than the second one but both can be used in the next context) :
    div.postContent:contains(Source code:) > div.title::after { content: ' (code)'; }
    div.postContent:matches(code) > div.title::after { content: ' (code)'; }

    <div class="postContent">
        <div class="title">Title of the post</div>
        <div class="message">
            <p>
                qdfqeqjcljmfjdslkqmj klmjlqkfj mclkvjmlkqj
            </p>
            <p>
                Source code:<br/>
                <code>
                    // xxxx
                    .....
                </code>
            </p>
            <p>
                fdjmsl ljdmqlu djm jfmlkqj qklmu dmqkj
            </p>
        </div>
    </div>


We don't need to implements a partial :matches because a whole :matches is easily possible.
If a developer want to make a buggy selector, it don't need :matches to do it.

    :root > * * * *:hover * * * * *:contains(e) * * { color: red; }

In fact, the :matches pseudo-class can be "emulated" using :contains pseudo-class :

        a:matches(b) > c { ... }
    
    can be wrotten :

        a b::before {content:'[[X-CONTENT-B]]'; display: none; }
        a:contains([[X-CONTENT-B]]) > c { ... }

    but it's less more optimised...

Fremy
  From: Tab Atkins Jr. 
  Sent: Thursday, July 31, 2008 1:45 AM
  To: www-style list 
  Subject: Proposal for limited :matches pseudoclass


  This is lifted from the :has-child proposal thread, since at least one person (Brad Kemper) liked the syntax, and at least one implementor (Boris Zbarsky) thought it wouldn't be horrible for implementations (at least, no more horrible than current child and sibling combinators).  Thought I'd give it a proper write-up, since I've had reason to want it in the last week.

  :matches pseudo-class

  The :matches(selector fragment) pseudo-class represents an element that has another specified element after it in the document tree.  The selector fragment starts with either the child combinator (>) or the adjacent-sibling combinator (+), optionally followed by whitespace, followed by a simple selector (see Selectors Level 3 for the definition of a simple selector).  This matches if an element matched by the simple selector occurs as a child (if > was used) or following adjacent sibling (if + was used) of the target element.  If the selector fragment is invalid or empty, the entire selector is invalid.

  Examples:
    td:matches(> input:checked) /* Matches any td with a checked input as a direct child */
    h1:matches(+ ul) /* Matches any h1 which is directly followed by a <ul> */
    p:matches(+ p) /* In a string of sibling <p>s, matches all but the last.  Contrast with "p+p", which matches all but the first. */

    tr:matches( input:checked) /* Invalid, as descendant combinator is not allowed */
    div:matches(> p > samp) /* Invalid, as combinator is not followed by a simple selector */

  Future extensions may relax the restrictions on the selector fragment, such as allowing it to take more combinators (such as the descendant or general sibling combinators) or allowing more than a simple selector in the selector fragment.

  ~TJ