@else in Media Queries

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
52 messages Options
123
Reply | Threaded
Open this post in threaded view
|

@else in Media Queries

Daniel Glazman
I'd like to explain a bit more here why I think the proposed @else
statements for Media Queries are for the time being overkill, despite
of the good they can provide.

First, it was said yesterday during CSS WG confcall that to find the
Media Query "applying" to a @else statement, you only need to look at
the enclosing @media rule. That's false. You need to look at the
enclosing rule but you also need to look at all the @import ancestors
and even the stylesheet ancestors because the ownerNode can specify
a Media Query. Example:


  <style media="screen and (max-width: 500px)">
    @media screen and (min-width: 200px) {
      p { color: red }
    }
  </style>

is, from an editor's or web author's point of view, really a:

  @media screen and (min-width: 200px) and (max-width: 500px) {
    p { color: red }
  }

So to find the real media query's context relevant to a given style
rule, you need to climb up the CSS OM tree up to the html ownerNode and
do quite a lot of operations (please note MQs are not decomposed by
the CSS OM that deals only with one string value containing the whole
MQ; something on Houdini's radar...). And I'm not even mentioning the
case where the MQ is a group of media, ahem.
Such an operation is already quite expensive, whether it's done
automatically or manually. It's error prone, complicated and painful.

If @else if added, it adds another major layer of complexity:
we can only negate a whole MQ right now and not a single component
inside a MQ so expressing the "compound" MQ relevant to an arbitrary
style rule could be very painful is not impossible. In short it means
that copy/paste of a given element with its stylistic information
between two different documents could lead to MQ of that form:

  @media ...a media query... {
    /* nothing here */
    @else {
      p { color: red }
    )
  }

Sorry, but that's ugly and that clearly sucks. From a UI perspective,
wow.

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.

I did a little survey of all existing wysiwyg editors dealing with MQs,
whether the pivot format is html or not (i.e. tools exporting to html
but having their own proprietary format). None of them is able to deal
with arbitrary Media Queries given their complexity. Adding @else right
now with only a limited set of boolean operations on MQs will most
certainly be a huge burden - up to a blocker - on visual editors.

</Daniel>

Reply | Threaded
Open this post in threaded view
|

Re: @else in Media Queries

Tab Atkins Jr.
On Thu, Jun 9, 2016 at 3:34 AM, Daniel Glazman
<[hidden email]> wrote:

> I'd like to explain a bit more here why I think the proposed @else
> statements for Media Queries are for the time being overkill, despite
> of the good they can provide.
>
> First, it was said yesterday during CSS WG confcall that to find the
> Media Query "applying" to a @else statement, you only need to look at
> the enclosing @media rule. That's false. You need to look at the
> enclosing rule but you also need to look at all the @import ancestors
> and even the stylesheet ancestors because the ownerNode can specify
> a Media Query. Example:
>
>
>   <style media="screen and (max-width: 500px)">
>     @media screen and (min-width: 200px) {
>       p { color: red }
>     }
>   </style>
>
> is, from an editor's or web author's point of view, really a:
>
>   @media screen and (min-width: 200px) and (max-width: 500px) {
>     p { color: red }
>   }
>
> So to find the real media query's context relevant to a given style
> rule, you need to climb up the CSS OM tree up to the html ownerNode and
> do quite a lot of operations (please note MQs are not decomposed by
> the CSS OM that deals only with one string value containing the whole
> MQ; something on Houdini's radar...). And I'm not even mentioning the
> case where the MQ is a group of media, ahem.
> Such an operation is already quite expensive, whether it's done
> automatically or manually. It's error prone, complicated and painful.

I'm not sure what you're trying to say here.  As the spec lays out
clearly in both definition and examples, @else is relative to the
*preceding* conditional rule, not an *enclosing* one.  Any enclosing
conditional is irrelevant here.

> If @else if added, it adds another major layer of complexity:
> we can only negate a whole MQ right now and not a single component
> inside a MQ so expressing the "compound" MQ relevant to an arbitrary
> style rule could be very painful is not impossible. In short it means
> that copy/paste of a given element with its stylistic information
> between two different documents could lead to MQ of that form:
>
>   @media ...a media query... {
>     /* nothing here */
>     @else {
>       p { color: red }
>     )
>   }
>
> Sorry, but that's ugly and that clearly sucks. From a UI perspective,
> wow.

I don't know what you're trying to say here. Can you flesh out the
example with more detail?

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

> I did a little survey of all existing wysiwyg editors dealing with MQs,
> whether the pivot format is html or not (i.e. tools exporting to html
> but having their own proprietary format). None of them is able to deal
> with arbitrary Media Queries given their complexity. Adding @else right
> now with only a limited set of boolean operations on MQs will most
> certainly be a huge burden - up to a blocker - on visual editors.

It sounds like @media itself is a blocker on those editors for some
reason.  @else doesn't seem to make the situation any worse.

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: @else in Media Queries

Daniel Glazman
On 09/06/2016 22:58, Tab Atkins Jr. wrote:

> I'm not sure what you're trying to say here.  As the spec lays out
> clearly in both definition and examples, @else is relative to the
> *preceding* conditional rule, not an *enclosing* one.  Any enclosing
> conditional is irrelevant here.

The whole things starts smelling like the worst of hacks in CSS. So an
editor removing one rule (the @media one) will have to carefully look
if there is an @else after it. To do what? Remove it? Explode it?
Keep it standalone (what does it even mean in that case...)?

> It sounds like @media itself is a blocker on those editors for some
> reason.  @else doesn't seem to make the situation any worse.

When was the last time you implemented a Wysiwyg editor dealing with
media queries and why don't you listen? Can you please for once accept
what others are saying when you have no knowledge of that domain?

</Daniel>


Reply | Threaded
Open this post in threaded view
|

Re: @else in Media Queries

Daniel Glazman
In reply to this post by Tab Atkins Jr.
Forgot to say one thing: it also implies new constraints on rule
insertion since you obviously can't insert let's say a style
rule between an @media and its @else. Oh, wait but you could
insert another @media rule :-) Urgh.

I really dislike this now. Far too hacky.

</Daniel>

Reply | Threaded
Open this post in threaded view
|

Re: @else in Media Queries

Mark Brown
In reply to this post by Tab Atkins Jr.
On Fri, Jun 10, 2016 at 6:58 AM, Tab Atkins Jr. <[hidden email]> wrote:
> On Thu, Jun 9, 2016 at 3:34 AM, Daniel Glazman <[hidden email]> 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.

On Fri, Jun 10, 2016 at 3:34 PM, Daniel Glazman
<[hidden email]> wrote:
> The whole things starts smelling like the worst of hacks in CSS. So an
> editor removing one rule (the @media one) will have to carefully look
> if there is an @else after it. To do what? Remove it? Explode it?

Can you explain how this is different from an editor for any other
language with an if-then-else construct?

Mark

[1] https://github.com/w3c/csswg-drafts/issues/112

Reply | Threaded
Open this post in threaded view
|

Re: @else in Media Queries

Daniel Glazman
On 10/06/2016 11:53, Mark Brown wrote:

> Can you explain how this is different from an editor for any other
> language with an if-then-else construct?

If we compare this to code, then my software generates code. Do you
use a code generator or do you write your own code?

</Daniel>


Reply | Threaded
Open this post in threaded view
|

Re: @else in Media Queries

Mark Brown
On Fri, Jun 10, 2016 at 9:21 PM, Daniel Glazman
<[hidden email]> wrote:
> On 10/06/2016 11:53, Mark Brown wrote:
>
>> Can you explain how this is different from an editor for any other
>> language with an if-then-else construct?
>
> If we compare this to code, then my software generates code. Do you
> use a code generator or do you write your own code?

You can assume that I don't know a lot about Wysiwyg editors; that's
why I was asking. I can understand your objection to the semantics -
your point about needing a "boolean completion" is valid (and thank
you for taking the time to make your point, btw) - but I don't
understand the problem with splitting up a chained conditional.

Mark

Reply | Threaded
Open this post in threaded view
|

Re: @else in Media Queries

Daniel Glazman
On 10/06/2016 14:23, Mark Brown wrote:

> You can assume that I don't know a lot about Wysiwyg editors; that's
> why I was asking. I can understand your objection to the semantics -
> your point about needing a "boolean completion" is valid (and thank
> you for taking the time to make your point, btw) - but I don't
> understand the problem with splitting up a chained conditional.

For the time being, any deletion in a stylesheet always results
in a valid stylesheet. But if we have the following:

  @media .... {
     ...
  }
  @else {
     ...
  }

and if you remove the @media part, you end up with an invalid statement
(the standalone @else). All existing code, everywhere on the Web,
performing deletions in a stylesheet will need to be updated to care
for that.

Similarly, insertions in a stylesheet will have to do some validation
to avoid breaking @media+@else.

Hth.

</Daniel>

Reply | Threaded
Open this post in threaded view
|

Re: @else in Media Queries

Marat Tanalin | tanalin.com
10.06.2016, 17:30, "Daniel Glazman" <[hidden email]>:
> For the time being, any deletion in a stylesheet always results
> in a valid stylesheet.

An arbitrary deletion (e.g. removing an opening brace while keeping the corresponding closing one) could make a stylesheet invalid.

> But if we have the following:
>
>   @media .... {
>      ...
>   }
>   @else {
>      ...
>   }
>
> and if you remove the @media part, you end up with an invalid statement
> (the standalone @else).

That's perfectly OK on its own.

> All existing code, everywhere on the Web,
> performing deletions in a stylesheet will need to be updated to care
> for that.

Supporting any new syntax-wise feature naturally involves changes in software. I'm not sure about the point of software intended just to perform arbitrary unaware deletions.

Reply | Threaded
Open this post in threaded view
|

Re: @else in Media Queries

Daniel Glazman
On 10/06/2016 18:22, Marat Tanalin wrote:
> 10.06.2016, 17:30, "Daniel Glazman" <[hidden email]>:
>> For the time being, any deletion in a stylesheet always results
>> in a valid stylesheet.
>
> An arbitrary deletion (e.g. removing an opening brace while keeping the corresponding closing one) could make a stylesheet invalid.

You can't do that from the OM.

</Daniel>


Reply | Threaded
Open this post in threaded view
|

Re: @else in Media Queries

Mark Brown
In reply to this post by Daniel Glazman
(Fwiw, my stake in this is as a UA dev keen to offer this feature to users.)

On Thu, Jun 9, 2016 at 8:34 PM, Daniel Glazman
<[hidden email]> wrote:
> So to find the real media query's context relevant to a given style
> rule, you need to climb up the CSS OM tree up to the html ownerNode and
> do quite a lot of operations (please note MQs are not decomposed by
> the CSS OM that deals only with one string value containing the whole
> MQ; something on Houdini's radar...). And I'm not even mentioning the
> case where the MQ is a group of media, ahem.
> Such an operation is already quite expensive, whether it's done
> automatically or manually. It's error prone, complicated and painful.

I see what you mean now. If they were all of the form
<media-condition> you could just concatenate the ancestors' strings
like "(A1) and (A2) and (A3) and ...", but that doesn't work for
<media-query-list> in general.

> If @else if added, it adds another major layer of complexity:
> we can only negate a whole MQ right now and not a single component
> inside a MQ so expressing the "compound" MQ relevant to an arbitrary
> style rule could be very painful is not impossible.

The proposed new rules use a form of syntax like <media-condition>, so
you can build the required string by concatenating the earlier
conditions in the chain like "(not (C1)) and (not (C2)) and (not (C3))
...", this time negating them before conjoining. You still need to add
the ancestors as above, but dealing with the siblings is at least much
easier. I don't agree that it adds another major layer of complexity.

On Fri, Jun 10, 2016 at 7:53 PM, Mark Brown <[hidden email]> wrote:
> you can't always write a separate condition that's
> equivalent to an else, because of how unknown media features are
> handled.

Sorry, I take that back. The spec says these ones are boolean, not three-valued.

Mark

Reply | Threaded
Open this post in threaded view
|

Re: @else in Media Queries

Tab Atkins Jr.
In reply to this post by Daniel Glazman
On Thu, Jun 9, 2016 at 10:34 PM, Daniel Glazman
<[hidden email]> wrote:

> On 09/06/2016 22:58, Tab Atkins Jr. wrote:
>> I'm not sure what you're trying to say here.  As the spec lays out
>> clearly in both definition and examples, @else is relative to the
>> *preceding* conditional rule, not an *enclosing* one.  Any enclosing
>> conditional is irrelevant here.
>
> The whole things starts smelling like the worst of hacks in CSS. So an
> editor removing one rule (the @media one) will have to carefully look
> if there is an @else after it. To do what? Remove it? Explode it?
> Keep it standalone (what does it even mean in that case...)?

This is literally how *every single programming language* works
(pedants pointing out esolangs, plz go away).  If you have an if-else
chain, and you remove the leading if block, you have to modify the
prelude to the next else-if to be just an if.

(Possible misunderstanding here - do you think an @else *arbitrarily
far down the page* will chain into the opening conditional?  If so,
that's wrong - they have be *immediately* following, with nothing
separating the two rules but whitespace and comments.)

In this case, that just means turning the @else into @when.  Or, if
it's the last @else and has no condition on it, just remove the
wrapping rule entirely.

>> It sounds like @media itself is a blocker on those editors for some
>> reason.  @else doesn't seem to make the situation any worse.
>
> When was the last time you implemented a Wysiwyg editor dealing with
> media queries and why don't you listen? Can you please for once accept
> what others are saying when you have no knowledge of that domain?

This tone is unnecessary.

You stated clearly that your survey of existing editors shows that
they can't even handle existing @media rules.  I don't know why this
is or what troubles they may be having, but @else is not a *new*
blocker here; at worst, it's stage 2 after they fix their existing
@media support.

If you could explain what the actual problem was, perhaps with
screenshots demonstrating why it's difficult in a WYSIWIG environment
specifically, I might be able to understand your point better.

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: @else in Media Queries

Tab Atkins Jr.
In reply to this post by Mark Brown
On Fri, Jun 10, 2016 at 2:53 AM, Mark Brown <[hidden email]> wrote:

> On Fri, Jun 10, 2016 at 6:58 AM, Tab Atkins Jr. <[hidden email]> wrote:
>> On Thu, Jun 9, 2016 at 3:34 AM, Daniel Glazman <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: @else in Media Queries

Daniel Glazman
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:

pros: - simple to read and understand
      - feature needed by users

cons: - new constraints needed on rule insertion
      - new constraints needed on rule deletion
      - @else standalone after deletion of @media is meaningless
      - complexifies automated media queries management
      - can't always express the @else case by a MQ
      - issues with copy/paste in wysiwyg environments

</Daniel>




Reply | Threaded
Open this post in threaded view
|

Re: @else in Media Queries

Tab Atkins Jr.
On Fri, Jun 10, 2016 at 12:45 PM, Daniel Glazman
<[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: @else in Media Queries

Henrik Andersson
Tab Atkins Jr. skrev:
>>       - complexifies automated media queries management
> What is "automated MQ management"?
>
>
I hope it's javascript. Because I foresee trouble with the javascript
side of this. To be honest, I don't know how @at rules in general nor
media queries in particular are exposed in javascript, but I get a
feeling in my gut that this is going to be problematic.

Reply | Threaded
Open this post in threaded view
|

Re: @else in Media Queries

Tab Atkins Jr.
On Fri, Jun 10, 2016 at 2:16 PM, Henrik Andersson <[hidden email]> wrote:
> Tab Atkins Jr. skrev:
>>>       - complexifies automated media queries management
>> What is "automated MQ management"?
>
> I hope it's javascript. Because I foresee trouble with the javascript
> side of this. To be honest, I don't know how @at rules in general nor
> media queries in particular are exposed in javascript, but I get a
> feeling in my gut that this is going to be problematic.

I would suggest learning how they're handled before suggesting
additions will be problematic. ^_^

I haven't written the CSSOM side yet, but it'll just closely resemble
CSSMediaRule, possibly with the CSSElseRule interface having a
property that links backward to the preceding rule in the chain, for
convenience (thanks for the suggestion, zcorpan!).

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: @else in Media Queries

Daniel Glazman
In reply to this post by Tab Atkins Jr.
On 10/06/2016 22:12, Tab Atkins Jr. wrote:

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

Sure.

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

Two consecutive rules in a valid sheet's OM: a @media followed by a
@else. Through OM, @media is removed, stylesheet is now invalid because
a standalone @else...

>
>>       - @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.

But "flex: 1" on an element that does not have "display: flex" does NOT
make the sheet invalid ; a standalone @else does.

>>       - complexifies automated media queries management
>
> What is "automated MQ management"?

Given an arbitrary document with arbitrary stylesheets, where should
I insert a new MQ to see the style rules it contains have visual impact,
ie. be the ones that win the cascade? Even for handwritten CSS, this
is an enormous issue.

>>       - can't always express the @else case by a MQ
>
> Why is this a con?

Turn a standalone @else in a valid @media.

</Daniel>



Reply | Threaded
Open this post in threaded view
|

Re: @else in Media Queries

Florian Rivoal-4

> On Jun 11, 2016, at 15:34, Daniel Glazman <[hidden email]> wrote:
>
> On 10/06/2016 22:12, Tab Atkins Jr. wrote:
>
>> 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?
>
> Sure.
>
>>> 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.
>
> Two consecutive rules in a valid sheet's OM: a @media followed by a
> @else. Through OM, @media is removed, stylesheet is now invalid because
> a standalone @else...

I don't know why this is an issue. Valid or not, if the @else does nothing,
this is good. The correct way to delete an @media{}@else{} is to remove both.
The incorrect way, which leaves a dangling else, results in the same behavior.

It does not matter much to me that the resulting stylesheet is deemed invalid, but
if you think that's an issue, we can simply declare a dangling @else to be
a valid construct that does nothing.

I think what's more problematic is if you have
  @media (...) {...}
  @media (...) {...}
  @else {...}
and some code that's unaware of @else just deletes the second @media,
changing the semantics.


>>>      - @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.
>
> But "flex: 1" on an element that does not have "display: flex" does NOT
> make the sheet invalid ; a standalone @else does.

As I said, if validation is the issue, we can define dangling @else to be
a valid noop.


>>>      - complexifies automated media queries management
>>
>> What is "automated MQ management"?
>
> Given an arbitrary document with arbitrary stylesheets, where should
> I insert a new MQ to see the style rules it contains have visual impact,
> ie. be the ones that win the cascade? Even for handwritten CSS, this
> is an enormous issue.
>
>>>      - can't always express the @else case by a MQ
>>
>> Why is this a con?
>
> Turn a standalone @else in a valid @media.

It this the case you're talking about?

You start with
  @media (something) {
     /* foobar 1 */
  }
  @else (somethingelse) {
    /* foobar 2 */
  }

Over time, you change your stylesheet so that the foobar 1 block becomes empty:
  @media (something) { }
  @else (somethingelse) {
    /* foobar 2 */
  }

You would like to replace this by a single media query, but
  @media (somethingelse) and (not (something)) {
    /* foobar 2 */
  }
has subtly different semantics.

But I am not sure this is a downside of this proposal. The fact that it is strictly more expressive than what we had before sounds like an argument for it, not against it.

 - Florian
Reply | Threaded
Open this post in threaded view
|

Re: @else in Media Queries

Mark Brown
In reply to this post by Daniel Glazman
On Sat, Jun 11, 2016 at 4:34 PM, Daniel Glazman
<[hidden email]> wrote:
> On 10/06/2016 22:12, Tab Atkins Jr. wrote:
>> 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.
>
> Two consecutive rules in a valid sheet's OM: a @media followed by a
> @else. Through OM, @media is removed, stylesheet is now invalid because
> a standalone @else...

Why do you say the stylesheet is invalid? If an at-rule is invalid it
is discarded, but I don't see where it says that it makes the
stylesheet invalid.

>>>       - can't always express the @else case by a MQ
>>
>> Why is this a con?
>
> Turn a standalone @else in a valid @media.

Why does it have to be @media? It's much easier to turn it into a
@when, isn't it?

Mark

123