Re: Do we need the restrictions on the <base> element?

Anne van Kesteren schreef:
>>>  3. Implementing something like base= dynamically costs a lot.
>>>     (As far as I know we still have issues with xml:base because of 
>>> that.)
>>
>> What are the costs?
>
> In theory you would need to reiterate over the entire subtree, 
> calcuate the new URIs and start fetching the new resources. <base> 
> doesn't have this problem, as it is only taken into account during 
> parsing. baseURI and xml:base, however, are defined in a different way. 

Implementing baseURI is very simple, just something like

   if @xml:base return @xml:base
   else return parent.baseURI

And on the document element,

   return head.base.href or documentURI or null

This is very fast O(log n) worst-time, and often faster. And you don’t 
need to evaluate it very often.

Next, for every element that uses an URI such as <img> (as opposed to 
e.g. @href which only needs to evaluate on click and on hover, and 
therefore doesn’t really need this), attach a handler for say a 
‘DOMNodeBaseModified' event to the document, which is a MutationEvent 
that is triggered when a 'xml:base' attribute is modified. This handler 
then re-evaluates the image by re-querying the @src attribute using an 
update() method or some such.

Note that this handler already exists because <img> tags and such needs 
to respond to changes to the HTML Base element.

One of the primary uses for xml:base, xi:include, automatically adds 
@xml:base, too.

But yeah, xml:base is the proper answer to the question I think. If you 
need multiple base URIs throughout your document, just use XHTML ;p. Or 
if you wish, introduce xml:base in HTML (the prefix is fixed anyway), 
but I don’t really care much about that.


~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.