Re: @else in Media Queries

(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
<daniel.glazman@disruptive-innovations.com> 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 <mark@mercurylang.org> 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

Received on Friday, 10 June 2016 18:31:55 UTC