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

Boris Zbarsky schreef:
>> This is very fast O(log n) worst-time, and often faster. And you 
>> don’t need to evaluate it very often.
>
> It needs to be either evaluated every time someone sets .src on an 
> image or cached on images.  The first way makes an O(1) operation 
> (image swapping) O(log N), while the second one makes the memory usage 
> much bigger.
>
> Not to mention all the other elements that use URI attributes...

I don’t think this is really a big deal. O(1) is obviously better than 
O(log n), but O(log n) is still fast. And how recursively looking up 
some value would make memory usage ‘much bigger’ I don’t know. It’s just 
a few more things on the stack, that’s all?

Also, in your case of image swapping, there is network overhead for 
retrieving the new image. This way outweighs the insignificant extra 
time it takes to perform the O(log n) operation for resolving the baseURI.

> Note that none of this involved _modifying_ xml:base attributes.  When 
> that happens, things are really bad.  But even their mere existence 
> makes modification of other attributes and moving of nodes in the DOM 
> more expensive.

I talked about this with Anne van Kesteren in a private conversation, 
and what I concluded was:

* Nowhere is it specified that this should actually happen. *

The DOM 3 Core specification ONLY states that the baseURI property has 
to be dynamic. That is, it should use a getter and implement the method 
I mentioned before. However, DOM 3 Core nor DOM 2 HTML nor XML Base 
specify anything about whether HTML elements that use baseURI should 
re-evaluate their URI values (like src, href) when the base URI changes.

This is in fact how we’ve implemented baseURI in Backbase about a year 
ago (and do consider that Backbase is implemented in Javascript, not 
C++!), and it doesn’t seem that this is causing us performance problems 
of any kind. We decided not to do any kind of dynamic updates to 
elements like <img> because not implementing a complex system through 
events to handle those updates was the easy (and fast) way out at that 
time :), and I guess I still agree with that.

In other words, I should’ve left the whole section about events and 
listeners and re-evaluation of URLs out of my original mail, because 
it’s only making things more complex where they don’t need to be.

>> Note that this handler already exists because <img> tags and such 
>> needs to respond to changes to the HTML Base element.
>
> Do they?  I don't believe UAs do that.

They don’t. It was merely an assumption that I made on what seemed 
logical, but apparantly UAs don’t do what’s logical in the case of HTML 
Base :).

I did some testing:

The current implementation of Firefox does not resolve baseURI 
dynamically. Instead, it seems baseURI is a constant which is set on 
every element while parsing. Note that contrary to your statement in 
your followup-mail to Henrik Dvergsdal’s message ("you'll note that 
Firefox doesn't implement xml:base for XHTML"), Firefox *does* support 
xml:base.

The current implementation of IE does of course not support baseURI, 
however when I modify the <base> element’s href attribute and re-set the 
test-image’s src attribute, it does reload the image relative to the new 
base URL (this does not happen in Firefox). Without re-setting the image 
path, the image is not re-evaluated.

Opera seems to behave the same way as IE.

It seems Firefox is a bit off here, and that the logical extension of IE 
and Opera’s implementation to support xml:base would go the same way as 
Backbase’s implementation.

----------

I guess Firefox’s current behaviour is that while it’s parsing, it 
creates a constant baseURI attribute for each element. According to the 
DOM 3 Core specification, it should instead implement a getter with the 
earlier mentioned recursive lookup method instead (or update the entire 
subtree when xml:base or <base> is modified and nodes are moved, but 
that doesn’t seem very efficient).

Any overhead because the retrieval operation changes from O(1) to O(log 
n) will probably not be noticable, because 1. the current method has an 
initial O(n) operation and the dynamic method has not, so that will kind 
of cancel eachother out, and 2. any overhead of O(log n) compared to 
O(1) will be insignificant because the result would be an HTTP retrieval 
operation. <a>’s href attribute will only be retrieved upon user 
interaction, so there’s also no problem there.

Finally, if you really want to you can optimise the whole baseURI 
implementation by making the getter check for a global flag which 
indicates whether "xml:base" is used anywhere. If it’s not, instead of 
returning parent.baseURI and go upwards through the tree, just directly 
return document.baseURI. This should negate any negative impact on 
existing documents that you would be afraid of.

----------

To conclude, HTML5 has an opportunity here to specify the behaviour of . 
There’s two options:

1. Not automatically reload resources when base URIs change, unless they 
are normally evaluated (e.g. <img>’s src attribute is re-set, or mouse 
clicks on or hovers over link). This is the current behaviour of IE and 
Opera, and also the simplest to implement, and probably also the fastest.

2. Automatically reloading resources when base URIs change. This would 
be the most logical behaviour, although it’s harder to implement and 
probably slow. One could argue that as changing the base URI would 
result in massive HTTP retrieval operations anyway, it’s going to be 
slow in any case. One should also wonder whether there’s really any use 
case for this.

3. Not support dynamic operations of any kind on base URIs. This is the 
current behaviour of Firefox’s.


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