Fix RGBA alpha parsing and serialization to adhere to W3 standard.

third_party/WebKit/Source/platform/graphics/Color.cpp

Index: third_party/WebKit/Source/platform/graphics/Color.cpp
diff --git a/third_party/WebKit/Source/platform/graphics/Color.cpp b/third_party/WebKit/Source/platform/graphics/Color.cpp
index 3ad2e4d84d59cb85ee67ae9928e4615f93b9b2ee..3b406bf1a1addf7976e8fa71e0d6b7eb4ab519bc 100644
--- a/third_party/WebKit/Source/platform/graphics/Color.cpp
+++ b/third_party/WebKit/Source/platform/graphics/Color.cpp
@@ -210,7 +210,16 @@ String Color::serializedAsCSSComponentValue() const {
   result.appendNumber(static_cast<unsigned char>(blue()));
   if (colorHasAlpha) {
     result.append(", ");
-    result.appendNumber(alpha() / 255.0f, 6);
+    // See <alphavalue> section in
+    // http://dev.w3.org/csswg/cssom/#serializing-css-values
+    int alphavalue = alpha();
+    float rounded = round(alphavalue * 100 / 255.0f) / 100;
+    if (round(rounded * 255) == alphavalue) {
+      result.appendNumber(rounded, 2);
+    } else {
+      rounded = round(alphavalue * 1000 / 255.0f) / 1000;

[sashab, 2017/01/02 23:04:16]

Is this safe against overflow? Do we need clampTo<>?

[ktyliu, 2017/01/03 02:14:22]

good question

the convention in this file seems like input values are clamped on
initialization (eg, makeRGBA) and internal members are guaranteed to be within
range

for this particular case, alpha() calls alphaChannel() internally which does "&
0xFF" and hence guarantees to return integer in range of [0, 255]

+      result.appendNumber(rounded, 3);
+    }
   }
 
   result.append(')');