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

On Tue, Nov 25, 2014 at 2:53 PM, François REMY
<francois.remy.dev@outlook.com> wrote:
> ± > 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*
>           ;

Ah yes, that's right, `a::before` and `a ::before` are different, and
it would be much messier to make that work with the "infer a *" rules.
:/

On Tue, Nov 25, 2014 at 2:28 PM, François REMY
<francois.remy.dev@outlook.com> wrote:
> That being said, you can't put combinators in :matches, too; the only thing is that we have a "match-all" selector for elements we can combine with :matches. We can't provide a "match-all" for pseudo-elements because they're not author-controlled. But, instead, we could possibly add a new ::matches definition as a parameterized pseudo-element selector segment. What do you think of ::matches(after,before)?

This is a decent idea.  On further thought, we don't actually want to
allow `foo :: *` (selecting all pseudo-elements), as it would prevent
us from easily adding new pseudo-elements in the future, and would be
a footgun in general.  (Targeting both ::before and ::first-line is
probably never intended.)  In other words, though :: is a combinator,
you really do want to always target a pseudo-element of a given name.
In that case, your idea of having an explicit form for "multiple
pseudo-elements" is pretty decent.

Benjamin, what do you think of this?

~TJ

Received on Wednesday, 26 November 2014 01:07:17 UTC