W3C home > Mailing lists > Public > www-style@w3.org > June 2016

Re: @else in Media Queries

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 10 Jun 2016 13:12:12 -0700
Message-ID: <CAAWBYDBza-xRg+5QfksTJM0c44U5bp62Q1e5EPU8_xwVGJJ_Lw@mail.gmail.com>
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Cc: www-style list <www-style@w3.org>
On Fri, Jun 10, 2016 at 12:45 PM, Daniel Glazman
<daniel.glazman@disruptive-innovations.com> wrote:
> On 10/06/2016 20:53, Tab Atkins Jr. wrote:
>> 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.
> Visibly, there's a need for a summary:

I think you're just summarizing some pros/cons for the proposal as a
whole here, and not actually responding to the quoted text directly,

> pros: - simple to read and understand
>       - feature needed by users
> cons: - new constraints needed on rule insertion
>       - new constraints needed on rule deletion

What new constraints are needed?  Are you talking about just in
editors?  The OM doesn't need to do anything special; it can handle
stray @else just fine.

>       - @else standalone after deletion of @media is meaningless

Why is this a con?  Plenty of things in CSS are meaningless without
support of other things.  "flex: 1" does nothing on an element that's
not a child of a "display: flex", for example.  This is a direct
physical connection between the @else rule and the thing it needs to
be meaningful, which is a lot easier to handle than most of CSS's very
indirect connections.

>       - complexifies automated media queries management

What is "automated MQ management"?

>       - can't always express the @else case by a MQ

Why is this a con?

>       - issues with copy/paste in wysiwyg environments

What is the issue?

Received on Friday, 10 June 2016 20:12:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:03 UTC