Repository navigation
[css-values-4] Specify argument range for resolution #8532
Description
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.
Activity
tabatkins commentedon Mar 6, 2023
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 commentedon Mar 6, 2023
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 commentedon Mar 6, 2023
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 commentedon Mar 6, 2023
I doubt anyone's relying on negative resolutions? So I suspect it's fine to just change the tests.
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 commentedon Mar 6, 2023
Yeah, agreed it should be safe (we didn't honor them anywhere until recently, that linked commit).
Add support for non-positive resolutions to image-set
Add support for non-positive resolutions to image-set
Add support for non-positive resolutions to image-set
Add support for non-positive resolutions to image-set
Add support for non-positive resolutions to image-set
Add support for non-positive resolutions to image-set
Add support for non-positive resolutions to image-set
[image-set] Stop rejecting negative resolutions
12 remaining items
tabatkins commentedon Apr 17, 2023
Not technically - other usages gain ranges from the property, not the function.
That is,
widthhas<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 saywidth: 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?
[image-set] Negative resolutions are now invalid
[image-set] Negative resolutions are now invalid (#39840)
[image-set] Negative resolutions are now invalid (part 2) (#39849)
Exclude negative resolutions in image-set
[image-set] Handle zero resolution and clamping negative resolutions …
Bug 1831253 [wpt PR 39840] - [image-set] Negative resolutions are now…
Bug 1831372 [wpt PR 39849] - [image-set] Negative resolutions are now…
Bug 1820684 [wpt PR 38839] - Add support for non-positive resolutions…
Bug 1831253 [wpt PR 39840] - [image-set] Negative resolutions are now…
Bug 1831372 [wpt PR 39849] - [image-set] Negative resolutions are now…