Amphtml: "background-image" CSS URLs unexpectedly rewritten

[SethBuilder]

What's the issue?

It's not possible to use background-image as inline CSS.

Briefly describe the bug/feature request.

According to #14072 inline CSS is now enabled on AMP.

However, in my case I use amp-list to generate dynamic content based on user interactions... this is an example of a dynamically generated background-image:
<div role="div" tabindex="@{{id}}" on="tap:share-dropup-1.hide" id="grid-1" class="grid-1" style='background-image:url(@{{inspiration.inspiration}});'>

where @{{inspiration.inspiration}} is returned from an API that I specify inside the srcof amp-list.

How do we reproduce the issue?

1. Step 1 to reproduce

Navigate to envago.io and inspect the background-image of any of the grid cells that contain an image (not video as videos work fine). You'll notice that what I code as @{{inspiration.inspiration}} translates into an AWS CloudFront link. So far so good.

2. Step 2 to reproduce

Google the word "envago" on Google Search (from a mobile device or the DevTools mobile emulator). And inspect background-image again. You'll notice that what should have been a CloudFront URL is now this:

background-image:url('https://envago-io.cdn.ampproject.org/i/s/envago.io/%7B%7Binspiration.inspiration%7D%7D');

What browsers are affected?

All browsers? Some specific browser? What device type?
Chrome on mobile (Nokia 8) version 70.0.3538.80

Which AMP version is affected?

Version 1811202351440

Is this a new issue? Or was it always broken? Paste your AMP version. You can find it in the browser dev tools.
It was always broken as far as I know.

[jpettitt]

~Only data urls are supported in CSS for AMP. I don't think what you are trying to do will work and this is "works as intended"~, Never mind - I was operating on incorrect info, url() should work.

I've tagged it bug for now until we confirm that.

[Gregable]

See choumx's referenced issue for more updates.

The short version is this was an implementation mistake when we implemented the style URL rewriting in the AMP Cache. Fixing it is easy, but there could be documents that rely on this behavior.

If someone uses: background-image:url('relative-url.png') then the cache currently fixes a bug in their template code by making this an absolute, cached, url.

However, the inverse is that if you use background-image:url(@{{inspiration.inspiration}}), that's technically a legal relative URL, and so the cache rewrites it.

So, @choumx is going to investigate how many documents might rely on this, and then we will figure out a timeline for fixing this.

[Gregable]

I haven't confirmed this works, but I think a hacky workaround for the time being would be to add a mustache variable that encompasses the "url" part of the string, so rather than:

style='background-image:url(@{{inspiration.inspiration}});'>

Use

style='background-image:{{inspiration.inspiration}};'>

And then set inspiration.inspiration to be url(http://example.com/) or what not. If the cache doesn't see the 'url()' CSS function, it will not attempt to rewrite.

Let me know if that doesn't work as a quick workaround while we sort this out and I'll come up with something else.

[jridgewell]

I don't think there's anything we can do on our (Runtime) end. Should we close this for https://github.com/ampproject/amphtml/issues/19479?

[choumx]

Well, this fell off the radar. For runtime, there's the small matter of adding some instrumentation (e.g. dev().error) to get some data on the number of impacted pages. That can be tracked as part of the I2I though.

[jridgewell]

I don't understand how we'd do that? How do we detect that an img has been broken by Cache's rewritting, and it's not just some 404?

[choumx]

Look for mustache variable markers in the style attribute of templates and output a warning/log an error.