[css-values-4] Specify argument range for resolution

[tcaptan-cr]

Currently the resolution-value is defined as:

The < resolution > unit represents the size of a single "dot" in a graphical representation by indicating how many of these dots fit in a CSS in, cm, or px.

However, no argument range is currently specified for the resolution unit, which would imply that zero and negative resolution values are valid.

Given the resolution is a ratio of physical "dots" to CSS px, in or cm, non-positive values do not make sense.

After discussing this issue with @emilio we thought it would be good if it would be well defined in the spec as [1, ∞].

MDN does currently mention a restriction to "strictly positive" that is not in the spec:

The < resolution > data type consists of a strictly positive < number > followed by one of the units listed below.

[tabatkins]

There's nothing wrong with a resolution between 1 and 0, and in general CSS tries to avoid open ranges (see the wiki) so "strictly positive" should be avoided if possible. In general, a zero resolution isn't problematic anyway; it's a degenerate resolution, sure, but just as meaningful in practice as any extremely small resolution value.

However, negative resolutions are indeed nonsensical. I think it's reasonable to add a range into V&U; this'll make negative values invalid by default, and clamp them to 0 if put in a math function.

[tabatkins]

Agenda+ for a resolution just due to the spec's stability. Proposal is to add a default range restriction to <resolution> values requiring they be non-negative. (They'll be treated the same as a negative length in a property that only allows non-negative lengths; this restriction will just apply to every place that accepts a resolution automatically.)

[emilio]

Sounds good, but just to double-check, media queries too? There's a bunch of tests expecting negative resolutions to parse in media queries, see web-platform-tests/wpt#24433, https://hg.mozilla.org/mozilla-central/rev/50b2f3e731efb6aab243709544a1934982f0c215.

CC @frivoal since he introduced at least a few of them.

Also, we should define how does a zero resolution image render... Probably should be rendered as another invalid image?

[tabatkins]

I doubt anyone's relying on negative resolutions? So I suspect it's fine to just change the tests.

Also, we should define how does a zero resolution image render... Probably should be rendered as another invalid image?

In image-set()? We could do that, or just clamp the resolution to a UA-defined minimum. Arbitrarily small resolutions would produce image blowups anyway, which are probably not desirable.

[emilio]

Yeah, agreed it should be safe (we didn't honor them anywhere until recently, that linked commit).

[css-meeting-bot]

The CSS Working Group just discussed [css-values-4] Specify argument range for resolution, and agreed to the following:

• RESOLVED: negative <resolution> values are invalid

The full IRC log of that discussion

<dael> TabAtkins: It was noted that it is possible to write a negative resolution and not def what that means. Prop is the resolution type as a general case says negative is invalid
<dael> TabAtkins: IN a calc we would clamp it.
<dael> TabAtkins: V&U is mature spec so need resolution
<dael> TabAtkins: Resolution type is restricted to non-negative values
<dael> fantasai: sgtm
<fantasai> RESOLVED: negative <resolution> values are invalid
<fantasai> scribe+ fantasai

[tabatkins]

Done; negative resolutions are now defined to always be outside the allowed range. This makes it invalid in all contexts, but will cause it to clamp when used in a math function.

[cdoublev]

This makes it invalid in all contexts, but will cause it to clamp when used in a math function.

calc(-1dppx) is invalid but calc(-1 * 1dppx) is valid (and clamped), right?

[tabatkins]

Hm, calc(-1dppx) being invalid wasn't explicitly intended, but yes, it does flow from the definition, and that's fine.

calc(-1 * 1dppx) is indeed valid and clamped.

[emilio]

That's inconsistent with all other calc() dimensions tho, seems unfortunate

[tabatkins]

Not technically - other usages gain ranges from the property, not the function.

That is, width has <length-percentage [0, ∞]> in its grammar, so a calc() must resolve to a non-negative length, but within the calc() itself negative lengths are fine; it's okay to say width: calc(-1 * 10px) to get a 10px length.

On the other hand, the way I specified this, all <resolution> productions implicitly have a non-negative constraint, which includes the ones allowed in math functions.

Now, this isn't a necessity. It was the easiest way to specify the resolution, but I could explicitly carve out an exception for math functions, I suppose?