Thank you Yoav! That's a good idea. I created a CL to place it behind a flag: https://chromium-review.googlesource.com/c/chromium/src/+/4075225
And I will send out a new intent. Regards, Traian On Thu, Dec 1, 2022 at 8:02 PM Yoav Weiss <yoavwe...@chromium.org> wrote: > Hey Traian, > > I'm excited about you taking on this area! At the same time, I agree with > Rego that we should not be landing patches for this without a new intent > that looks at the current compat landscape. > Can you put this behind a flag and send a new intent? Thanks! :) > > On Fri, Dec 2, 2022 at 3:48 AM Traian Captan <tcap...@chromium.org> wrote: > >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvs_3AvB12EV6Ry9OzaG-%3DHkvk2ujEm_FWC6t9MZHREP1g%40mail.gmail.com?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/CAFxahvsTM8ytRgaNjK1CZe7_JWCPUnY-thgLyyuzddXmoK77Ow%40mail.gmail.com.
