On Tue, Apr 16, 2013 at 4:57 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
> As Ian pointed out (see WHATWG IRC reference above) you don't always > want to parse synchronously as the base URL might change at a later > stage. For images, that's what you want--if the base URL changes after you assign .src, the old base should still be used. Most of the time this is what you get now with images. The only time you don't is the "images on demand" path, which I think is a bug (this would just align those two paths). If there are cases where base changes do need to be picked up after assignment, we might need a bit of a hack to deal with this. First, parse and capture the URL synchronously, as above. Then, at fetch time parse the URL again. If the resulting parsed URL is the same, use the original one, so you retain any captured blob. If the parsed URL has changed (because of a base change), discard the original parsed URL and use the new one instead. That means that if the base doesn't change (or if the URL is absolute, as with blob URLs), the captured blob data is still there. If the URL did change, it'll use the new parsed URL. This also does not work for CSS where when parsing happens is > even less defined (which might benefit projects such as Servo). > If the time CSS parses its URLs isn't defined, then I think blob URLs are fundamentally incompatible with being put into CSS. Either CSS's parse time needs to be defined, or we should disallow blob URLs in CSS. I know putting blob URLs in CSS is a major case for some people, but we can only support it if we can define it interoperably. (This applies to non-autorevoke blobs, too, I think, depending on how undefined it is.) > This would also fix https://www.w3.org/Bugs/Public/show_bug.cgi?id=21058, > > because URLs would be resolved against <base href> synchronously. > > That would make <img> behave differently from e.g. <a download>. > Pretty sure <a> needs to resolve at the point it is actually clicked. > The above hack would deal with this. -- Glenn Maynard
