RE: [selectors] Assistance requested in figuring out the data model of pseudo-elements

± > I am confused with this last paragraph. Aren't all combinators already
± > allowed in :matches()?
± >
± > The definition says the argument is simply a selector list. WebKit
± > allows any combinator in :matches(). Using combinators in :matches()
± > is super useful, we already use that a lot.
± 
± Yes, but the subject of the matches is the last thing in each complex selector;
± in `a:matches(b > .foo)`, the ".foo" element has to be the same as the "a"
± element; the "b" element is an ancestor.  In `a:matches(::before)`, though,
± that's not the intent - the ::before is
± *not* the same as the "a" element, it's a sub-element(ish).
± 
± This is why I'm talking about making :: actually a combinator, into the pseudo-
± tree.  Then you can switch the match set to be the pseudo-elements of an
± element, before trying to match :matches() against it.

FWIW, this proposal was rejected last time because all combinator can be padded with whitespace, and so "::" would be a very special combinator. That being said, let's be honest, that's what it actually is. It would make sense to reconsider. [1]

 combinator
   /* combinators can be surrounded by whitespace */
   : S+ | S* [ '>' | '+' | '~' | COLUMN | '/' IDENT '/' ] S*
   ;

(CSS Syntax L4)

_____________________________
[1] I could not find the very specific mail about the resolution, but it is maybe close to this one: http://lists.w3.org/Archives/Public/www-style/2013Nov/0358.html

Received on Tuesday, 25 November 2014 22:54:03 UTC