Able to repro this issue on Windows 7, MAC (10.11.5) & Ubuntu (14.04) for Google Chrome Stable Version - 51.0.2704.84

This is a Non-Regression issue existing from M49 - # 49.0.2610.0 

Before this build the error value isn't displayed.

> CSS.escape("0000ee")
"\30 000ee"

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/parser/CSSParserToken.cpp?l=220-221

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

 Issue 621418  has been merged into this issue.

Per the comment, were we trying to maintain compatibility with the previous implementation, other browsers, or something else entirely?

This behavior is pretty surprising and doesn't allow the color picker in devtools to adjust these values.

This gets worse.

'M20.8' serializes as 'M200.8'

It appears that the only requirement from the spec is that the serialized value roundtrips. Firefox does a much better job of preserving the original property value.

Why is this P1?

It's a pretty major interop issue in a new feature. We should figure out what to do before usage increases. It's also trivially easy to run into when using custom paint.

fwiw Safari also behaves differently

> $0.style.cssText = '--foo: #0000ee'
< "--foo: #0000ee" = $2
> $0.style.cssText 
< "--foo: rgb(0, 0, 238);" = $3

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

commit 7b65d1f3c241e1e5fe2d06b8fc272dc86c1ff44f
Author: ramya.v <ramya.v@samsung.com>
Date: Fri Jun 24 06:55:54 2016

CSS Variable #0000ee is read as #\30 000ee

Handled HashTokenTypes seperately.

BUG= 617694 

Review-Url: https://codereview.chromium.org/2080723003
Cr-Commit-Position: refs/heads/master@{#401828}

[modify] https://crrev.com/7b65d1f3c241e1e5fe2d06b8fc272dc86c1ff44f/third_party/WebKit/LayoutTests/fast/css/variables/computed-style.html
[modify] https://crrev.com/7b65d1f3c241e1e5fe2d06b8fc272dc86c1ff44f/third_party/WebKit/Source/core/css/CSSMarkup.cpp
[modify] https://crrev.com/7b65d1f3c241e1e5fe2d06b8fc272dc86c1ff44f/third_party/WebKit/Source/core/css/CSSMarkup.h
[modify] https://crrev.com/7b65d1f3c241e1e5fe2d06b8fc272dc86c1ff44f/third_party/WebKit/Source/core/css/parser/CSSParserToken.cpp

This issue is Pri-1 but has already been moved once. Lowering the priority and moving to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Should be fixed by #13

 Issue 617514  has been merged into this issue.

Wasn't this only fixed for color?

The bug report is for "CSS variable, #30000ee is read as #\30 000ee" though.

That's just a symptom of the larger problem. eg. comment #8. We're not interoperable with the implementation in Firefox.

 Issue 631024  has been merged into this issue.

I can't get the example in comment #8 reproducing? What I get here is:

$0.style.cssText = "--foo: 'M20.8'"
"--foo: 'M20.8'"
$0.style.cssText 
"--foo: "M20.8";"

Where does this still fail with variables?

eg.

element.style.setProperty('--a', 'M20.8')
element.style.getPropertyValue('--a') -> 'M200.8'

I forked off the part about making this match exactly into a separate bug 661854