[mediaqueries-4][mediaqueries-5] Is the `<mf-range>` "swapping value and name" syntax really useful?

[emilio]

The <mf-range> syntax allows:

<mf-range> = <mf-name> [ '<' | '>' ]? '='? <mf-value>
           | <mf-value> [ '<' | '>' ]? '='? <mf-name>

That is, both 500px > width and width > 500px is valid.

This is nice, but given <mf-value> can also be an <ident> it causes ambiguity, and complexity / slowness while parsing.

Given you can easily use negations, I think it's not terribly useful, but if people feel very strongly about it the spec should define how to resolve the syntax ambiguity.

[emilio]

cc @frivoal

[emilio]

There's a further problem with that, which is that we parse the value in terms of the feature name, so if we haven't seen the feature name we don't know which kind of value we're parsing. This becomes a bigger problem given you may need to parse arbitrary stuff like calc() as part of <integer>s or <length>s.

[tabatkins]

The full 100px < width < 500px syntax is useful (and one of the main reasons we finally revived this syntax), and has the same issues as the more trivial 100px < width example you bring up.

[tabatkins]

Oh, hm, I guess 100px < width < 500px is detectable just from the number of tokens there, while 100px < width isn't as easy to tell.

I'm fine with just dropping that syntax clause, then, if that's the only problem.

[emilio]

Yeah, though even if it's detectable it's kind of a pain to detect, you need to start accumulating tokens and doing lookahead instead of just looking at the feature name.

Is (100px < width < 500px) really so much more useful than (width > 100px) and (width < 500px) to justify the implementation complexity?

[frivoal]

I think the readability benefits are quite strong. In a media query that only consists of (100px < width < 500px) (or the expanded form), it is not that critical, but as soon as you combine it in some larger boolean syntax, the mental overhead goes way up if you have to think of it as a boolean expression, rather than a simple range thing. Yes, it is equivalent, but reading it as a range is much easier.

@media (pointer) or (100px < width < 500px) {...}
vs
@media (pointer) or ((width > 100px) and (width < 500px)) {...}

It is just syntactic sugar, so if the concern from the implementation side is too strong, we could simplify a bit, but it is really nice sugar.

Like Tab, I wouldn't be too sad about loosing 500px > width in favor of width < 500px, but I would be sad about loosing 100px < width < 500px

[css-meeting-bot]

The Working Group just discussed <mf-range>, and agreed to the following:

• RESOLVED: Close this issue with no change

The full IRC log of that discussion

<heycam> Topic: <mf-range>
<heycam> github: https://github.com//issues/2791
<heycam> florian: (width < 100px) is allowed in MQ L4
<heycam> ... it also lets you do (100px > width) which people don't care about strongly
<heycam> ... but they also let you do (50px < width < 100px)
<heycam> ... Firefox has implemented the first one
<heycam> ... and claimed that the second two are more difficult to implement
<heycam> emilio: it's not that I'd like not to, it's that it's somewhat annoying
<heycam> ... the way we parts MQs now, you look at the media feature name, you know what kind of value you parse, so you have the value before it, it is more annoying to figure out which is the media feature name
<heycam> ... and identifiers can also be media feature values
<heycam> ... if you have an ident operator ident, you can't reject it, because you can't know that a range feature with ident values wouldn't make sense, biut...
<heycam> florian: I think the third option is nice
<heycam> ... Tab's suggestion was if dropping the middle one, you can still easily identify the media feature for the third one, just a couple more tokens later
<heycam> emilio: I think if we're going to keep the last one, we may as well keep the previous one
<heycam> astearns: doesn't make it much easier
<heycam> astearns: are you the only ones implementing this?
<heycam> emilio: I think so, so far
<heycam> frremy: that was two weeks ago
<heycam> ericwilligers: I think this is clear:
<heycam> width < 100
<heycam> 100 <= width < 200
<heycam> 200 < width
<heycam> ericwilligers: with the last one the width on the RHS
<heycam> florian: if removing the middle one was a signficiant simplification, we can do it, but sounds like not
<heycam> RESOLVED: Close this issue with no change