[whatwg] Issues concerning the <base> element and xml:base

On Mar 1, 2008, at 4:29 AM, Jonas Sicking wrote:

> Ian Hickson wrote:
>> On Mon, 13 Aug 2007, Jonas Sicking wrote:
>>> Ian Hickson wrote:
>>>>> Also, if we're going to be inconsistent in how current browsers  
>>>>> and web
>>>>> pages handle multiple <base>s, why not simply use the first  
>>>>> <base> for
>>>>> both href="" and target=""?
>>>> Done.
>>> I realized another limitation. It is very hard for implementations  
>>> to 'correctly' deal with dynamic modifications to bases. Ideally  
>>> all external resources, such as <iframe>s, <img>s, css  
>>> backgrounds, <svg:use> elements and css @imports should be updated  
>>> to potentially use new URIs. This can happen when <base> elements  
>>> and xml:base attributes are inserted or mutated. So far no UA that  
>>> I know of does this, and it would be very hard to implement.
>> I completely agree with you that this is an area that is problematic.
>>> What I suggest is that we add similar language as the XBL spec  
>>> does for xmlns attributes and xbl:attr attributes. Say that  
>>> dynamic modifications are allowed, but that the implementation is  
>>> not expected to update the resolved URI unless the URI is  
>>> explicitly touched.
>> Unfortunately it's unclear when that would be. At least with  
>> xbl:attr we have a somewhat well-defined set of steps for when  
>> things happen. Here it's far less clear. For example, clicking a  
>> link is likely to reresolve the URI relative to the base URI. Maybe  
>> even hovering it might. Or maybe even just a repaint in general.
>> I'm not sure what to do here. It seems like UAs should support a  
>> notification mechanism so that when a base URI is changed, all URIs  
>> in the document (for <base>) or in that subtree (for xml:base) get  
>> reresolved. That actually seems relatively simple and has little  
>> (no) overhead in the common case of nothing being changed.
>
> Personally it's something I would be very reluctant to do. It would  
> add a whole lot of code for basically no benefit for web developers.  
> I have never heard of anyone that actually desired changing the base  
> uri for all or parts of a page dynamically.
>
> There would definitely be overhead unfortunately. First of all in  
> lots of code added to every place that resolves URIs in order to set  
> up appropriate listeners to the notification, and managing the  
> lifetime of those listeners. Second there would be memory overhead  
> in keeping around lists of who listens to what subtrees.
>
> My guess is that supporting dynamic modifications would be one of  
> those features that someone would file a bug on early on during  
> testing of a UA implementation, and then nobody would care about a  
> very long time, including both web developers and UA developers.  
> Especially given that the feature would be missing from all other UAs.
>
> But yeah, I have no real good solution either. We could either say  
> that uris MAY not be immediately updated in the face of dynamic  
> modifications. Which would probably suffer from some amout of  
> implementation differences. Or we could say MUST be immediately  
> updated and probably still suffer from implemenation differences due  
> to lack of implementation.

How about requiring that the base used is the one in effect when a  
given relative URI is resolved, and define that URIs for resource- 
loading elements are resolved at the time the relevant attribute is  
set or parsed (but for hyperlinks, at the time it is dereferenced).  
That is easy to implement, interoperable, and reasonably predictable.  
It makes sense that changing <base> would affect future loads but not  
trigger reloads of already loaded or already in progress resources.

Regards,
Maciej

Received on Saturday, 1 March 2008 17:08:50 UTC