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

Mon Apr 30 23:53:18 PDT 2007

This, along with the checkin I just made, should resolve all the e-mails 
that have been sent regarding <base>. Please let me know if I missed 
anything or if you see any new issues.

On Sun, 11 Feb 2007, Geoffrey Sneddon wrote:
>
> To take this from a discussion last month on atom-syntax:
> 
> What is meant to happen if you set innerHTML of a <div> where the set 
> value has both a <base> and an <a>?

Nothing much. The base element will appear in the DOM (as a child of the 
<div>), but it will not have any effect.

On Sun, 11 Feb 2007, Geoffrey Sneddon wrote:
> 
> The point is whether it:
> 	a) Gets inserted into the <head>, and changes all the links in the
> document.
> 	b) Appears in some magic place, and changes the links in the HTML
> fragment.
> 	c) Gets ignored.

None of the above. It appears in the DOM but has no effect.

On Sun, 11 Feb 2007, Geoffrey Sneddon wrote:
> 
> Safari 2.0.4/419.3: (1) Inserted in DOM (in the innerHTML location).
> Firefox 2.0.0.1: (3) Inserted in DOM (in the innerHTML location).
> IE/Mac 5.2.3: (2) (anyway to view the DOM tree?)
> Opera 9.10: (1) DOM Snapshot for some reason isn't working.
> IE6/Win: (2) The new <base> never appears in DOM, but the full absolute URLs
> are in the DOM.
> IE7/Win: (3) The new <base> never appears in DOM, but the full absolute URLs
> are in the DOM.
> 
> In conclusion, Safari and Opera change all the links, IE5/Mac and 
> IE6/Win both change links within the fragment, and Firefox and IE7/Win 
> don't change any links.

The latter is the option I'm following for now. Note that browsers all do 
_different_ things for target="" than for href="". The spec has made them 
act the same for now. I'm not sure this is workable, we'll have to see 
when the browser vendors try to get this interoperable. I can't imagine 
that it's a huge issue given that the browsers are so far from each other 
in terms of what they do here. I'm going to do a study of some subset of 
the Web to see how common this is (at least the static case; I can't 
really do much about the scripted case).

On Fri, 2 Mar 2007, Anne van Kesteren wrote:
>
> I think <base> should also be allowed in XML documents. It simplifies 
> the language, it already needs to be supported and <base> is able to set 
> Document.baseURI where xml:base can at most set 
> Document.documentElement.baseURI. (Document.baseURI influences how 
> XMLHttpRequest works for instance.)

Done.

> The <base> element section should probably also talk about what happens 
> when you modify the .href attribute.

What more is there to say? Isn't it defined enough?

On Fri, 2 Mar 2007, Keryx Web wrote:
> 
> And today the base element already works in at least FFox and Opera also when
> content is sent as true XHTML 1.0, so this would not really change anything
> but the spec.

Indeed.

On Tue, 13 Mar 2007, Asbjørn Ulsberg wrote:
> > 
> > They don't conflict. They are both applied. <base> is the document's 
> > base URI, and xml:base is the base URI of the element it is applied 
> > on.
> 
> What about:
> 
>   <base href="http://www.example.org/" xml:base="/bar" />

The xml:base here has no effect.

On Tue, 13 Mar 2007, Adrian Sutton wrote:
> 
> I'm not entirely sure this is legal but what about (say for a document 
> on http://localhost/): <base href=".." xml:base="bar" />

On Tue, 10 Apr 2007, Jonas Sicking wrote:
> 
> Note that the current text isn't implementable since it says that 
> relative uris in <base> should be resolved against the base uri 
> document, but the <base> element modifies that base uri so there is a 
> circular dependency.

No, the <base> element sets the "document entity's base URI", and is 
resolved relative to the "base URI from the encapsulating entity" or the 
"URI used to retrieve the entity". See RFC2396.

On Wed, 14 Mar 2007, Bjoern Hoehrmann wrote:
> 
> Note that some of the suggestions made in this thread would give quite 
> surprising results e.g. when using XInclude.

You didn't elaborate on what you considered surprising, so I can't tell if 
what the spec now says also suffers from these problems. Could you let me 
know if you think the spec as written would give "surprising" results when 
using XInclude, and which results it is you consider surprising? Thanks.

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