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

On 11/25/14, 5:06 PM, Tab Atkins Jr. wrote:
> 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?
For me, one of the best property of :matches() is its use for 
composition or selectors.

Today, you can take any selector list, put it inside a :matches(), 
"augment it", and everything works as developers expect. I believe this 
to be a great property and I have received very positive feedback so far.

On the other hand, I need to look a bit more into some issues raised on 
this thread, in particular applying filters on pseudo elements. Some 
cases are not clear to me yet, for example:
     ::first-line:blank
     ::before:blank { content: "non-blank"; }
     etc

Some cases would force a lot of complexity on the engine, for example:
     ::first-letter:hover { ... }

Overall I also fail to see what is the problem with defining :matches() 
as a generator of a disjunction. That would mean :matches() itself has 
no intrinsic properties, which seem like a useful definition.

Benjamin

Received on Wednesday, 26 November 2014 02:05:03 UTC