Intent to Implement and Ship: Unprefixed -webkit-image-set

[Sunil Ratnu]

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

[Elliott Sprehn]

Is our implementation compatible with Safari? Is there a test suite?

[PhistucK]

Edge shows positive signs - https://developer.microsoft.com/en-us/microsoft-edge/platform/status/cssimageset?filter=f3f0000bf&search=image-set.

☆PhistucK

--
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+unsubscribe@chromium.org.

[John Mellor]

The CSS image-set spec is old, and has a major todo: it only supports variations in screen density (1x, 2x, etc), but doesn't yet allow for selecting images based on viewport width like the more modern <img> srcset+sizes attributes. Media queries aren't sufficient for this (though they nicely handle the art direction use case, so CSS won't additionally need an equivalent to the <picture> and <source> elements).

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.

[Philip Jägenstedt]

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.

[Chris Harrelson]

LGTM2

--

[PhistucK]

It has come to my attention in comment 5 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

[Dru Knox]

Is this blocked on API owner feedback?

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[dgla...@google.com]

LGTM3 + investigate the syntax issue mentioned by PhistucK.

:DG<

[Traian Captan]

Hi,

This issue has been bugging devs since 2016.

I'm landing a patch 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 

As a follow up, I will investigate whether we can fix the remaining compat issues.

Regards,

Traian

[一丝]

Does the current implementation of Chrome support nesting? I think nesting should be disabled. See: https://github.com/w3c/csswg-drafts/issues/7662

以上

一丝

Traian Captan <tca...@chromium.org> 于2022年12月1日周四 07:59写道：

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.

[Manuel Rego Casasnovas]

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+...@chromium.org

> <mailto:blink-dev+...@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>.

[Noam Rosenthal]

On Thu, Dec 1, 2022 at 1:59 AM Traian Captan <tca...@chromium.org> wrote:

Hi,

This issue has been bugging devs since 2016.

I'm landing a patch 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 

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.

 

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.

[Traian Captan]

Hi,

I tested it out and Chrome does not currently support nesting.

Same for Safari, however Firefox does seem to support nesting.

Regards,
Traian

[Traian Captan]

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

[Yoav Weiss]

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! :)

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.

[Traian Captan]

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

[Traian Captan]

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, 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

[Manuel Rego Casasnovas]

Given the answer, I agree with Yoav that it'd be better to forget about
this thread and start a new one when things are ready to ship.

Thanks,
Rego

On 02/12/2022 22:09, Traian Captan wrote:
> 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
> <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 <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).

> <https://wpt.fyi/results/css/css-images/image-set/image-set-parsing.html?label=master&label=experimental&aligned&view=subtest&q=image-set-parsing <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
> <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

> <mailto: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

> >             <chri...@chromium.org <mailto:chri...@chromium.org>>

> wrote:
> >
> >                 LGTM2
> >
> >                 On Fri, Aug 12, 2016 at 1:11 PM, Philip Jägenstedt

> >                 <foo...@chromium.org <mailto:foo...@chromium.org>>

> <mailto: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
> <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 <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 <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 <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 <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

> <mailto: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> <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

> <mailto: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

> <mailto:sunil...@samsung.com>> wrote:
> >
> >                                     *Contact emails
> >                                     *sunil...@samsung.com

> <mailto:sunil...@samsung.com>

> <mailto:blink-dev%2B...@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+...@chromium.org

> <mailto:blink-dev%2Bunsu...@chromium.org>
> > <mailto:blink-dev+...@chromium.org
> <mailto:blink-dev%2Bunsu...@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> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/116914db-f380-4590-abbc-5930a8ee77ccn%40chromium.org?utm_medium=email&utm_source=footer <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/116914db-f380-4590-abbc-5930a8ee77ccn%40chromium.org?utm_medium=email&utm_source=footer>>.
>