Hi Rego, Thank you for your message!
> This issue has been bugging devs since 2016. > > > > I'm landing a patch > > <https://chromium-review.googlesource.com/c/chromium/src/+/4063134> to > > unprefix -webkit-image-set which will expose the current image-set > > functionality without needing the '-webkit-' prefix. > I don't think this is the right way to move this topic. 3 LGTMs from > 2016 shouldn't be enough to land the change without a previous notice on > this thread. Sorry about that, it was meant more as an FYI on the old thread since there was no follow up after the LGTMs and the issue is still open. I will create a new Chrome status entry and send out a brand new email about it. > > To address the compat issue, if both prefixed and standard versions are > > defined in the right order, > > and the standard version fails parsing, Chrome will fallback to the > > prefixed version. > > The `image-set-fallback` test has been added to verify this behavior. > > Unprefixing image-set fixes 2 of the failing subtests of the > > image-set-parsing WPT test > > < > https://wpt.fyi/results/css/css-images/image-set/image-set-parsing.html?label=master&label=experimental&aligned&view=subtest&q=image-set-parsing > > > > > > As a follow up, I will investigate whether we can fix the remaining > > compat issues. > > How is the interop with WebKit and Firefox implementations? > According to MDN Firefox added support for -webkit-image-set() in > version 90, so it'd be nice that this change is in alignment too. > WebKit and Firefox support both prefixed and unprefixed versions. I am not removing the prefixed version, only adding the possibility of using the current functionality without needing the `-webkit-` prefix. > What's the status of WPT tests? Why only 2 subtests are getting fixed > with this change? Are there plans to fix the rest? > For the image-set-parsing test, Firefox is passing 46/50, Safari 37/50 and Chrome 20/50 (22 with my patch). For the overall WPT tests for image-set <https://wpt.fyi/results/css/css-images/image-set?label=master&label=experimental&aligned&view=subtest&q=image-set>, Firefox is passing 71/77, Safari 50/77 and Chrome 23/77 (25 with my patch). We only pass 2 more tests because we are only exposing the current implemented functionality not adding any new functionality with this patch. I will follow up with additional fixes for some of the other issues. > Do we have use counters for both the prefixed and uprefixed versions to > see if we can get rid of them in the future? > Yes, we have counters for both, but I don't think we can get rid of the prefixed version, as there were talks about adding the prefixed version to the spec: https://github.com/w3c/csswg-drafts/issues/6285 I guess we should also update things at: > https://chromestatus.com/feature/5432024223449088 I'll send a brand new one. > And probably notify MDN so it can get updated if the prefix is no longer > needed in any browser. > Good idea. Regards, Traian On Wed, Nov 30, 2022 at 11:57 PM Manuel Rego Casasnovas <r...@igalia.com> wrote: > Hi, > > On 01/12/2022 00:59, Traian Captan wrote: > > This issue has been bugging devs since 2016. > > > > I'm landing a patch > > <https://chromium-review.googlesource.com/c/chromium/src/+/4063134> to > > unprefix -webkit-image-set which will expose the current image-set > > functionality without needing the '-webkit-' prefix. > I don't think this is the right way to move this topic. 3 LGTMs from > 2016 shouldn't be enough to land the change without a previous notice on > this thread. > > > To address the compat issue, if both prefixed and standard versions are > > defined in the right order, > > and the standard version fails parsing, Chrome will fallback to the > > prefixed version. > > The `image-set-fallback` test has been added to verify this behavior. > > Unprefixing image-set fixes 2 of the failing subtests of the > > image-set-parsing WPT test > > < > https://wpt.fyi/results/css/css-images/image-set/image-set-parsing.html?label=master&label=experimental&aligned&view=subtest&q=image-set-parsing > > > > > > As a follow up, I will investigate whether we can fix the remaining > > compat issues. > > How is the interop with WebKit and Firefox implementations? > According to MDN Firefox added support for -webkit-image-set() in > version 90, so it'd be nice that this change is in alignment too. > > What's the status of WPT tests? Why only 2 subtests are getting fixed > with this change? Are there plans to fix the rest? > > Do we have use counters for both the prefixed and uprefixed versions to > see if we can get rid of them in the future? > > I guess we should also update things at: > https://chromestatus.com/feature/5432024223449088 > > And probably notify MDN so it can get updated if the prefix is no longer > needed in any browser. > > Cheers, > Rego > > > > > Regards, > > Traian > > > > On Tuesday, August 30, 2016 at 8:51:03 AM UTC-7 dgla...@google.com > wrote: > > > > LGTM3 + investigate the syntax issue mentioned by PhistucK. > > > > :DG< > > > > > > On Monday, August 29, 2016 at 5:06:06 PM UTC-7, Dru Knox wrote: > > > > Is this blocked on API owner feedback? > > > > On Mon, Aug 15, 2016 at 1:47 AM PhistucK <phis...@gmail.com> > wrote: > > > > It has come to my attention in comment 5 > > < > https://bugs.chromium.org/p/chromium/issues/detail?id=630597#c5> that the > standard syntax is a superset of the Blink syntax. > > https://drafts.csswg.org/css-images-3/#image-set-notation > > <https://drafts.csswg.org/css-images-3/#image-set-notation> > > > > Blink supports - > > background-image: image-set( url("foo.png") 1x, > > url("foo-2x.png") 2x, > > url("foo-print.png") 3x ); > > > > The standard supports this - > > background-image: image-set( "foo.png" 1x, > > url("foo-2x.png") 2x, > > "foo-print.png" 600dpi ); > > Basically, you do not need url("..."), you can enter it as a > > string without the url() function. Also, the resolution part > > supports more than just #x. > > > > I do not have Safari, but according to the unprefixing > > layout test, it looks like it does not support the standard > > syntax as well. > > > > Should the standard syntax be dropped? Can you talk to > > WebKit and see if they intend to implement the standard > syntax? > > > > > > ☆*PhistucK* > > > > On Fri, Aug 12, 2016 at 11:47 PM, Chris Harrelson > > <chri...@chromium.org> wrote: > > > > LGTM2 > > > > On Fri, Aug 12, 2016 at 1:11 PM, Philip Jägenstedt > > <foo...@chromium.org> wrote: > > > > Easy LGTM1. Given that authors generally assume that > > prefixed things are aliases and that WebKit has made > > it just so, whatever problems there might be with > > image-set, the only way to move forward is to > > consider -webkit-image-set as part of the compat > > constraint and navigate accordingly. > > > > When it comes to tests, I guess this (like almost > > all) feature doesn't have a shared test suite that > > we actually use? Nothing > > in > https://github.com/w3c/csswg-test/tree/master/css-images-3 < > https://github.com/w3c/csswg-test/tree/master/css-images-3> and I don't > know where else it would be? > > > > I suspect that contributing to csswg-tests is, like > > web-platform-tests, not streamlined enough to > > require it for shipping new things, but it would be > > great if you wanted to take a look at how feasible > > it is in this case. Even just a few reftests testing > > the very basics would be valuable. > > > > Finally, I wouldn't assume that compat risk is low. > > When things (like the Fullscreen API...) are > > prefixed only for a very long time, it's actually > > possible that merely unprefixing can break things. > > Let's hope this one works out. > > > > On Fri, Aug 12, 2016 at 5:59 PM John Mellor > > <joh...@chromium.org> wrote: > > > > The CSS image-set spec is old, and has a major > > todo > > < > https://drafts.csswg.org/css-images-3/#issue-952b7afb>: it only supports > variations in screen density (1x, 2x, etc), but doesn't yet allow for > selecting images based on viewport width < > https://html.spec.whatwg.org/multipage/embedded-content.html#viewport-based-selection> > like > the more modern <img> srcset+sizes attributes < > https://jakearchibald.com/2015/anatomy-of-responsive-images/#varying-size-and-density>. > Media queries aren't sufficient for this (though they nicely handle the art > direction < > https://html.spec.whatwg.org/multipage/embedded-content.html#art-direction> > use > case, so CSS won't additionally need an equivalent to the <picture> and > <source> elements < > https://jakearchibald.com/2015/anatomy-of-responsive-images/#varying-width-density-and-art-direction > >). > > > > That said, unprefixed image-set is perhaps > > already a defacto standard (due to websites > > preemptively unprefixing it, and soon Safari > > shipping it), so it's likely that when selecting > > images based on viewport width eventually gets > > added to CSS images, that will be done by > > extending the image-set syntax in a backwards > > compatible way. > > > > On 8 August 2016 at 08:04, PhistucK > > <phis...@gmail.com> wrote: > > > > Edge shows positive signs > > - > https://developer.microsoft.com/en-us/microsoft-edge/platform/status/cssimageset?filter=f3f0000bf&search=image-set > < > https://developer.microsoft.com/en-us/microsoft-edge/platform/status/cssimageset?filter=f3f0000bf&search=image-set > >. > > > > ☆*PhistucK* > > > > On Mon, Aug 8, 2016 at 8:51 AM, Elliott > > Sprehn <esp...@chromium.org> wrote: > > > > Is our implementation compatible with > > Safari? Is there a test suite? > > > > > > On Aug 7, 2016 10:31 PM, "Sunil Ratnu" > > <sunil...@samsung.com> wrote: > > > > *Contact emails > > *sunil...@samsung.com > > > > > > > > *Spec* > > > https://drafts.csswg.org/css-images-3/#image-set-notation < > https://drafts.csswg.org/css-images-3/#image-set-notation> > > > > > > > > *Summary* > > Support unprefixed version of > image-set. > > > > > > > > *Motivation* > > Currently blink implementation is > > "webkit" prefixed. Given Safari also > > recently unprefixed image-set, > > unprefixing can be done without any > > risk. > > > > Link to the WebKit change: > > > https://trac.webkit.org/changeset/202765 < > https://trac.webkit.org/changeset/202765> > > > > > > > > *Interoperability and Compatibility > Risk > > *Low. > > Firefox and Edge do not support > > image-set. Only Chrome and Safari > > support it. Safari also has recently > > unprefixed -webkit-image-set. > > > > > > > > *Ongoing technical constraints > > *None > > > > > > > > *Will this feature be supported on > > all six Blink platforms (Windows, > > Mac, Linux, Chrome OS, Android, and > > Android WebView)?* > > Yes > > > > > > > > *OWP launch tracking bug* > > Will be using this as reference bug: > > > https://bugs.chromium.org/p/chromium/issues/detail?id=630597 < > https://bugs.chromium.org/p/chromium/issues/detail?id=630597> > > > > > > > > *Entry on the feature dashboard* > > No > > > > > > > > *Requesting approval to ship?* > > Yes > > > > > > > > Thanks & Regards, > > > > Sunil > > > > -- > > > > 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. > > > > > > > > -- > > 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+unsubscr...@chromium.org > > <mailto:blink-dev+unsubscr...@chromium.org>. > > To view this discussion on the web visit > > > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/116914db-f380-4590-abbc-5930a8ee77ccn%40chromium.org > < > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/116914db-f380-4590-abbc-5930a8ee77ccn%40chromium.org?utm_medium=email&utm_source=footer > >. > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvsTVsWvrhJy%3Dtu6FsPbVx-vqX%3DQC%3DdrfJ9uq%3DzK__4uwg%40mail.gmail.com.
