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

Laurens Holst wrote:
> 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".

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

> They swap when the user clicks a button in a picture viewer, or when the user hovers 
> over something.

That also happens, but clearly the performance is less of an issue here.

> By the way, blitting a bitmap still seems a much slower operation than 
> calling a function recursively a dozen or so times.

Not necessarily: blitting a bitmap can be much better optimized to only happen 
as often as needed for smooth operation from the POV of the user (e.g. put the 
paint off on an event), while the base URI stuff has to happen as often as the 
script asks for it.  In practice, UAs "drop frames" in a lot of existing DHTML 
animations...

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

> Well, if you think it’s acceptable for html:base :). It’s a pragmatic 
> solution, I admit, but if that’s the only thing that works for browser 
> vendors then it’s better than no solution

I'm not convinced that's true.  I wouldn't say that html:base _works_ for 
browser vendors.  More that they suffer it because they need to for compat with 
existing content...  Implementing it compatibly is really quite a bit of a pain.

> By the way, are there really any sites that depend on the current 
> behaviour that when <base>’s href attribute is changed, the images don’t 
> change?

No idea.  ;)

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

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

> Unless you have a proposal for how to implement xml:base-like 
> functionality without any performance impact?

I don't, yet.  I admit that it's very tempting functionality, but the xml:base 
setup is a _huge_ pain currently.  We need to think of something better.

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

Huh?  Testcase?

-Boris

Received on Tuesday, 5 June 2007 15:37:20 UTC