which sdk version does apps have to target, N or O?

this is not known since we cannot talk about android release dates here.

O is the safe version.

I'll disable the feature in  issue 618518 , so this is no longer blocking.

Would it make sense to enable just 4-digit colors?
Also, does this affect RGBA() format at all (e.g rgba(255, 255, 255, 1.0)?

Talked with Eddy, she said this might make sense for style-dev to own while Noel is out.  Assigning to her for further routing / triage.

Unassigning since I'm not currently working on this

Alright, should this be put on someone's TODO list?

Probably. Hey Rick - Perhaps this should go on one of the WebView people's queues?

Here's the main place where we configure web settings quirks based on target SDK version. Either someone can write a patch that plumbs this down to wherever it needs to go for this feature (and then we'll take care of making sure it gets documented in the release notes), or you can tell us where it needs to go and we can try to get to it.
https://cs.chromium.org/chromium/src/android_webview/glue/java/src/com/android/webview/chromium/WebViewChromium.java?rcl=0&l=172

The one thing that's tricky is that it needs to test against the *next* android release, whose SDK level is not yet set. I think we're currently planning to add a utility function for this to make it easier; I'll ping people and report back.

torne: This is controlled today via the CSSHexAlphaColorEnabled RuntimeEnabledFeature.  So the quirk should probably boil down to calling RuntimeEnabledFeatures::setCSSHexAlphaColorEnabled(false) when targetting an older SDK (but never explicitly setting it to true - leave that to blink to decide).

There's other places in content where we have Android-specific settings for RuntimeEnabledFeatures, eg: https://cs.chromium.org/chromium/src/content/child/runtime_features.cc?type=cs&sq=package:chromium&rcl=1480681004&l=299

But I don't see any existing plumbing from the above WebViewChromium into RuntimeEnabledFeatures.

So either we should:

1) Add some new plumbing from WebViewChromium down to WebRuntimeFeatures (plus the tiny bit of missing plumbing from WebRuntimeFeatures to RuntimeEnabledFeatures).  I think there'd be some Java work to this, so would probably be best for you guys to drive.

OR

2) Add a new WebSetting (like the other quirks) that can disable support for this feature (independent of the RuntimeEnabledFeature - which we'd remove after shipping).  That would mostly be blink work, so should probably go to meade@'s style team.

I don't have a strong opinion of which is best.  Perhaps the latter is most consistent with what we're doing already (though I haven't looked exhaustively)  WDYT?  aelias?

I somewhat prefer approach 1) I think.  That will make for simpler code in the short term, and there is no particular reason to prefer WebSettings plumbing for targetSdkVersion quirks.  They fit the WebRuntimeFeatures "gradual release" idea fairly well and it may well become the new pattern to use indefinitely-maintained WebRuntimeFeatures for new targetSdkVersion quirks in the future.

Looks like WebView team is next to take action here, removing Blink>CSS.

ping

looks like we missed the window for O :/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f311a84728272e30979432e8474089b3db3c67df

commit f311a84728272e30979432e8474089b3db3c67df
Author: Noel Gordon <noel@chromium.org>
Date: Thu Jul 27 00:10:07 2017

[CSS4] Accept 8 (#RRGGBBAA) and 4 (#RGBA) value hex colors

Move this CSS feature from experimental back to stable under the
prior Blink intent-to-ship [1] ( bug 76362 ) and re-ship (M62).

Block this feature on the Android WebView however (due to chrome
 bug 618472 ) using a AwSettings.java quirk. Also add

  setCSSHexAlphaColorEnabled(boolean enabled)

to AwSettings.java which WebViewChromium.java could call once the
TargetSdkVersion to use for this WebView quirk is known.

Add an AwSettingsTest.java test to test that support for this CSS
feature is off by default in the Android WebView.

Covered by existing tests: see  crbug.com/76362#c29 

[1] http://bit.ly/1q94VPR

Bug:  76362 ,  618472 
Change-Id: Ibe52f5fdef77ae331be1eb95bfb9751eb197fc23
Reviewed-on: https://chromium-review.googlesource.com/560926
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Richard Coles <torne@chromium.org>
Reviewed-by: Bo Liu <boliu@chromium.org>
Reviewed-by: Rick Byers <rbyers@chromium.org>
Reviewed-by: Alan Cutter <alancutter@chromium.org>
Reviewed-by: Sam McNally <sammc@chromium.org>
Commit-Queue: Noel Gordon <noel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#489808}
[modify] https://crrev.com/f311a84728272e30979432e8474089b3db3c67df/android_webview/browser/aw_settings.cc
[modify] https://crrev.com/f311a84728272e30979432e8474089b3db3c67df/android_webview/java/src/org/chromium/android_webview/AwSettings.java
[modify] https://crrev.com/f311a84728272e30979432e8474089b3db3c67df/android_webview/javatests/src/org/chromium/android_webview/test/AwSettingsTest.java
[modify] https://crrev.com/f311a84728272e30979432e8474089b3db3c67df/content/public/common/common_param_traits_macros.h
[modify] https://crrev.com/f311a84728272e30979432e8474089b3db3c67df/content/public/common/web_preferences.cc
[modify] https://crrev.com/f311a84728272e30979432e8474089b3db3c67df/content/public/common/web_preferences.h
[modify] https://crrev.com/f311a84728272e30979432e8474089b3db3c67df/content/renderer/render_view_impl.cc
[modify] https://crrev.com/f311a84728272e30979432e8474089b3db3c67df/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5
[modify] https://crrev.com/f311a84728272e30979432e8474089b3db3c67df/third_party/WebKit/Source/platform/exported/WebRuntimeFeatures.cpp
[modify] https://crrev.com/f311a84728272e30979432e8474089b3db3c67df/third_party/WebKit/public/platform/WebRuntimeFeatures.h

M-62 is Beta channel now.  Quirk active for Android WebView, and I was about to mark fixed but...

Android-ilian's, who's gonna unquirk it some day :)  IIRC torne@ offered to when reviewing #18,  so do you want to take this bug as a reminder?

Sure, I'll take it. Sorry we missed this for O; we'll get this sorted for the next release (we've had various discussions about how to deal with API levels better now).

Sounds good, we'll get there, and thanks for your help with this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e3526f77d76ab1277059880b3cc472ea25d64fe7

commit e3526f77d76ab1277059880b3cc472ea25d64fe7
Author: Tobias Sargeant <tobiasjs@google.com>
Date: Mon Dec 04 16:26:02 2017

Enable CSS hex alpha and scrollTopLeftInterop based on P targetting

Bug:  618472 , 790008 
Change-Id: I663d380d14c927890a0863f4cb3158c2db1be408
Reviewed-on: https://chromium-review.googlesource.com/801017
Reviewed-by: Richard Coles <torne@chromium.org>
Commit-Queue: Tobias Sargeant <tobiasjs@chromium.org>
Cr-Commit-Position: refs/heads/master@{#521360}
[modify] https://crrev.com/e3526f77d76ab1277059880b3cc472ea25d64fe7/android_webview/glue/java/src/com/android/webview/chromium/WebViewChromium.java
[modify] https://crrev.com/e3526f77d76ab1277059880b3cc472ea25d64fe7/android_webview/javatests/src/org/chromium/android_webview/test/AwSettingsTest.java

So CSS hex alpha in WebView is now working from Android P onwards?  Can we close here?

Yup, sorry, Toby probably didn't notice this as he's not CCed on the bug. Any app that *targets* P or later in its manifest can use 8-digit CSS colors, even if it's running on an earlier OS version.