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

On 3 Jun 2007, at 21:22, Boris Zbarsky wrote:
> Laurens Holst wrote:
>> 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...
>
> 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.
>
>> 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.

Did a quick test. Safari does respond, Firefox doesn't.

Anyway, as far as I can see, the spec currently requires UA's to  
respond to such changes. I can see how <base> is cheaper than  
xml:base because of problems related to reordering of nodes in the  
DOM tree. But, apart from that, won't we have excactly the same  
problems with the current <base> element?

Furthermore xml:base seems to be a "normative part" of the spec  
already. Does this mean that we have a base attribute? - at least in  
the XML serialization

And finally: Why must the <base> element occur only "In a head  
element, after the meta element with the charset attribute, if any,  
but before any other elements"? Does the sequencing of the elements  
in <head> really matter?

--
Henrik Dvergsdal

Received on Sunday, 3 June 2007 23:33:41 UTC