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

On Wed, Nov 26, 2014 at 10:11 AM, François REMY
<francois.remy.dev@outlook.com> wrote:
> ± On Wed, Nov 26, 2014 at 9:56 AM, François REMY
> ± <francois.remy.dev@outlook.com> wrote:
> ± > ± A "generator of a disjunction" makes :matches() a special syntax
> ± > form, not a ± real pseudo-class.  That would be somewhat easier, but
> ± > it would also be ± weird.  Dunno if I wanna go down that road.
> ± >
> ± > Also, it's not a disjunction. If it was, the following two would be equivalent:
> ± >
> ± >         a:matches(.b c, .d e)
> ± >         a.b c, a.d e
> ± >
> ± > If I understood the situation correctly, they are not.
> ±
> ± No, it's more complicated than that.  Let's rephrase in explicit AND/OR terms,
> ± to make it clear how it's in DNF:
> ±
> ± (a AND .b c) OR (a AND .d e)
> ±
> ± It's a disjunction of conjunctions.
>
> If we extend to pseudo-elements, this won't stay accurate;
> ==> [a]:matches([b], ::before)
> ==> ([a] AND [b]) OR ([a] AND ::before)

Kinda sort, depends on how you want to interpret things.  The AND
operator doesn't map directly to existing syntax in CSS, so you have
to be creative; you can interpret a pseudo-element in a clause as
matching *and* transferring the matched element to the pseudo-element
instead.  It's a nasty hack of the data model, though.

> Which is why I argue we probably shouldn't allow that.

Right.

~TJ

Received on Wednesday, 26 November 2014 18:35:09 UTC