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

Boris Zbarsky schreef:
>> Of course an O(log n) operation is going to be slower than an O(1) 
>> operation. However, is the impact significant enough to ever be 
>> noticed by the user? I mean, in what scenarios do images swap?
>
> The one _I_ run into it the most it is browser benchmarks which are 
> then widely published as "speed comparisons".

So you think widely published bogus speed comparison benchmarks are more 
important than making the web better?

> The second-most common (trailing very little) is DHTML-based games 
> where images swap on every time-step depending on what else is going 
> on in the game.  So every 10ms, ideally.  Often for thousands of 
> images (every single sprite, etc).

Meh, thousands of images swapping 100 times per second? Seems a bit 
excessive, the human eye can’t even follow that.

>> In fact, contrary to what I thought earlier, this already seems to be 
>> implemented in Firefox.
>
> Not for HTML.  We implement all sorts of slow things for content 
> that's not really used.  Optimizing it is just much lower priority, 
> and in practice people don't push its boundaries as much.

Fact is, if you want to do document includes like xi:include, if you 
don’t have xml:base-functionality, you get messy results because then 
images and links are not relative to the included document, but to the 
main document instead. Kind of like moving stylesheets from their own 
file to inline in a <style> block in HTML suddenly has you changing all 
the image paths because they don’t work anymore.

If you want to create any kind of modular system like including a menu 
into all your pages, or some template, then those modules either have to 
use absolute URLs or programmatically fix the location in all image 
references. We’ve had this situation with Backbase for years, and I’m 
very very glad that we now implement xml:base and got rid of that mess.

So in my opinion this is more valuable to support than some DOM-based 
game which calls functions much more often than it reasonably has to. I 
think O(log n) (or less) is pretty decent.

>>> It doesn't, since the base URI is stored on the document.
>>
>> No, this is also true when xml:base is used. So it can’t be that it’s 
>> stored on the document.
>
> It's looked up recursively for non-HTML, just grabbed off the document 
> for HTML.

Yeah, my mistake.

>> Well, that is assuming that you let the images re-evaluate.
>
> No.  As I said earlier, xml:base also slows down any DOM mutations 
> involving images (moving them in the DOM).

Not if you do not let the images re-evaluate, which is what I’m saying.

I absolutely understand that if you do that, it means slow extra checks 
on move operations, probably to the point that it creates an excessive 
degradation in performance.

>> However, re-setting an image’s URL does not result in the new baseURI 
>> being used
>
> Huh?  Testcase?

Attached (together with the HTML one). At first, image loads as 
expected. Then click the button ‘click to remove xml:base’, which makes 
it relative to the file system or whereever you put this. Hover over the 
link and click the ‘click to alert baseURI’ button to confirm this. 
Finally, click the ‘click to re-set the image's SRC attribute’ button to 
try re-setting the image src, and the old image remains, even though I 
have a different image on the images/sitelogo.png path locally.

When the URL is different from the original one, it does use the new 
baseURI. Setting it back to the original one again doesn’t load the new 
image.


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