Re: @else in Media Queries

On Fri, Jun 10, 2016 at 12:45 PM, Daniel Glazman
<[email protected]> 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,
right?

> 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?

~TJ