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

Boris Zbarsky schreef:
>> 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.

XBL is again just one of the languages. If you’d include XBL directly 
into HTML using xi:include (possibly expanded server-side), you would 
still need xml:base. If you include SVG with external references in an 
XHTML document using xi:include, again xml:base makes that work. I don’t 
see how XBL itself would solve anything if you wouldn’t have xml:base.

In fact, I was talking about this specifically with a binding system in 
mind (the Backbase tag definition language), which is included in the 
document through xi:include, the same way any other XML is included and 
processed.

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

Well, I think you mentioned tests of your own without giving any 
specific numbers, where are those :). Making different implementations 
and comparing them in a realistic environment wouldn’t exactly be easy 
for me. But, as fortunately Firefox implements both methods, I can test 
it with existing functionality in Firefox.

Attached are 2 testcases. One for XHTML (which uses xml:base and 
recursive lookup), and one for HTML. Test results for re-setting the 
<img>’s URL 1000 times (specific numbers listead at the bottom [1]):

HTML, 1 nested div: 2019 ms
HTML, 10 nested divs: 2171 ms

XHTML, 1 nested div: 2034 ms
XHTML, 10 nested divs: 2127 ms

That’s what I mean.

First of all, no difference between HTML and XHTML, even though the 
former uses an O(1) method and the latter an O(log n) method. 
Furthermore, deeper nesting does make it a little slower, but the 
slowing is relatively insignificant and happens in both cases, so I 
wouldn’t credit this difference towards the baseURI implementation.

These results make perfect sense because, is a couple of simple "if 
(!@xml:base) return parent.baseURI;" iterations really going to make any 
noticable difference? Of course not, as long as the number of recursive 
iterations stays reasonably in check, which is the case with log n.

Binary check, method call, return value, these are some of the simplest 
operations possible. If this would matter in any significant way, then 
you’d better remove all those subroutines from all your code and replace 
them with inline macros (or whatever the term for that is).

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

Sure, I guess it’s odd, but that’s what I’ve been talking about. UAs 
already do it with <base> in HTML, and Firefox with xml:base in XHTML as 
well. As I said, if that’s the only way xml:base can be implemented 
without harming performance, then that works for me.

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

You’re right, the extension of the image that I tested with wasn’t the 
same, I overlooked that. So Firefox’s behaviour is just fine.


~Grauw

[1]
HTML, 1 div results: 2028, 2022, 2006, 2011, 2030
HTML, 10 div results: 2243, 2121, 2138, 2232, 2122
XHTML, 1 div results: 2006, 2014, 2077, 2039, 2036
XHTML, 10 div results: 2114, 2116, 2136, 2130, 2141

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