- 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>
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) blah; else; other; 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 @media/@when/whetever. 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 others. </Daniel>
Received on Saturday, 11 June 2016 07:39:13 UTC