Intent to Implement and Ship: Parse floats/decimals in CSS RGB and RGBA functions

[csna...@gmail.com]

Contact emails

csna...@gmail.com

Explainer

n/a

Spec

https://drafts.csswg.org/css-color/#funcdef-rgb

Summary

According to CSS Color 3, only integer values or percentages were valid inside the RGB or RGBA functions. However, with CSS Color 4, the specification notes that "the CSS syntax allows full <number>s, not just <integer>s, for authoring convenience". This change would make it so that floating point and decimal values are parsed as valid inside of the RGB or RGBA functions. However, the proposed change would not result in any behavioral change, as the values would be still truncated to integers for painting/etc.

Draft CL: https://chromium-review.googlesource.com/c/chromium/src/+/719775

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

Yes, this would be a universal feature.

Debuggability

DevTools does not currently parse floating point RGB values in the color picker, but this can easily be updated.

Risks

Interoperability and Compatibility

Edge: Shipped with consistent behavior as to what is proposed (see e.g. https://jsfiddle.net/0v82oe3r/ in Edge)

Firefox: No signals

Safari: No signals

Web developers: No signals

Ergonomics

n/a

Activation

n/a

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

No web platform tests have been created; I'm not sure if this is necessary or if existing LayoutTests are sufficient.

Entry on the feature dashboard

Small change, shouldn't result in any user-facing behavior changes

Requesting approval to ship?

Yes

[Anne van Kesteren]

On Wed, Oct 25, 2017 at 4:44 AM, <csna...@gmail.com> wrote:
> https://drafts.csswg.org/css-color/#funcdef-rgb

It doesn't seem to detail whether to use floor() or round()? Your
email suggests floor(), but the spec doesn't say as far as I can tell.
It also doesn't say what the computed value in the object model would
be.

> Edge: Shipped with consistent behavior as to what is proposed (see e.g.
> https://jsfiddle.net/0v82oe3r/ in Edge)

That doesn't really give answers to all the questions this addition raises.

> No web platform tests have been created; I'm not sure if this is necessary
> or if existing LayoutTests are sufficient.

Seems like that would be good to help determine how exactly it should
behave and ensure everyone ends up implementing that.


--
https://annevankesteren.nl/

[csna...@gmail.com]

On Wednesday, October 25, 2017 at 3:24:50 AM UTC-4, Anne van Kesteren wrote:

On Wed, Oct 25, 2017 at 4:44 AM,  <csna...@gmail.com> wrote:
> https://drafts.csswg.org/css-color/#funcdef-rgb

It doesn't seem to detail whether to use floor() or round()? Your
email suggests floor(), but the spec doesn't say as far as I can tell.
It also doesn't say what the computed value in the object model would
be.

The spec doesn't clarify this issue, but Edge appears to use floor() and this is the approach already laid out in the Blink code (floats are simply truncated to integers). It might be better to eventually pass on the floating point value to painting, but I didn't want to mess with that yet.

 

> Edge: Shipped with consistent behavior as to what is proposed (see e.g.
> https://jsfiddle.net/0v82oe3r/ in Edge)

That doesn't really give answers to all the questions this addition raises.

I can't find any visible documentation as to this from Edge, but this is the behavior that has been observed -- perhaps some clarification could be used from the Edge team.

 

> No web platform tests have been created; I'm not sure if this is necessary
> or if existing LayoutTests are sufficient.

Seems like that would be good to help determine how exactly it should
behave and ensure everyone ends up implementing that.

It looks like I spoke too soon, as e.g. https://github.com/w3c/web-platform-tests/blob/master/offscreen-canvas/fill-and-stroke-styles/2d.fillStyle.parse.css-color-4-rgb-1.html tests this issue.

[Chris Harrelson]

Hi,

Thanks for sending this intent. It looks reasonable, but let's wait until the spec is clarified (please file a bug or PR against the spec) as to the comments Anne raised, as well as comprehensive-enough web platform tests. The folks at style-dev@ can help with technical points on the latter. I believe you're already in touch with them on code review.

Chris

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aa0ec354-1301-478d-a001-6ed2f1583316%40chromium.org.

[Daniel Bratell]

csnardi, one thing you could do (apart from waiting or participating in work on clearing the spec uncertainties) is to solicit interest from other browser vendors. I believe this will eventually be fine, but Chris has a point that it might be too early to ship this change if the spec hasn't been finalized.

/Daniel

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/aa0ec354-1301-478d-a001-6ed2f1583316%40chromium.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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8xmO_5Qzzk3Zg%2Bt4RVxTgvYY88F5Cj_cEm7htR6wz4TQ%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Chris Nardi]

I created an issue for the spec [1] to try to help resolve the wording distinction. We'll see where it goes, but it appears so far that it might just be resolved as implementation-specific.

As to other browsers, I found that Firefox has a bug [2] for this change, but no progress has been made. I can't find anything for Safari.

I would note that unless my understanding of Blink/Skia code is incorrect, we currently only use 4-bit color channels for painting, so attempting to use the more precise numbers instead of simply truncating/rounding to an integer would require a rework of that entire code.

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

[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1291878

[Daniel Bratell]

It's certainly not 4 bit color channels in general, though there may be optimizations and code somewhere for when you have limited screen like some mobile phones do.

The thing that I think will matter most in the long run is whether values should be truncated or rounded. If 254.99999 ends up at 254 optimization opportunities will be lost. The current issue doesn't mention that. Also, there is the question of serialization. Should the decimal values be preserved (a bit tricky I suspect) or should it always be an integer when read.

/Daniel

[Anne van Kesteren]

On Thu, Nov 16, 2017 at 11:18 AM, Daniel Bratell <bra...@opera.com> wrote:
> It's certainly not 4 bit color channels in general, though there may be
> optimizations and code somewhere for when you have limited screen like some
> mobile phones do.
>
> The thing that I think will matter most in the long run is whether values
> should be truncated or rounded. If 254.99999 ends up at 254 optimization
> opportunities will be lost. The current issue doesn't mention that. Also,
> there is the question of serialization. Should the decimal values be
> preserved (a bit tricky I suspect) or should it always be an integer when
> read.

Indeed, I added some comments to that effect.


--
https://annevankesteren.nl/

[Philip Jägenstedt]

Chris, are you still pursuing this? I ask because I noticed recently that there are tests that are failing because of this:

https://wpt.fyi/css/css-color

It's rgb-002.html, rgb-004.html, rgb-006.html and rgb-008.html.

(I had a half-finished import of css-color sitting around, I think I'll finish it so the tests are there if you want to use them, or fix them, depending on the outcome of https://github.com/w3c/csswg-drafts/issues/1983.)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78j-32Et5xmfwfQeL82wTv%2BPQa4rTEs2px10%2BoVhPi7uyA%40mail.gmail.com.

[Chris Nardi]

I was planning on waiting to see if there was any consensus from this list/the spec bug in order to determine future direction for this. However, if I remember correctly, we also need to make it so that commas are optional in rgb/rgba in order for those tests to pass.

I could either continue to wait to determine how we want to proceed with rounding/truncating, or attempt to implement decimal-level precision for each channel. I'm not sure how this would work, as the only code I can find for making RGB values is https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/platform/graphics/Color.h which relies on 32-bit RGBA.

[Chris Nardi]

I also realized I made a typo there -- that message should have said 8-bit channels (so no decimal precision for each channel).

[Philip Jägenstedt]

On Mon, Nov 27, 2017 at 4:55 PM Chris Nardi <csna...@gmail.com> wrote:

I was planning on waiting to see if there was any consensus from this list/the spec bug in order to determine future direction for this. However, if I remember correctly, we also need to make it so that commas are optional in rgb/rgba in order for those tests to pass.

Yes, those tests unfortunately test all new syntax bits at the same time. However, they're now imported, and you can change them however is needed for them to be more useful, as long as the total test coverage isn't reduced.

FWIW, I think they could all be rewritten to use testharness.js, by using getComputedStyle, leaving perhaps just one test as a reftest. That should make them faster to run too.

[Chris Nardi]

In an update on this proposal, the spec issue was discussed and it was resolved that rounding is the correct behavior. The spec hasn't officially been changed yet, but my proposed wording had positive feedback.

Additionally, after some bugs were fixed with the web platform tests verifying this behavior, I discovered that Firefox has implemented this change and supports decimal channels. There are still some bugs in the tests, but a PR to fix those should hopefully be merged in soon. New tests should probably be added to verify the rounding behavior, but everything else should be tested already.

[Chris Nardi]

The spec has now been updated to state:

Implementations should honor the precision of the channel as authored or calculated wherever possible. If this is not possible, the channel should be rounded to the closest value at the highest precision used, rounding up if two values are equally close.

Since this resolves the main issue with the intent, any thoughts on proceeding with this proposal, changing flooring to rounding?

[Philip Jägenstedt]

If what the spec now says is possible to test for and makes sense for the reviewers of the eventual CL, then LGTM1. Thanks for your patience on this one, and thanks for improving interop :)

[Daniel Bratell]

LGTM2

/Daniel

[Rick Byers]

LGTM3

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

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