Intent to Ship: Accept 8 (#RRGGBBAA) and 4 (#RGBA) value hex colors

[Noel Gordon]

Contact emails

no...@chromium.org, taba...@chromium.com

Spec

https://drafts.csswg.org/css-color/#hex-notation

Summary

Update the CSS color parser to support 8/4-digit hex color. Legacy HTML attribute color parsing, per the "rules for parsing a legacy colour value" of the HTML micro syntax (http://bit.ly/1WF2Yre), will not be changed [1].

Interoperability and Compatibility Risk

Legacy color parsing rules are maintained. Compat with Safari.

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=76362

Feature dashboard entry

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

Public support

 Firefox

  Mixed https://bugzilla.mozilla.org/show_bug.cgi?id=567283

  Some concerns about legacy HTML color attributes [1].

 Edge

  No signals

 Safari

  Positive http://trac.webkit.org/r192023

 Web Developers

  https://twitter.com/search?q=#rrggbbaa

[1] Chrome/Safari test that, fast/dom/attribute-legacy-colors.html. The test checks the HTML mirco syntax "rules for parsing a legacy colour value".

~noel

[Rick Byers]

LGTM1

[Jochen Eisinger]

lgtm2

[Dimitri Glazkov]

LGTM3

[Mike Taylor]

On 5/6/16 9:36 AM, Noel Gordon wrote:
> *Public support*
> /Firefox/

> Mixed https://bugzilla.mozilla.org/show_bug.cgi?id=567283
> Some concerns about legacy HTML color attributes [1].

FTR, this landed in moz-central a few hours ago:

<https://groups.google.com/forum/#!topic/mozilla.dev.platform/00Tq2s58GwA>

--
Mike Taylor
Web Compat, Mozilla

[Selim Gurun]

Hello,

Some concerns here. This change has caused problems with both Gmail and Inbox Android applications. Both Gmail and Inbox use Android Webview and after this change the quoted text in reply became invisible. Gmail for example were setting the color to  #89000000. 

I wonder if such breakages would be more widespread.

[Torne (Richard Coles)]

One more thing to note about this: Android resources already have 8-value hex colours, but they are #AARRGGBB and not #RRGGBBAA like this CSS feature.

I assume that 8-value colours were just not valid at all before, and so these CSS rules in gmail/inbox were being ignored?

[Ian Clelland]

On Fri, Jun 3, 2016 at 6:27 AM, Torne (Richard Coles) <to...@chromium.org> wrote:

One more thing to note about this: Android resources already have 8-value hex colours, but they are #AARRGGBB and not #RRGGBBAA like this CSS feature.

I assume that 8-value colours were just not valid at all before, and so these CSS rules in gmail/inbox were being ignored?

Oh, no, it's much weirder than that :)

See the rules for parsing a legacy colour value here:

https://html.spec.whatwg.org/multipage/infrastructure.html#colours

(Blink tests this behaviour, you can see some of the craziness in the layout test at LayoutTests/fast/dom/script-tests/attribute-legacy-colors.js)

Also:

http://stackoverflow.com/questions/8318911/why-does-html-think-chucknorris-is-a-color

[Boris Zbarsky]

On 6/3/16 9:56 AM, Ian Clelland wrote:
> See the rules for parsing a legacy colour value here:
> https://html.spec.whatwg.org/multipage/infrastructure.html#colours

This is precisely why Gecko only supports the 8-char and 4-char syntax
in CSS, not in HTML attribute values. Color parsing in CSS doesn't do
the chucknorris thing.

-Boris

[Torne (Richard Coles)]

Oh. So that sounds like it would actually have interpreted #AARRGGBB before as being #RRRGGGBBB by padding it with a 0, or something equally bizarre. So I assume it just happened to come out a reasonable colour by accident....

[Simon Pieters]

On Fri, 03 Jun 2016 03:39:22 +0200, Selim Gurun <sgu...@chromium.org>
wrote:

> Hello,
>
> Some concerns here. This change has caused problems with both Gmail and
> Inbox Android applications. Both Gmail and Inbox use Android Webview and
> after this change the quoted text in reply became invisible. Gmail for
> example were setting the color to #89000000.
> I wonder if such breakages would be more widespread.

Were these apps using these colors in an HTML presentational attribute or
in CSS?

Per spec these have different rules. Introducing 8 and 4 value hex colors
in CSS should not affect parsing of HTML colors. If it does there is a bug
in the implementation of parsing HTML colors.

--
Simon Pieters
Opera Software

[Torne (Richard Coles)]

They were using it in CSS.

[Simon Pieters]

On Wed, 08 Jun 2016 11:04:13 +0200, Torne (Richard Coles)
<to...@chromium.org> wrote:

> They were using it in CSS.

OK, thanks.

(I tested now and confirm that HTML attributes are not affected in the
implementation; <body bgcolor="#f0ff"> is yellow rather than purple.)

As for usage of 8 or 4 hex colors in CSS in the wild, I checked in
httparchive (496,446 pages):

SELECT * FROM (
SELECT page, url, REGEXP_EXTRACT(LOWER(body), r'((?:^|[\{;"\'
\t]|[a-z-]+-)color\s*:\s*#(?:[0-9a-f]{4}){1,2}(?:$|[\};"\' \t]))') AS match
FROM [httparchive:har.2016_05_15_chrome_requests_bodies]
) WHERE match != "null"

4550 results. But only 368 of these are using 8 digits. Note that the
query looks at all resources, but doesn't include CSS properties that
don't end with "color" in the name.

The results which includes URLs for each match is available here:

https://gist.github.com/zcorpan/4a5779d1c1fa0acffdac9d15f9bae6a2

cheers

[Torne (Richard Coles)]

The CSS in question here is embedded inside an Android app that uses WebView and isn't going to show up in httparchive. Since Android has supported 8-digit hex colours (with a different meaning) for much longer than the web, I would expect this mistake to be much more common in CSS embedded inside Android apps than on the public web.

[Rick Byers]

Thanks for bringing this up.  For the purposes of this "intent to ship" (and the CSS spec) I think it's really just the public web that matters.  But Android WebView issues can be an indicator of issues we might hit on the web.  Thanks for doing the httparchive search Simon!  Noel, can you spot check a subset of these to try to estimate the likely breakage?  Eg. picking 30 sites at random (or maybe 15 of the 4 digit, 15 of the 8 digit), how many are subtly broken, not broken at all, and badly broken?

Based on the result of that we can choose one of:

• ship without any additional work - rely on developers finding and fixing their bugs
• ship but do some additional outreach (blog post, devtools extension or other tool to find such bugs)
• delay shipping by a release or more and add a deprecation warning / use counter for the previously invalid colors
• abandon all hope and argue this feature should be pulled from the spec as not web compatible (based on the data / experience so far this seems very unlikely to be necessary)

As for Android WebView compat in particular, I agree that's worth worrying about but this probably isn't the forum (and I'm not the person) to debate the tradeoffs.  Noel can you file a release-blocking Chrome bug for this?  We can't have a blink change break a bunch of Android apps.  One option is to add a setting to disable support for this and set it for Android apps that were compiled against an older version of the Android SDK.  aelias@ has done this before and can provide details.  Torne, have the particular Android apps in question been updated already?  Any internal bug numbers to point to?

[Selim Gurun]

On Wed, Jun 8, 2016 at 1:56 PM, Rick Byers <rby...@chromium.org> wrote:

Thanks for bringing this up.  For the purposes of this "intent to ship" (and the CSS spec) I think it's really just the public web that matters.  But Android WebView issues can be an indicator of issues we might hit on the web.  Thanks for doing the httparchive search Simon!  Noel, can you spot check a subset of these to try to estimate the likely breakage?  Eg. picking 30 sites at random (or maybe 15 of the 4 digit, 15 of the 8 digit), how many are subtly broken, not broken at all, and badly broken?

Based on the result of that we can choose one of:

• ship without any additional work - rely on developers finding and fixing their bugs
• ship but do some additional outreach (blog post, devtools extension or other tool to find such bugs)
• delay shipping by a release or more and add a deprecation warning / use counter for the previously invalid colors
• abandon all hope and argue this feature should be pulled from the spec as not web compatible (based on the data / experience so far this seems very unlikely to be necessary)

As for Android WebView compat in particular, I agree that's worth worrying about but this probably isn't the forum (and I'm not the person) to debate the tradeoffs.  Noel can you file a release-blocking Chrome bug for this?  We can't have a blink change break a bunch of Android apps.  One option is to add a setting to disable support for this and set it for Android apps that were compiled against an older version of the Android SDK.  aelias@ has done this before and can provide details.  Torne, have the particular Android apps in question been updated already?  Any internal bug numbers to point to?

Inbox and Gmail are fixed. Internal bugs  b/28977540 and b/29104000

[Joe Medley]

Guys,

I was playing around with alpha channels. I noticed that though these don't work in Chrome 51 (as expected), the rgba() function does. There's no Chromestatus entry for it, and I can't find an intent. 

Does anyone know when Chrome started supporting this? I need to note this on MDN.

Thanks,

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

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

[Rick Byers]

rgba() has been around forever AFAIK, MDN says Chrome has supported it since 1.0.

[Alexandre Elias]

On Wed, Jun 8, 2016 at 1:56 PM, Rick Byers <rby...@chromium.org> wrote:

One option is to add a setting to disable support for this and set it for Android apps that were compiled against an older version of the Android SDK.  aelias@ has done this before and can provide details.

Thanks for looping me in.  In my opinion, it's appropriate to introduce such a quirk setting for this, and I've filed http://crbug.com/618472 to track that.

[Selim Gurun]

Yes, I think this is the right approach.

[Tab Atkins]

Yeah, that's a way-old CSS2.1 function. (Or maybe even CSS1? Dunno,
and too lazy to verify.)

[Shane Stephens]

Noel's on leave and will be for a while. Would it be appropriate to revert the shipping patch (to allow the quirk setting to go through) and wait until we can find an interim owner before attempting to proceed?

Cheers,

    -Shane

[Rick Byers]

Yeah having the quirk is release-blocking for clank, so if there's no-one prepared to jump on it now then reverting and re-landing when there's someone to drive sounds like the right thing to me.

[Mike Lawther]

sgtm.

Thanks Rick for jumping on this and disabling it (https://bugs.chromium.org/p/chromium/issues/detail?id=618518). 

>>> email to blink-dev+unsubscribe@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+unsubscribe@chromium.org.

[Simon Pieters]

On Wed, 08 Jun 2016 22:56:49 +0200, Rick Byers <rby...@chromium.org> wrote:

> Thanks for bringing this up. For the purposes of this "intent to ship"
> (and the CSS spec) I think it's really just the public web that matters.
> But Android WebView issues can be an indicator of issues we might hit on
> the web. Thanks for doing the httparchive search Simon! Noel, can you
> spot check a subset of these to try to estimate the likely breakage? Eg.
> picking 30 sites at random (or maybe 15 of the 4 digit, 15 of the 8
> digit),
> how many are subtly broken, not broken at all, and badly broken?

I did this myself, first looking at pages where the match was using 0 for
alpha, thinking that would be more likely to be badly broken. After maybe
30 or so pages I started looking at 8-digit with 00 for alpha. After
another 30 or so I just checked each page regardless of the match. I've
looked at at least 200 pages and did not find a single page that was
obviously broken (I might have missed things that were subtly broken,
though).

New approach. I checked from the top and tried to find the offending
element with devtools, if there was any, and compare with my Opera Beta
(which doesn't yet support this). Out of the first 21 pages I find 1 page
with a visual difference.

http://www.tradutor-online.nu/

The text "Anúncios" is green instead of gray.

Based on this I think it is probably OK to ship as far as Web compat goes.
But there are likely some pages that break, so it seems reasonable to blog
about this new feature and explain the issue.

[Rick Byers]

Awesome, thanks for doing the research Simon! I agree it sounds like it's probably sufficiently web compatible but does need some form of outreach.

We do need the targetSdk quirk for WebView though.  I've demoted this feature to "experimental" status until someone is found to land that patch (sorry, don't have time myself at the moment).

[Mike Taylor]

On 6/9/16 3:07 AM, Simon Pieters wrote:
> Based on this I think it is probably OK to ship as far as Web compat goes.
> But there are likely some pages that break, so it seems reasonable to blog
> about this new feature and explain the issue.

The only site we're aware of (so far...) was sfconservancy.org, but they
just fixed it.

(screenshot: https://cloudup.com/c_B6d7q0a9c)

https://github.com/webcompat/web-bugs/issues/2628

[Noel Gordon]

PSA: I added an Android WebView quirk (disable) for this [1] and re-enabled this CSS feature along with devtools support in M62 [2].  It's been active ~10 weeks on our release channels.  M62 is currently Chrome Beta channel.  Enjoy.

~noel

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=618472#c18

[2] https://bugs.chromium.org/p/chromium/issues/detail?id=76362#c55

[Selim Gurun]

we are adding Finch to WebView (no milestone set yet).

Once finished, would it make sense to enable this without quirk for 5%, 10% and monitor bugs for a while and if no bad impact enable it for all?

[Noel Gordon]

Maybe, though I'm not familiar with how we undo a WebView quirk and roll it out.  See the bug for more details about that.

~noel

--
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/CAA5teA%2BgVqGJ0A1-T_2uN1Te2JW%2Bfo8Z0LdE7YD7nghfoxCH4w%40mail.gmail.com.

[Rick Byers]

IIRC this got reverted back in 2016 precisely because we saw a number of broken Android apps.  So I think we already have that data.

Also, using Finch to control web-exposed API behavior in stable channels is generally avoided because it's very hard for developers to reason about (predictability).