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

Fri Jun 6 12:01:43 PDT 2008

Implementors, please see the question at the bottom.

On Sun, 24 Jul 2005, fantasai wrote:
>
> The xml:base attribute, unlike the xml:lang attribute, is not listed as 
> a common attribute. It's also not listed as an element-specific 
> attribute on any element. However, the prose says to use xml:base 
> instead of <base> in XML documents. Could you specify more clearly where 
> the xml:base attribute is allowed in xHTML 5?

Done.

On Sat, 3 Sep 2005, fantasai wrote:
>
> # The href content attribute, if specified, must contain a URI (or IRI).
> 
> Can the href attribute be empty?

This will be defined when I define "URI" more carefully (the answer is 
yes, as the empty string is a valid URI reference, as I understand it).

> # User agents must use the value of the href attribute on the first base
> # element in the document as the document entity's base URI
> 
> Current behavior is to use the nearest previous <base> element, be it 
> prior sibling or cousin, and this is interoperably implemented in 
> Mozilla and Opera. I think requiring that the first <base> apply to 
> previous as well as following elements is a good idea for <head>, but 
> you may need to investigate whether it is practical for <base> in 
> <body>.

IE7 does it. I recall doing a study on whether it was a big problem, and 
it seemed like while there were pages that relied on the multi-base 
support, there were also many pages that broke because of it. Mozilla goes 
through some weird contortions to support it. If we can get away with not 
doing it, I think it's worth it.

> # In a head element, before any elements that use relative URIs, and
> # only if there are no other base elements anywhere in the document.
> 
> It would be simpler to just require <base> to be before any elements 
> that use URIs period. It's easier to express, and there are no 
> invalidation surprises if one changes an absolute URI to a relative one 
> later on.

It seems we changed to this at some point already.

On Mon, 13 Mar 2006, Henri Sivonen wrote:
> 
> I just realized that if the base element has attributes other than href, 
> for example id or class, there is no way to serialize those attributes 
> in conforming XHTML5. I suggest banning attributes other than href on 
> base, so that conforming HTML5 documents can be serialized as conforming 
> XHTML5 documents without data loss. This would be consistent with the 
> prohibition of extra attributes on the charset meta.

I think that would be a confusing requirement. As far as I can tell the 
requirement you mention on meta charset is gone now.

On Sat, 1 Mar 2008, Jonas Sicking wrote:
> > 
> > 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.

I agree that it's a pretty dumb thing to do.

> 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.

There's no need to keep track of that, the listeners are just all the 
descendants. Just walk the tree notifying everyone.

> 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.

What we need, therefore, is a solution that everyone can agree on and can 
agree is implementable in a timely fashion, which still gives us 
interoperable behaviour. I'm not sure what that could be.

On Sat, 1 Mar 2008, Anne van Kesteren wrote:
> 
> Note that the new base URI would only take effect once you actually did 
> something with a potentially affected object. For instance, <img> would 
> not start loading a new image if the base URI changes. <img>.src = 
> <img>.getAttribute("src") could start loading a new resource however if 
> the base URI changed since the initial load.

Well, we'd have to define that either way.

On Sat, 1 Mar 2008, Jonas Sicking wrote:
> 
> Well, that was my intention with the initial proposal. But Hixie pointed 
> out that "did something" is a very hard thing to define. For example on 
> a <a href="...">, does the user hovering the node count? Does resizing 
> the window count? Does removing the node from the DOM and reinserting it 
> count?

Indeed.

On Sat, 1 Mar 2008, Maciej Stachowiak wrote:
> 
> I'd propose that resolution is always done against the base in effect at 
> the time the URI is resolved. So changing the base would never trigger a 
> reload short of another action.

Then we need to define "resolve".

> > For example on a <a href="...">, does the user hovering the node 
> > count?
> 
> If you display an absolute URI to the user at this time it should get 
> resolved against the current base, but since this is not a load, it 
> should get resolved again when the user clicks the link, if the base 
> changed.

What if the URL changes as you're hovering? Does the URL get resolved at 
50Hz, or does it get resolved when it is first displayed?

Same with :link vs :visited -- when do you redecide what the URL is for 
the purposes of styling? There's no clearly defined or definable time that 
this happens, as far as I can tell.

On Sat, 1 Mar 2008, L. David Baron wrote:
> 
> That means you'd need to define when every URI is resolved and how long 
> that result is cached.  That seems like a substantial amount of 
> specification and testing work.  It might interfere with lazy evaluation 
> as a performance optimization, although I suspect that's not an issue 
> for the main case since we already have to resolve all anchors in order 
> to do visited-link coloring.
> 
> It also breaks some invariants that are nice to maintain, like that 
> removing and reinserting content from a document should produce the same 
> result.  (I think this one may actually be important in practice since 
> authors sometimes use removal/reinsertion to work around bugs handling 
> dynamic changes.  Although we probably already break it in a bunch of 
> ways as well.)

I agree with these points.

On Sat, 1 Mar 2008, Maciej Stachowiak wrote:
> 
> 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.

This seems like it would have more overhead than just notifying everyone 
in the subtree.

On Sat, 1 Mar 2008, Jonas Sicking wrote:
> 
> I very much agree it's an edge case and would be fine with leaving it 
> undefined.

Well, right now it's implicitly defined that changing the base changes 
anything refering to that base instantly. I'm not really sure how to 
unspecify that without adding a really weird clause like "in the event 
that the attribute is changed, user agents may, whenever convenient, 
pretend, for the sake of url resolution, that it has not changed".

I have made notes in the spec that this is an area that needs defining. 
Right now I'm leaning towards defining a "base href change notification 
behaviour" for all elements that have URI attributes or are otherwise 
sensitive to base href changes, and defining that when the base href 
changes, all the elements in the document with such behaviour defined 
should have that behaviour activated (this would, in the simple case, just 
be a walk over the document with a virtual method call per element; it 
might be a bit slow for some documents, but then this is a very rare 
occurance anyway). We would also invoke this behaviour on the entire 
subtree of an element whenever that element is inserted into a different 
document, in case it matters in any cases.

In practice I think this only actually affects :link/:visited and url() 
rules in style="" attributes. I plan on making <img>/<iframe>/<link 
rel=stylesheet> etc not reload their content if the base href changes 
(though that does mean that .src and .href will end up pointing to URIs 
that aren't actually what was loaded). I can't think of any other cases 
that are sensitive off the top of my head, but I'll be thorough if I do 
end up specifying this.

The question is, are people ok with that plan?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'