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 08:34:16 +0200
To: www-style list <www-style@w3.org>
Message-ID: <224f7ffa-ab58-2c74-8961-408517610820@disruptive-innovations.com>
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?


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

Received on Saturday, 11 June 2016 06:34:42 UTC

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