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

Laurens Holst wrote:
> So you think widely published bogus speed comparison benchmarks are more 
> important than making the web better?

Of course not.  But unfortunately, they do sway people's choice of UA, soUA
implementors have to pay some attention to them.  As little as they can get away
with, typically.

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

<shrug>.  I'm not the one writing the web pages.  I'm the one trying to make a
UA render them reasonably.

> Fact is, if you want to do document includes like xi:include, if you 
> don’t have xml:base-functionality, you get messy results

Yes.  I don't think anyone is disputing that.

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

Or use a binding system of some sort (XBL, whatever), yes.

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

Unfortunately, said DOM-based games seem to be somewhat popular, based onthe
number of bug reports we get when we accidentally break one.

> I think O(log n) (or less) is pretty decent.

I keep asking to see numbers instead of qualitative statements.  I have yet to
see any.

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

So if an image is moved in the DOM it doesn't get the new URI, is what you're
saying?  But some other unrelated change (like "img.src = img.src") might make
it reload the image and suddenly get a different image?  That seems like very
odd behavior.

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

Worsk for me, if the new URI actually returns an image (if it doesn't, we leave 
the old image in place instead of showing a broken image icon).  I hope you're 
not testing this in Firefox 1.0 or anything like that, right?

-Boris

Received on Wednesday, 6 June 2007 23:46:35 UTC