Intent to Ship: Double-position gradient color stop syntax

[Florin Malita]

Contact emails

fma...@chromium.org

Explainer

https://drafts.csswg.org/css-images-4/#color-stop-syntax

Spec

https://drafts.csswg.org/css-images-4/#color-stop-syntax

While Images 4 is still a WD, CSSWG has cleared double-position color stop syntax for shipping: [1], [2].

[1] https://github.com/w3c/csswg-drafts/issues/2439

[2] https://www.w3.org/2018/03/28-css-minutes.html#item07

Summary

This is a minor extension to the current gradient color stop syntax: when two consecutive stops use the same color, the author is allowed to omit the second stop and specify two positions instead. E.g.:

green 50% 75%

instead of

green 50%, green 75%

This simplifies the definition of solid gradient spans.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

https://leaverou.github.io/conic-gradient/

Debuggability

On par with current/supported CSS gradient color stop syntax.

Risks

Interoperability and Compatibility

Compatibility risk: minimal.  Syntax extension with a supporting polyfill (see Activation below) that's been around for a while.  Both this implementation and the polyfill are spec-compliant, so no compatibility issues are expected.

Interoperability risk: low. This is a minor/backward-compatible usability improvement to existing gradient color stop syntax that has been in the draft for six years.  CSSWG has cleared the feature for shipping, and, given the minimal effort required to support, will likely be implemented by all vendors.

Edge: No signals

Firefox: No signals (https://bugzilla.mozilla.org/show_bug.cgi?id=1352643)

Safari: No signals

Web developers: Positive.

Ergonomics

Minor usability improvement to existing gradient color stop syntax.

Activation

Lea Verou's cross-platform conic-gradient polyfill (https://leaverou.github.io/conic-gradient/) includes support for double-position color stop syntax.

Is this feature fully tested by web-platform-tests?

WIP (pull request: https://github.com/w3c/web-platform-tests/pull/10274)

Entry on the feature dashboard

https://www.chromestatus.com/feature/5712111258828800

[PhistucK]

It would be great if you filed issues at the WebKit and Edge issue trackers (and tried to get some signals).

☆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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADgYMVdvtW8%2BuJgsGFHhJWMbwGcDUpHy5dgCbyiH1r1ckoFbCw%40mail.gmail.com.

[j.j.]

Firefox: No signals (https://bugzilla.mozilla.org/show_bug.cgi?id=1352643)

looks like active development now

[Emilio Cobos Álvarez]

Chromium seems to canonicalize gradients during serialization when this
flag is turned on, that is:

document.body.style.backgroundImage = "linear-gradient(black 0%, black
50%)"

I would expect this to keep serializing to:

"linear-gradient(black 0%, black 50%)"

Since it's the backwards-compatible syntax, and it's specified with the
old gradient syntax.

However when the flag is toggled on Chromium it serializes as:

"linear-gradient(black 0% 50%)"

Which is OK I guess if we deem it's acceptable to canonicalize stops and
potentially breaking old code, but is kind of unexpected, and isn't in
any spec (or tests :P) whatsoever.

Indeed most of the implementations I drafted in the Firefox bug wouldn't
a priori be compatible with this, and would serialize as specified.

I filed https://github.com/w3c/csswg-drafts/issues/2714 about this. I'd
think it'd be worth getting a resolution and tests for this before
shipping it.

-- Emilio

On 05/27/2018 06:02 AM, j.j. wrote:
>
> Firefox: *No
> signals*(_https://bugzilla.mozilla.org/show_bug.cgi?id=1352643
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1352643>_)

>
>
> looks like active development now

FWIW, a contributor is looking into it, because I suggested it as a good
Rust-hacking bug. But that doesn't mean that it gets done, necessarily.

> --
> 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/398717bf-1e90-4e5d-a164-ed7a470bc00c%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/398717bf-1e90-4e5d-a164-ed7a470bc00c%40chromium.org?utm_medium=email&utm_source=footer>.

[Florin Malita]

Thanks, I'll update the chromestatus.com feature page.

 

> --
> 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/398717bf-1e90-4e5d-a164-ed7a470bc00c%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/398717bf-1e90-4e5d-a164-ed7a470bc00c%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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e800fc37-f8f6-9a9d-13f2-cd25d21c8fd3%40mozilla.com.

[Philip Jägenstedt]

Florin, I think would Blink be the first to ship support for this new syntax, can you confirm?

On the interop risk, that is the risk that other vendors will not ship the same change, or that it takes many years and we have a non-interoperable state in the interim. (Which we don't like because web developers are routinely bitten by interop issues.)

With a small change like this, the interop risk is actually significant, since it's so easy to fall off the radar of someone. What we can do to minimize the risk:

• Share all of our tests as web-platform-tests. (parsing PR merged)
• File bugs for all engines pointing to those tests and mention which browsers already pass. Perhaps with link to https://wpt.fyi/results/css/css-images/gradient/color-stops-parsing.html (append ?label=experimental to see more)

Florin, do you believe any tests beyond parsing tests are needed here? Since it's a kind of shorthand, it should be possible to write a reftest that makes sures that the interpretation is correct as well, right?

Since https://wpt.fyi/results/css/css-images/gradient/color-stops-parsing.html?label=experimental isn't passing I took a look in cs.chromium.org and was surprised to not see an -expected.txt file. And that the test passes when run. Why is that?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADgYMVcGnd17ZNUdopyg4k-7jkvADF5So-0RDhXC26Yr%3Dcvocg%40mail.gmail.com.

[Florin Malita]

Thanks for the feedback.

On Thu, May 31, 2018 at 6:07 AM 'Philip Jägenstedt' via blink-dev <blin...@chromium.org> wrote:

Florin, I think would Blink be the first to ship support for this new syntax, can you confirm?

Correct.

 

On the interop risk, that is the risk that other vendors will not ship the same change, or that it takes many years and we have a non-interoperable state in the interim. (Which we don't like because web developers are routinely bitten by interop issues.)

With a small change like this, the interop risk is actually significant, since it's so easy to fall off the radar of someone.

Interesting point -- I had assumed this would be non-controversial exactly because it is a minor extension to existing syntax, and it would get picked up whenever vendors catch up with Images 4 -- but I see your angle.

What we can do to minimize the risk:

• Share all of our tests as web-platform-tests. (parsing PR merged)
• File bugs for all engines pointing to those tests and mention which browsers already pass. Perhaps with link to https://wpt.fyi/results/css/css-images/gradient/color-stops-parsing.html (append ?label=experimental to see more)

Florin, do you believe any tests beyond parsing tests are needed here? Since it's a kind of shorthand, it should be possible to write a reftest that makes sures that the interpretation is correct as well, right?

Agreed: I am planning to write more WPT tests, and certain aspects can definitely be verified with reftests.

I also opened bugs for WebKit & Edge, per your and PhistucK's suggestion:

https://bugs.webkit.org/show_bug.cgi?id=186154

https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/17726067/

 

Since https://wpt.fyi/results/css/css-images/gradient/color-stops-parsing.html?label=experimental isn't passing I took a look in cs.chromium.org and was surprised to not see an -expected.txt file. And that the test passes when run. Why is that?

The test is definitely expected to pass with --enable-experimental-web-platform-features.  I'm not familiar with wpt.fyi, my first guess is they are not running the Chrome tests with experimental features enabled.  Is there some way to verify?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYf9yVXAfW6V6puCeN518dHODaxWL%2B4Vn6jD5J1-7aHDmQ%40mail.gmail.com.

[Philip Jägenstedt]

On Thu, May 31, 2018 at 10:09 PM Florin Malita <fma...@chromium.org> wrote:

Thanks for the feedback.

On Thu, May 31, 2018 at 6:07 AM 'Philip Jägenstedt' via blink-dev <blin...@chromium.org> wrote:

Florin, I think would Blink be the first to ship support for this new syntax, can you confirm?

Correct.

 

On the interop risk, that is the risk that other vendors will not ship the same change, or that it takes many years and we have a non-interoperable state in the interim. (Which we don't like because web developers are routinely bitten by interop issues.)

With a small change like this, the interop risk is actually significant, since it's so easy to fall off the radar of someone.

Interesting point -- I had assumed this would be non-controversial exactly because it is a minor extension to existing syntax, and it would get picked up whenever vendors catch up with Images 4 -- but I see your angle.

What we can do to minimize the risk:

• Share all of our tests as web-platform-tests. (parsing PR merged)
• File bugs for all engines pointing to those tests and mention which browsers already pass. Perhaps with link to https://wpt.fyi/results/css/css-images/gradient/color-stops-parsing.html (append ?label=experimental to see more)

Florin, do you believe any tests beyond parsing tests are needed here? Since it's a kind of shorthand, it should be possible to write a reftest that makes sures that the interpretation is correct as well, right?

Agreed: I am planning to write more WPT tests, and certain aspects can definitely be verified with reftests.

Excellent!

 

I also opened bugs for WebKit & Edge, per your and PhistucK's suggestion:

https://bugs.webkit.org/show_bug.cgi?id=186154

https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/17726067/

 

Thank you!

 

Since https://wpt.fyi/results/css/css-images/gradient/color-stops-parsing.html?label=experimental isn't passing I took a look in cs.chromium.org and was surprised to not see an -expected.txt file. And that the test passes when run. Why is that?

The test is definitely expected to pass with --enable-experimental-web-platform-features.  I'm not familiar with wpt.fyi, my first guess is they are not running the Chrome tests with experimental features enabled.  Is there some way to verify?

I see, it's behind a flag, and Chrome Dev on wpt.fyi isn't running with --enable-experimental-web-platform-features as I thought. Confirmed locally by trying it without and without flag. I've filed https://github.com/web-platform-tests/results-collection/issues/569.

LGTM1!

[Daniel Bratell]

LGTM2  with the wpt additions

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdcwO%3DP%3DyAyjSEUqdQwQd6-dMqQt0k4uwc%3Dv2CsZObxLw%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Yoav Weiss]

Florin - was the serialization compat/spec concern raised by Emilio addressed in some way? 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zj8jmdkarbppqq%40cicero2.linkoping.osa.

[Florin Malita]

Yes, looks like it was decided to expand at parse time and always serialize the expanded form (which matches the current Chromium impl): https://github.com/w3c/csswg-drafts/issues/2714

(thanks @Emilio for clarifying this aspect)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEg2LsxKpfpi%3DRgygN07HFAmebdTD2%2B-9HheprQ%3DjcKPhg%40mail.gmail.com.

[Florin Malita]

On Thu, Jun 7, 2018 at 10:37 AM Florin Malita <fma...@chromium.org> wrote:

Yes, looks like it was decided to expand at parse time and always serialize the expanded form (which matches the current Chromium impl)

Correction:  this doesn't match the current Blink behavior (I misread the examples in GH issue).  Going to update the implementation to match the CSSWG resolution before shipping.

[Yoav Weiss]

On Thu, Jun 7, 2018 at 4:44 PM Florin Malita <fma...@chromium.org> wrote:

On Thu, Jun 7, 2018 at 10:37 AM Florin Malita <fma...@chromium.org> wrote:

Yes, looks like it was decided to expand at parse time and always serialize the expanded form (which matches the current Chromium impl)

Correction:  this doesn't match the current Blink behavior (I misread the examples in GH issue).  Going to update the implementation to match the CSSWG resolution before shipping.

Awesome! Assuming that will be accompanied by WPTs, LGTM3