- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 10 Jun 2016 11:53:55 -0700
- To: Mark Brown <mark@mercurylang.org>
- Cc: W3C www-style mailing list <www-style@w3.org>
On Fri, Jun 10, 2016 at 2:53 AM, Mark Brown <mark@mercurylang.org> wrote: > On Fri, Jun 10, 2016 at 6:58 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >> On Thu, Jun 9, 2016 at 3:34 AM, Daniel Glazman <daniel.glazman@disruptive-innovations.com> wrote: >>> My recommendation for @else is then the following: yes to @else but >>> we need to have boolean completion in MQs first, to be able to >>> serialize precisely the MQ relevant to a given style rule. That means >>> allowing negated single media features, OR operations and grouping >>> through parentheses. I'm pretty sure we'll have requests for that (if >>> we don't have them yet) anyway. >> >> We already have all of those. > > Well, not quite. Florian's example on the issue tracker [1] > illustrates that you can't always write a separate condition that's > equivalent to an else, because of how unknown media features are > handled. > > To make the set of operations complete, you could, for example, add a > function such as 'unknown(media-query)' which is true iff its argument > evaluates to unknown. So this doesn't seem a major hurdle. I'm not sure that's what Daniel was referring to; his email *seemed* to be just about NOT/AND/OR, which does indeed exist already for @media and @supports. I haven't seen a use-case yet for needing to explicitly test for unknown values, except "emulate what @else can do". If we can come up with one we can always add such a function. ~TJ
Received on Friday, 10 June 2016 18:54:42 UTC