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

tcaptan-cr · 2023-03-06T21:53:34Z

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 · 2023-03-06T22:37:33Z

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 · 2023-03-06T22:39:09Z

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 · 2023-03-06T23:01:17Z

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 · 2023-03-06T23:17:34Z

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 · 2023-03-06T23:29:02Z

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

This change was triggered by the recently added wpt tests that started failing after auto import: third_party/blink/web_tests/external/wpt/css/css-images/image-set/image-set-zero-resolution-rendering.html third_party/blink/web_tests/external/wpt/css/css-images/image-set/image-set-zero-resolution-rendering-2.html Currently the spec does not restrict the range for resolution, thus non-positive resolutions are valid and should not be rejected at parse time. The current consensus is to parse the non-positive resolutions, but treat them as unsupported options for rendering purposes. With this change, image-set will match resolution parsing with media queries. An issue has been opend for the spec to define the valid argument range for resolution: w3c/csswg-drafts#8532 R=futhark, pdr Change-Id: I7b329519168f3c088f5c9ee8614931b0ead7a4df

This change was triggered by the recently added wpt tests that started failing after auto import: third_party/blink/web_tests/external/wpt/css/css-images/image-set/image-set-zero-resolution-rendering.html third_party/blink/web_tests/external/wpt/css/css-images/image-set/image-set-zero-resolution-rendering-2.html Currently the spec does not restrict the range for resolution, thus non-positive resolutions are valid and should not be rejected at parse time. The current consensus is to parse the non-positive resolutions, but treat them as unsupported options for rendering purposes. With this change, image-set will match resolution parsing with media queries. An issue has been opend for the spec to define the valid argument range for resolution: w3c/csswg-drafts#8532 In the discussion on the issue new proposals were added about how to treat zero resolutions for rendering purposes. Until the spec is well defined in this area we will remove the zero resolution rendering tests. R=futhark, pdr Change-Id: I7b329519168f3c088f5c9ee8614931b0ead7a4df

This change was triggered by the recently added wpt tests that started failing after auto import: third_party/blink/web_tests/external/wpt/css/css-images/image-set/image-set-zero-resolution-rendering.html third_party/blink/web_tests/external/wpt/css/css-images/image-set/image-set-zero-resolution-rendering-2.html Currently the spec does not restrict the range for resolution, thus non-positive resolutions are valid and should not be rejected at parse time. The current consensus is to parse the non-positive resolutions, but treat them as unsupported options for rendering purposes. With this change, image-set will match resolution parsing with media queries. An issue has been opend for the spec to define the valid argument range for resolution: w3c/csswg-drafts#8532 In the discussion on the issue new proposals were added about how to treat zero resolutions for rendering purposes. Until the spec is well defined in this area we will remove the zero resolution rendering tests. R=futhark, pdr Change-Id: I7b329519168f3c088f5c9ee8614931b0ead7a4df Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4312883 Commit-Queue: Philip Rogers <pdr@chromium.org> Commit-Queue: Traian Captan <tcaptan@chromium.org> Reviewed-by: Philip Rogers <pdr@chromium.org> Cr-Commit-Position: refs/heads/main@{#1114116}

https://bugs.webkit.org/show_bug.cgi?id=254388 rdar://107167273 Reviewed by NOBODY (OOPS!). Resolution ranges are currently not restricted by the specification, so we should accept them. Corresponding WPT commit with more details: web-platform-tests/wpt@6dd9e79 The two unskipped tests are for rendering, negative resolutions are considered invalid for rendering purposes, so they display as blank. However, they are still parsed, which means the declaration stays valid, which wasn't the case before. Also rebaseline parsing tests. It is possible that the spec changes again in the future: w3c/csswg-drafts#8532 * LayoutTests/TestExpectations: * LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-parsing-expected.txt: * Source/WebCore/css/parser/CSSPropertyParserHelpers.cpp: (WebCore::CSSPropertyParserHelpers::consumeImageSetOption):

This change was triggered by the recently added wpt tests that started failing after auto import: third_party/blink/web_tests/external/wpt/css/css-images/image-set/image-set-zero-resolution-rendering.html third_party/blink/web_tests/external/wpt/css/css-images/image-set/image-set-zero-resolution-rendering-2.html Currently the spec does not restrict the range for resolution, thus non-positive resolutions are valid and should not be rejected at parse time. The current consensus is to parse the non-positive resolutions, but treat them as unsupported options for rendering purposes. With this change, image-set will match resolution parsing with media queries. An issue has been opend for the spec to define the valid argument range for resolution: w3c/csswg-drafts#8532 In the discussion on the issue new proposals were added about how to treat zero resolutions for rendering purposes. Until the spec is well defined in this area we will remove the zero resolution rendering tests. R=futhark, pdr Change-Id: I7b329519168f3c088f5c9ee8614931b0ead7a4df Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4312883 Commit-Queue: Philip Rogers <pdr@chromium.org> Commit-Queue: Traian Captan <tcaptan@chromium.org> Reviewed-by: Philip Rogers <pdr@chromium.org> Cr-Commit-Position: refs/heads/main@{#1114116}

… to image-set, a=testonly Automatic update from web-platform-tests Add support for non-positive resolutions to image-set This change was triggered by the recently added wpt tests that started failing after auto import: third_party/blink/web_tests/external/wpt/css/css-images/image-set/image-set-zero-resolution-rendering.html third_party/blink/web_tests/external/wpt/css/css-images/image-set/image-set-zero-resolution-rendering-2.html Currently the spec does not restrict the range for resolution, thus non-positive resolutions are valid and should not be rejected at parse time. The current consensus is to parse the non-positive resolutions, but treat them as unsupported options for rendering purposes. With this change, image-set will match resolution parsing with media queries. An issue has been opend for the spec to define the valid argument range for resolution: w3c/csswg-drafts#8532 In the discussion on the issue new proposals were added about how to treat zero resolutions for rendering purposes. Until the spec is well defined in this area we will remove the zero resolution rendering tests. R=futhark, pdr Change-Id: I7b329519168f3c088f5c9ee8614931b0ead7a4df Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4312883 Commit-Queue: Philip Rogers <pdr@chromium.org> Commit-Queue: Traian Captan <tcaptan@chromium.org> Reviewed-by: Philip Rogers <pdr@chromium.org> Cr-Commit-Position: refs/heads/main@{#1114116} -- wpt-commits: 6dd9e79912d5161f24b2bf576e0b115c28cde956 wpt-pr: 38839

css-meeting-bot · 2023-04-05T23:56:07Z

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 · 2023-04-06T18:47:33Z

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.

This change was triggered by the recently added wpt tests that started failing after auto import: third_party/blink/web_tests/external/wpt/css/css-images/image-set/image-set-zero-resolution-rendering.html third_party/blink/web_tests/external/wpt/css/css-images/image-set/image-set-zero-resolution-rendering-2.html Currently the spec does not restrict the range for resolution, thus non-positive resolutions are valid and should not be rejected at parse time. The current consensus is to parse the non-positive resolutions, but treat them as unsupported options for rendering purposes. With this change, image-set will match resolution parsing with media queries. An issue has been opend for the spec to define the valid argument range for resolution: w3c/csswg-drafts#8532 In the discussion on the issue new proposals were added about how to treat zero resolutions for rendering purposes. Until the spec is well defined in this area we will remove the zero resolution rendering tests. R=futhark, pdr Change-Id: I7b329519168f3c088f5c9ee8614931b0ead7a4df Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4312883 Commit-Queue: Philip Rogers <pdr@chromium.org> Commit-Queue: Traian Captan <tcaptan@chromium.org> Reviewed-by: Philip Rogers <pdr@chromium.org> Cr-Commit-Position: refs/heads/main@{#1114116}

cdoublev · 2023-04-11T07:32:16Z

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 · 2023-04-14T22:49:34Z

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 · 2023-04-15T17:19:05Z

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

tabatkins · 2023-04-17T22:58:39Z

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?

See resolution in w3c/csswg-drafts#8532

Resulting from the discussion of issue 8532 [1] which asked to specify the argument range for resolution units, negative resolutions should now be excluded. Spec definition: [2] "The allowed range of <resolution> values always excludes negative values, in addition to any explicit ranges that might be specified." [1] w3c/csswg-drafts#8532 [2] https://www.w3.org/TR/css-values-4/#resolution-value R=pdr Change-Id: I20486e9e506683cb076551149c590da20d6eff08 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4518748 Commit-Queue: Traian Captan <tcaptan@chromium.org> Reviewed-by: Philip Rogers <pdr@chromium.org> Cr-Commit-Position: refs/heads/main@{#1142795}

…in calc expressions https://bugs.webkit.org/show_bug.cgi?id=254388 rdar://107167273 Reviewed by Tim Nguyen. In a CSSWG resolution it was decided that zero resolutions should be accepted by image-set but that they should produce an invalid image. This change accepts zero but will reject negative resolutions. In a follow-up we should clamp the result of calc expressions to zero. This change also resyncs the image-set WPT as of upstream commit c56aec6 w3c/csswg-drafts#8532 (comment) * LayoutTests/TestExpectations: * LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-negative-resolution-rendering-2.html: * LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-negative-resolution-rendering-3-expected.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-negative-resolution-rendering-3.html: Copied from LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-negative-resolution-rendering.html. * LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-negative-resolution-rendering-expected.html: * LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-negative-resolution-rendering.html: * LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-parsing-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-parsing.html: * LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-zero-resolution-rendering-2-expected.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-zero-resolution-rendering-2.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-zero-resolution-rendering-expected.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-zero-resolution-rendering.html: Added. * Source/WebCore/css/parser/CSSPropertyParserHelpers.cpp: (WebCore::CSSPropertyParserHelpers::consumeImageSetOption): * Source/WebCore/rendering/style/StyleImageSet.cpp: (WebCore::StyleImageSet::bestImageForScaleFactor): Canonical link: https://commits.webkit.org/264298@main

… invalid, a=testonly Automatic update from web-platform-tests [image-set] Negative resolutions are now invalid (#39840) See resolution in w3c/csswg-drafts#8532 -- wpt-commits: f191d6e935b7f2df4bd3103a07179af544244516 wpt-pr: 39840

… invalid (part 2), a=testonly Automatic update from web-platform-tests [image-set] Negative resolutions are now invalid (part 2) (#39849) See resolution in w3c/csswg-drafts#8532 -- wpt-commits: b0350b795dbf77ebf53713aca302e5d768d5db26 wpt-pr: 39849

… invalid, a=testonly Automatic update from web-platform-tests [image-set] Negative resolutions are now invalid (#39840) See resolution in w3c/csswg-drafts#8532 -- wpt-commits: f191d6e935b7f2df4bd3103a07179af544244516 wpt-pr: 39840

… invalid (part 2), a=testonly Automatic update from web-platform-tests [image-set] Negative resolutions are now invalid (part 2) (#39849) See resolution in w3c/csswg-drafts#8532 -- wpt-commits: b0350b795dbf77ebf53713aca302e5d768d5db26 wpt-pr: 39849

tabatkins added Agenda+ css-values-4 Current Work labels Mar 6, 2023

chromium-wpt-export-bot mentioned this issue Mar 7, 2023

Add support for non-positive resolutions to image-set web-platform-tests/wpt#38839

Merged

nt1m mentioned this issue Mar 24, 2023

[image-set] Stop rejecting negative resolutions WebKit/WebKit#11906

Closed

css-meeting-bot removed the Agenda+ label Apr 5, 2023

mozilla-apprentice mentioned this issue Apr 5, 2023

[css-values-4] Specify argument range for resolution mozilla/wg-decisions#1095

Closed

chromium-helper mentioned this issue Apr 5, 2023

[css-values-4] Specify argument range for resolution chromium-helper/csswg-resolutions#95

Closed

tabatkins added a commit that referenced this issue Apr 6, 2023

[css-values-4] Define that negative ranges are always invalid. #8532

b0defca

tabatkins closed this as completed Apr 6, 2023

tabatkins added the Needs Testcase (WPT) label Apr 6, 2023

nt1m added a commit to web-platform-tests/wpt that referenced this issue May 4, 2023

[image-set] Negative resolutions are now invalid

cf65932

See resolution in w3c/csswg-drafts#8532

nt1m mentioned this issue May 4, 2023

[image-set] Negative resolutions are now invalid web-platform-tests/wpt#39840

Merged

nt1m added a commit to web-platform-tests/wpt that referenced this issue May 4, 2023

[image-set] Negative resolutions are now invalid (#39840)

f191d6e

See resolution in w3c/csswg-drafts#8532

nt1m mentioned this issue May 4, 2023

[image-set] Negative resolutions are now invalid (part 2) web-platform-tests/wpt#39849

Merged

nt1m added a commit to web-platform-tests/wpt that referenced this issue May 4, 2023

[image-set] Negative resolutions are now invalid (part 2) (#39849)

b0350b7

See resolution in w3c/csswg-drafts#8532

rreno mentioned this issue May 5, 2023

[image-set] Handle zero resolution and clamping negative resolutions in calc expressions WebKit/WebKit#13479

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

tcaptan-cr commented Mar 6, 2023

tabatkins commented Mar 6, 2023

tabatkins commented Mar 6, 2023

emilio commented Mar 6, 2023

tabatkins commented Mar 6, 2023

emilio commented Mar 6, 2023

css-meeting-bot commented Apr 5, 2023

tabatkins commented Apr 6, 2023

cdoublev commented Apr 11, 2023

tabatkins commented Apr 14, 2023

emilio commented Apr 15, 2023

tabatkins commented Apr 17, 2023

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

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

Comments

tcaptan-cr commented Mar 6, 2023

tabatkins commented Mar 6, 2023

tabatkins commented Mar 6, 2023

emilio commented Mar 6, 2023

tabatkins commented Mar 6, 2023

emilio commented Mar 6, 2023

css-meeting-bot commented Apr 5, 2023

tabatkins commented Apr 6, 2023

cdoublev commented Apr 11, 2023

tabatkins commented Apr 14, 2023

emilio commented Apr 15, 2023

tabatkins commented Apr 17, 2023