Unprefix -webkit-image-set to expose the current image-set functionality without needing the '-webkit-' prefix.
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.
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.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No
110 Or 111
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
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?
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.
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?
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.
If we have plans to fix issues on this feature later, why not fixing
them before and then shipping when things look good?
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
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.
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.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No
No milestones specified
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