Test case: https://jsfiddle.net/gpmkojL7/

I see similar behavior on Chrome version 56.0.2924.87 and 57.0.2987.98 and I see similar behavior on Windows(7 and 10) and linux as well.

Tested the issue on Windows-7, Mac-10.12.2 and Linux Ubuntu-14.04 using chrome versions 56.0.2924.87, 57.0.2987.98 and canary 59.0.3040.0 with the Test case https://jsfiddle.net/gpmkojL7/.

Please find the attached screen cast and let us know the expected behavior to provide the bisect.

Thanks..

Deleted: 700445.mov 3.7 MB

700445.mov 3.7 MB Download

It works for data URIs, with and without quotes.

There is a companion bug here, in that the following is interpreted as valid (computed value: none) even though Chrome doesn't support image-set.

background-image: image-set(var(--1x) 1x, var(--2x) 2x);

It seems the parser needs quite some work.

That it accepts property names like --1x is another bug, as they can't begin with numbers. (The bug from the previous comment also occurs with legal names.)

Re comment #6:
I believe --1x is a valid custom property name. The reasoning that it shouldn't be valid because identifier tokens don't start with digits doesn't hold here because it starts with -, not 1.
See spec: https://drafts.csswg.org/css-variables/#defining-variables

Re comment #5:
Using var() in a property declaration defers parse validation until the var() can be resolved. To illustrate this; Firefox accepts "background-image: pics-of-dogs(var(--dog-count));" as valid at parse time.

I think the variable resolution parsing context doesn't have enough information about the base URL.

In the var() version the value returned from CSSImageValue::ValueWithURLMadeAbsolute() serialises as url("") instead of url("https://fiddle.jshell.net/gpmkojL7/show/image.png").

Probably the same as  bug 618165 

(#7)

You're right, it's valid. The updated diagram addresses this.

https://drafts.csswg.org/css-syntax-3/#ident-token-diagram

As per the old diagram it wasn't.

https://www.w3.org/TR/css-syntax-3/#ident-token-diagram

(#8)

An actual use case I have.

--x1: url(data:image/png;base64,<PNG>);
--x2: url(data:image/png;base64,<PNG>);
background-image: var(--x1);
background-image: -webkit-image-set(var(--x1) 1x, var(--x2) 2x);
background-image: image-set(var(--x1) 1x, var(--x2) 2x);

Now Chrome does not support image-set yet, nor does any browser I think, but you could still define it that way in an attempt to be forward-compatible for when browsers do. Except that this declaration breaks background-image which I think it shouldn't. (I could be wrong.)

Re #13:
Thanks for raising that point, I filed an issue on the spec: https://github.com/w3c/csswg-drafts/issues/1348
Please take any further discussion there, this bug is just for the -webkit-image-set failure.

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

commit a3079e2f1ea9974caebcdebd00c1c33dbaa662e0
Author: alancutter <alancutter@chromium.org>
Date: Fri May 12 03:18:14 2017

Ensure original parser context is used when parsing resolved var() references

When resolving var() references at style building time we were not
using the CSSParserContext specific to where the var() came from.
This resulted in relative url()s not being able to resolve to an appropriate
absolute URL based on the source base URL.

This change attaches CSSParserContexts to var() references so they can be
used at style resolution time and appropriately resolve relative URLs.

BUG= 700445 

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

[add] https://crrev.com/a3079e2f1ea9974caebcdebd00c1c33dbaa662e0/third_party/WebKit/LayoutTests/fast/css/resources/image-url-var.css
[add] https://crrev.com/a3079e2f1ea9974caebcdebd00c1c33dbaa662e0/third_party/WebKit/LayoutTests/fast/css/variables/computed-image-url.html
[add] https://crrev.com/a3079e2f1ea9974caebcdebd00c1c33dbaa662e0/third_party/WebKit/LayoutTests/fast/css/variables/computed-stylesheet-image-url.html
[modify] https://crrev.com/a3079e2f1ea9974caebcdebd00c1c33dbaa662e0/third_party/WebKit/Source/core/css/CSSSyntaxDescriptor.cpp
[modify] https://crrev.com/a3079e2f1ea9974caebcdebd00c1c33dbaa662e0/third_party/WebKit/Source/core/css/CSSVariableReferenceValue.cpp
[modify] https://crrev.com/a3079e2f1ea9974caebcdebd00c1c33dbaa662e0/third_party/WebKit/Source/core/css/CSSVariableReferenceValue.h
[modify] https://crrev.com/a3079e2f1ea9974caebcdebd00c1c33dbaa662e0/third_party/WebKit/Source/core/css/cssom/CSSUnparsedValue.cpp
[modify] https://crrev.com/a3079e2f1ea9974caebcdebd00c1c33dbaa662e0/third_party/WebKit/Source/core/css/parser/CSSPropertyParser.cpp
[modify] https://crrev.com/a3079e2f1ea9974caebcdebd00c1c33dbaa662e0/third_party/WebKit/Source/core/css/parser/CSSVariableParser.cpp
[modify] https://crrev.com/a3079e2f1ea9974caebcdebd00c1c33dbaa662e0/third_party/WebKit/Source/core/css/parser/CSSVariableParser.h
[modify] https://crrev.com/a3079e2f1ea9974caebcdebd00c1c33dbaa662e0/third_party/WebKit/Source/core/css/resolver/CSSVariableResolver.cpp