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/CAL5BFfWunc0EAk80KpKC-4X69fjzHznhhpxwm52o0_nUh8E97A%40mail.gmail.com.
