Hi Noam, Thanks for the heads up! This patch only exposes the current `-webkit-` prefixed functionality without needing the prefix, and the parsing strictness is the same.
When I look at adding the extra functionality you mentioned I will port your test case and look out for this issue. For now, image-set without the url keyword as well as generated images will fail parsing, Chrome will fall back to the `-webkit-` prefixed version if defined and behave as it did before the patch. Regards, Traian On Thu, Dec 1, 2022 at 2:11 AM Noam Rosenthal <nrosent...@chromium.org> wrote: > > > On Thu, Dec 1, 2022 at 1:59 AM Traian Captan <tcap...@chromium.org> wrote: > >> Hi, >> >> 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. >> >> 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> >> >> Hi Traian > I implemented the same in WebKit 3 years ago, alongside other image-set > improvements. At the time there were some strange backwards-compatibility > issues, e.g. with empty strings, > where I had to keep some non-standard behavior in -webkit-image-set around > parsing : > https://trac.webkit.org/changeset/255420/webkit > > Would be good to double check that we don’t repeat the same regression ☺️ > > The other thing WebKit has since then is support for urls without the > url() keywords and also generated images in an image-set. I am curious if > we have a plan to implement that or if unprefixing without them can cause > issues. > > >> As a follow up, I will investigate whether we can fix the remaining >> compat issues. >> >> 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 >>>>> >>>>> 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 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 >>>>>>>>> . >>>>>>>>> >>>>>>>> ☆*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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *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. >> 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/CAFxahvs_3AvB12EV6Ry9OzaG-%3DHkvk2ujEm_FWC6t9MZHREP1g%40mail.gmail.com.
