- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 26 Nov 2014 10:34:21 -0800
- To: François REMY <francois.remy.dev@outlook.com>
- Cc: Benjamin Poulain <benjamin@webkit.org>, www-style list <www-style@w3.org>
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