[whatwg] Issues concerning the <base> element and xml:base
jonas at sicking.cc
Sat Mar 1 04:29:41 PST 2008
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=""?
>> 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
More information about the whatwg