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

Re: @else in Media Queries

From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Date: Sat, 11 Jun 2016 09:38:41 +0200
To: Florian Rivoal <florian@rivoal.net>
Cc: www-style list <www-style@w3.org>
Message-ID: <e8c6e329-a2b7-a10b-a981-adf555a8368d@disruptive-innovations.com>
On 11/06/2016 09:04, Florian Rivoal wrote:

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

Unaware or old-fashion, without knowledge of @else. Yes, absolutely.

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

Earlier in this thread, someone mentioned "all programming languages".
There's not a single programming language I use these days that
lets you delete the two first lines preserving the two last ones in

  if (foo)

without choking. This is what I think we should avoid here. I don't
want standalone @else rules to appear because an OM-based app or webapp
hasn't been updated to deal with @else. We would break 20+ years of
"deletion of a valid rule does not change validity of a sheet".

Again, I understand the rationale behind the proposal and how/why it
can be useful to some users (although I'm not sure it's that critical
and not sure it's worth the hassle) but I think there are issues to
solve to have something balanced, well integrated to CSS and in
particular its OM. I also understand that @else cannot be, ATM, inside
@media (or @when or whatever) because an invalid rule would trash the
@else block with it. I find *extremely* ugly the possibility to
keep standalone @else rules in a sheet if one deletes the preceding

And I'm still highly concerned by the side-effects of @else on a tool
like BlueGriffon. Or DreamWeaver, Macaw, Visual Studio Web, and all

Received on Saturday, 11 June 2016 07:39:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:47 UTC