Re: [css-values] url(#frag) handling when base url changes

On Tue, 22 Mar 2016 18:52:35 +0100, Tab Atkins Jr. <>  

> On Mon, Mar 21, 2016 at 6:23 PM, fantasai  
> <> wrote:
>> I'm.. not 100% clear on what's going on here, but, isn't this handled
>> by the fact that CSS is stateless? It's only a problem if the computed
>> value is cached over the base URL change--and that's a caching problem,
>> not a spec problem.
> CSS is not, in fact, stateless for this issue.  Style-Attr requires
> the URL to be absolutized at parse-time.  Values says URLs are
> absolutized at computed-value time.  The web platform in general is
> not consistent on whether things are "stateless" or not for base-URL
> changes; <img>, for example, does not reload (tho it does change its
> serialization of the src attribute), and this behavior is
> well-specified by HTML.
> I put together a test-case at
> <>.

Nice! I had started a simpler test at

I think nothing anywhere says to do anything in particular for CSS when  
the base URL changes, which probably means that the URLs in CSS shouldn't  
be reparsed, right?

> It starts all the images as valid - by combining <base> and their
> relative URL, you resolve to a fat pony gif on my server.  Then I
> change the base url; the results are shown in the first column.  Then
> I force a reparse of the url source by appending a space; the results
> are shown in the second column.  URL serializations are logged at all
> three states.
> Firefox and Chrome seem to agree - changing the base does *not* reload
> the image in any of the three situations.  The serialized absolute url
> changes for <img>, but not for the two CSS ones.
> Edge disagrees in an odd way - for <img>, it does not reload when base
> changes, and does when it reparses the src attribute, same as
> Firefox/Chrome.  For inline style, it reloads both times.  For
> stylesheets, it doesn't reload either time. (I suspect that the
> stylesheet case might have more aggressive "this is the same string,
> just ignore the attempted set" logic?)
>> Though possibly worth pointing out in a note.
>> Wrt perf concerns, I somehow doubt there are enough computed URLs and
>> enough frequency of the document base URL changing for updating said
>> cache to be a huge problem.
> Jonas seems to disagree in the Moz bug.  In particular, pushState()
> would require re-resolving every URL on the page, and that *is* used
> fairly commonly on some sites.

This is defined at  
for HTML, and it's basically only active UI that should be updated,  
nothing else.

There's also <body background> which HTML's rendering section currently  
says to parse the URL when the attribute is set, so it doesn't respond to  
base URL changes even if CSS computed value time is after the base URL  

As is also discussed in that issue, when exactly to parse URLs is relevant  
for blob: URLs in particular, and I suppose this applies to CSS as well.

As for the original issue, I don't have a strong opinion but I would find  
(2) more surprising than (1), and I don't see why either is more magic  
than the other.

Simon Pieters
Opera Software

Received on Tuesday, 22 March 2016 18:55:49 UTC