Intent to Ship: Unprefix -webkit-image-set

334 views
Skip to first unread message

Traian Captan

unread,
Dec 5, 2022, 9:23:32 PM12/5/22
to blink-dev

Contact emails

tca...@chromium.org

Explainer

None

Specification

https://w3c.github.io/csswg-drafts/css-images-4/#image-set-notation

Summary

Unprefix -webkit-image-set to expose the current image-set functionality without needing the '-webkit-' prefix.



Blink component

Blink


Motivation

Currently Blink only supports '-webkit-' prefixed image-set, while Gecko and WebKit support both prefixed and unprefixed versions. With this change interop with Gecko and WebKit will be increased by allowing web developers to use the current Blink image-set functionality both with and without the '-webkit-' prefix.


Search tags

image-set

TAG review

Skipping because this is a straightforward interop fix.

TAG review status

Not applicable

Risks



Interoperability and Compatibility

The Interoperability Risk is Low. This change increases interop with Gecko and WebKit which already support both '-webkit-' prefixed and unprefixed image-set. The Compatibility Risk is Low. If both prefixed and standard versions are defined in the right order, and the standard version fails parsing, Blink will fallback to the prefixed version. The 'image-set-fallback' test has been added to verify this behavior.



Gecko: Shipped/Shipping (https://hg.mozilla.org/integration/autoland/rev/5c09b1d070e2)

WebKit: Shipped/Shipping (https://trac.webkit.org/changeset/202765/webkit)

Web developers: Strongly positive - This issue has been Starred by 55 users.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No



Debuggability

N/A

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/css/css-images/image-set

Flag name

CSSImageSet

Requires code in //chrome?

False

Tracking bug

https://crbug.com/630597

Estimated milestones

110 Or 111



Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5109745420075008

This intent message was generated by Chrome Platform Status.

Yoav Weiss

unread,
Dec 7, 2022, 6:37:49 AM12/7/22
to blink-dev, Traian Captan
LGTM1

Thanks for working on this!! Looking at wpt.fyi, other implementations are passing the test suite for this to varying degrees. Does this intent cover full compliance with the test suite? (e.g. `type()`, `url()`, non `x` descriptors, and maybe other dimensions) Or does it only cover the unprefixing and further interop improvements will come later?

Manuel Rego Casasnovas

unread,
Dec 7, 2022, 8:39:42 AM12/7/22
to Yoav Weiss, blink-dev, Traian Captan

On 07/12/2022 12:37, Yoav Weiss wrote:
> LGTM1
>
> Thanks for working on this!! Looking at wpt.fyi, other implementations
> are passing the test suite for this to varying degrees. Does this intent
> cover full compliance with the test suite? (e.g. `type()`, `url()`, non
> `x` descriptors, and maybe other dimensions) Or does it only cover the
> unprefixing and further interop improvements will come later?

I do wonder what's the goal of removing the prefix, if we're not also
improving the spec compliance and interoperability?

If we ship "image-set" people would expect it's a complete feature, and
then they'll get confused when somethings don't work. How are we going
to explain which is shipping exactly, is there any kind of documentation
about that?

Cheers,
Rego

>
> On Tuesday, December 6, 2022 at 3:23:32 AM UTC+1 Traian Captan wrote:
>
>
> Contact emails
>
> tca...@chromium.org <mailto:tca...@chromium.org>
>
>
> Explainer
>
> None
>
>
> Specification
>
> https://w3c.github.io/csswg-drafts/css-images-4/#image-set-notation
> <https://w3c.github.io/csswg-drafts/css-images-4/#image-set-notation>
>
>
> Summary
>
> Unprefix -webkit-image-set to expose the current image-set
> functionality without needing the '-webkit-' prefix.
>
>
>
> Blink component
>
> Blink
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>
>
>
>
> Motivation
>
> Currently Blink only supports '-webkit-' prefixed image-set, while
> Gecko and WebKit support both prefixed and unprefixed versions. With
> this change interop with Gecko and WebKit will be increased by
> allowing web developers to use the current Blink image-set
> functionality both with and without the '-webkit-' prefix.
>
>
> Search tags
>
> image-set <https://chromestatus.com/features#tags:image-set>
>
>
> TAG review
>
> Skipping because this is a straightforward interop fix.
>
>
> TAG review status
>
> Not applicable
>
>
> Risks
>
>
>
> Interoperability and Compatibility
>
> The Interoperability Risk is Low. This change increases interop with
> Gecko and WebKit which already support both '-webkit-' prefixed and
> unprefixed image-set. The Compatibility Risk is Low. If both
> prefixed and standard versions are defined in the right order, and
> the standard version fails parsing, Blink will fallback to the
> prefixed version. The 'image-set-fallback' test has been added to
> verify this behavior.
>
>
>
> /Gecko/: Shipped/Shipping
> (https://hg.mozilla.org/integration/autoland/rev/5c09b1d070e2
> <https://hg.mozilla.org/integration/autoland/rev/5c09b1d070e2>)
>
> /WebKit/: Shipped/Shipping
> (https://trac.webkit.org/changeset/202765/webkit
> <https://trac.webkit.org/changeset/202765/webkit>)
>
> /Web developers/: Strongly positive - This issue has been Starred by
> 55 users.
>
> /Other signals/:
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such
> that it has potentially high risk for Android WebView-based
> applications?
>
> No
>
>
>
> Debuggability
>
> N/A
>
>
> Will this feature be supported on all six Blink platforms
> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
>
> Yes
>
>
> Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
>
> Yes
> https://wpt.fyi/results/css/css-images/image-set
> <https://wpt.fyi/results/css/css-images/image-set>
>
>
> Flag name
>
> CSSImageSet
>
>
> Requires code in //chrome?
>
> False
>
>
> Tracking bug
>
> https://crbug.com/630597 <https://crbug.com/630597>
>
>
> Estimated milestones
>
> 110 Or 111
>
>
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat
> or interop issues. Please list open issues (e.g. links to known
> github issues in the project for the feature specification) whose
> resolution may introduce web compat/interop risk (e.g., changing to
> naming or structure of the API in a non-backward-compatible way).
>
> None
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5109745420075008
> <https://chromestatus.com/feature/5109745420075008>
>
> This intent message was generated by Chrome Platform Status
> <https://chromestatus.com/>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5e1384ee-25d0-4e9c-aab4-599faaf02e59n%40chromium.org <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5e1384ee-25d0-4e9c-aab4-599faaf02e59n%40chromium.org?utm_medium=email&utm_source=footer>.

Stefan Zager

unread,
Dec 7, 2022, 5:12:45 PM12/7/22
to Manuel Rego Casasnovas, Yoav Weiss, blink-dev, Traian Captan
On Wed, Dec 7, 2022 at 5:39 AM Manuel Rego Casasnovas <re...@igalia.com> wrote:

On 07/12/2022 12:37, Yoav Weiss wrote:
> LGTM1
>
> Thanks for working on this!! Looking at wpt.fyi, other implementations
> are passing the test suite for this to varying degrees. Does this intent
> cover full compliance with the test suite? (e.g. `type()`, `url()`, non
> `x` descriptors, and maybe other dimensions) Or does it only cover the
> unprefixing and further interop improvements will come later?

I do wonder what's the goal of removing the prefix, if we're not also
improving the spec compliance and interoperability?

If we ship "image-set" people would expect it's a complete feature, and
then they'll get confused when somethings don't work. How are we going
to explain which is shipping exactly, is there any kind of documentation
about that?

IMO, un-prefixing is an un-alloyed good thing, regardless of how spec compliant chromium's implementation is. If it is in fact as buggy as you suggest, then let the bugs flow!

 
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/250ec61a-ba76-3bb3-8798-c1e546d7a554%40igalia.com.

Traian Captan

unread,
Dec 7, 2022, 9:17:43 PM12/7/22
to Yoav Weiss, blink-dev
Thanks Yoav!

This intent only covers the unprefixing.
Further interop improvements will come later.

Regards,
Traian


Traian Captan

unread,
Dec 7, 2022, 9:47:22 PM12/7/22
to Manuel Rego Casasnovas, Yoav Weiss, blink-dev
Hi Rego,
 
I do wonder what's the goal of removing the prefix, if we're not also
improving the spec compliance and interoperability?
It's an incremental step in the direction of spec compliance and interoperability.
Further improvements will follow.
This is similar to how Firefox handled the implementation, splitting it over several patches and releases (https://bugzilla.mozilla.org/show_bug.cgi?id=1107646).

If we ship "image-set" people would expect it's a complete feature, and
then they'll get confused when somethings don't work. How are we going
to explain which is shipping exactly, is there any kind of documentation
about that?
I would expect that if they find something that doesn't work, they would open bug / feature requests, which we can use to prioritize what we should look at implementing next.

Regards,
Traian

Traian Captan

unread,
Dec 7, 2022, 9:49:20 PM12/7/22
to Stefan Zager, Manuel Rego Casasnovas, Yoav Weiss, blink-dev
Thanks Stefan!

That makes sense.
We do plan to address some of the other issues.
Having bugs filed would be helpful in prioritizing what we should focus on next.

Regards,
Traian

Manuel Rego Casasnovas

unread,
Dec 14, 2022, 7:28:31 AM12/14/22
to Traian Captan, Yoav Weiss, blink-dev
If we have plans to fix issues on this feature later, why not fixing
them before and then shipping when things look good?

If we unprefix it, it'll kind of appear as a new Chromium feature that
people can use, and they will expect it follows the spec. But we'll have
to document it just works for this specific syntax but not this other
and things like that, which would be hard to document and explain. Then
as bugs are fixed more syntax will be supported, how are we going to
announce that?

Checking the tests results in wpt.fyi:
https://wpt.fyi/results/css/css-images/image-set/image-set-parsing.html?label=master&product=chrome%5Bexperimental%5D&product=chrome%5Bstable%5D&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&aligned&view=subtest

I'm confused about the first examples there:
* e.style['background-image'] = "image-set(url(example.png) 1x)"
is passing
But:
* e.style['background-image'] = "-webkit-image-set(url(example.png) 1x)"
should set the property value
is not passing

The first test is failing in without the runtime flag, and is passing
with it. I'm not sure I'm understanding what we're shipping exactly, as
I understood it was the same syntax than then prefixed version.

Cheers,
Rego

On 08/12/2022 03:47, Traian Captan wrote:
> Hi Rego,
>  
>
> I do wonder what's the goal of removing the prefix, if we're not also
> improving the spec compliance and interoperability?
>
> It's an incremental step in the direction of spec compliance and
> interoperability.
> Further improvements will follow.
> This is similar to how Firefox handled the implementation, splitting it
> over several patches and releases
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1107646
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1107646>).
>
> If we ship "image-set" people would expect it's a complete feature, and
> then they'll get confused when somethings don't work. How are we going
> to explain which is shipping exactly, is there any kind of documentation
> about that?
>
> I would expect that if they find something that doesn't work, they would
> open bug / feature requests, which we can use to prioritize what we
> should look at implementing next.
>
> Regards,
> Traian
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvsO-axM0xi_E1bKQHk0_KgorSsJCQKmdA4EM_axOgm5hg%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvsO-axM0xi_E1bKQHk0_KgorSsJCQKmdA4EM_axOgm5hg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Noam Rosenthal

unread,
Dec 14, 2022, 9:42:02 AM12/14/22
to Manuel Rego Casasnovas, Traian Captan, Yoav Weiss, blink-dev
On Wed, Dec 14, 2022 at 2:28 PM Manuel Rego Casasnovas <re...@igalia.com> wrote:
If we have plans to fix issues on this feature later, why not fixing
them before and then shipping when things look good?

If we unprefix it, it'll kind of appear as a new Chromium feature that
people can use, and they will expect it follows the spec.

I agree, for example people might (wrongfully) rely on CSS.supports("background-image", "image-set(url(example.jpg) 1x)")
to mean that the full set of image-set features is supported.
I'm not sure people are more granular than that about feature detection but we probably have data about that.
 
It might be wise to support the cases behind the prefix, and unprefix when the behavior is close to complete and interoperable enough.
We don't need to rely on people posting bug reports when we know the issues today by looking at the WPT failures.

Traian Captan

unread,
Jan 23, 2023, 5:47:41 PM1/23/23
to Manuel Rego Casasnovas, Yoav Weiss, blink-dev
Hi Rego,

If we have plans to fix issues on this feature later, why not fixing
them before and then shipping when things look good?
Sounds good. I'll fix the issues first, and then I will update the Intent.

Checking the tests results in wpt.fyi:
https://wpt.fyi/results/css/css-images/image-set/image-set-parsing.html?label=master&product=chrome%5Bexperimental%5D&product=chrome%5Bstable%5D&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&aligned&view=subtest

I'm confused about the first examples there:
* e.style['background-image'] = "image-set(url(example.png) 1x)"
  is passing
But:
* e.style['background-image'] = "-webkit-image-set(url(example.png) 1x)"
should set the property value
  is not passing
That is a strange one that I was also confused by initially as well. It is because the '-webkit-' prefixed 'image-set' is expected to serialize to the same value as standard 'image-set': 
"Implementations must accept -webkit-image-set() as a parse-time alias
of image-set(). (It’s a valid value, with identical arguments to
image-set(), and is turned into image-set() during parsing.)"
Chrome is returning "-webkit-image-set(url(\"example.png\") 1x)" while the expected is "image-set(url(\"example.png\") 1x)"

Traian Captan

unread,
Jan 23, 2023, 5:57:44 PM1/23/23
to Noam Rosenthal, Manuel Rego Casasnovas, Yoav Weiss, blink-dev
Thanks Noam!

I'll add support for the other cases behind the feature flag and we'll ship it when we are "interoperable enough".

Regards,
Traian

Traian Captan

unread,
Mar 8, 2023, 2:40:55 AM3/8/23
to Noam Rosenthal, Manuel Rego Casasnovas, Yoav Weiss, blink-dev
Hi,

Following the previous conversation, we worked on adding support for the missing functionality that is currently described in the image-set spec.

Here is the updated intent:

Contact emails

Summary

Unprefix -webkit-image-set to expose the current image-set functionality without needing the '-webkit-' prefix, and add support for the functionality currently described in the image-set spec.



Blink component

Blink

Search tags

image-set

TAG review

Skipping because this is a straightforward interop fix.

TAG review status

Not applicable

Risks



Interoperability and Compatibility

The Interoperability Risk is Low. This change increases interop with Gecko and WebKit which already support both '-webkit-' prefixed and unprefixed image-set, and are also actively working on improving their image-set implementations as part of Interop 2023 efforts. The Compatibility Risk is Low.

Web developers: Strongly positive This issue has been Starred by 55 users.

Other signals:


WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No



Debuggability



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes


Flag name

CSSImageSet

Requires code in //chrome?

False

Tracking bug

https://crbug.com/630597

Estimated milestones

No milestones specified



Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5109745420075008

Links to previous Intent discussions

Intent to Ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/JXcRP4MJc9I


This intent message was generated by Chrome Platform Status.

Regards,
Traian

Yoav Weiss

unread,
Mar 8, 2023, 4:54:02 AM3/8/23
to Traian Captan, Noam Rosenthal, Manuel Rego Casasnovas, blink-dev
My LGTM1 still stands! :)

Even though wpt.fyi is reddish, I'm seeing all the tests pass on ToT. Thank you!!

Manuel Rego Casasnovas

unread,
Mar 8, 2023, 9:51:47 AM3/8/23
to Yoav Weiss, Traian Captan, Noam Rosenthal, blink-dev
LGTM2

Thank you very much for fixing the issues before shipping.

On 08/03/2023 10:53, Yoav Weiss wrote:
> Even though wpt.fyi
> <https://wpt.fyi/results/css/css-images/image-set/image-set-computed.sub.html?label=experimental&label=master&aligned> is reddish, I'm seeing all the tests pass on ToT. Thank you!!

I guess that's because wpt.fyi is still using Chrome 112, when the last
patches have landed in 113.

Cheers,
Rego

Traian Captan

unread,
Mar 8, 2023, 3:53:44 PM3/8/23
to Yoav Weiss, Noam Rosenthal, Manuel Rego Casasnovas, blink-dev
Thanks Yoav!

Traian Captan

unread,
Mar 8, 2023, 3:55:56 PM3/8/23
to Manuel Rego Casasnovas, Yoav Weiss, Noam Rosenthal, blink-dev
Thanks Rego!

Daniel Bratell

unread,
Mar 8, 2023, 5:40:10 PM3/8/23
to Manuel Rego Casasnovas, Yoav Weiss, Traian Captan, Noam Rosenthal, blink-dev
LGTM3 to ship image-set

/Daniel

Traian Captan

unread,
Mar 8, 2023, 5:44:48 PM3/8/23
to Daniel Bratell, Manuel Rego Casasnovas, Yoav Weiss, Noam Rosenthal, blink-dev
Thanks Daniel!

Reply all
Reply to author
Forward
0 new messages