W3C home > Mailing lists > Public > public-html@w3.org > June 2007

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

From: Laurens Holst <lholst@students.cs.uu.nl>
Date: Fri, 08 Jun 2007 10:41:22 +0900
Message-ID: <4668B3C2.9090508@students.cs.uu.nl>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: "public-html@w3.org" <public-html@w3.org>
Boris Zbarsky schreef:
>>>> and Firefox with xml:base in XHTML as well.
>>>
>>> Testcase?  That's not what I see over here.
>>
>> What? You claimed this yourself, and one paragraph later in my response
>
> Maybe I misunderstood?  As far as I could tell you were claiming that 
> changing xml:base did not affect future image requests.

FUTURE image requests are of course affected. At first, I though it 
wasn’t, quote:

> 3. Not support dynamic operations of any kind on base URIs. This is 
> the current behaviour of Firefox’s. 

But, you corrected me in and in the last part of my [1] and [2] mails I 
agree that I made a mistake in my testing and that I was wrong.

[1] http://lists.w3.org/Archives/Public/public-html/2007Jun/0113.html
[2] http://lists.w3.org/Archives/Public/public-html/2007Jun/0157.html

But in this part of the mail I was responding to your statement that 
xml:base would slow down e.g. DOM mutations.

Let me quote the entirety that came before this:

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

Here I am suggesting that /automatically/ re-evaluating and updating 
included resources when their base URI changes, e.g. when moving them or 
changing the xml:base attribute, would NOT have to be done, while still 
complying with standards (and possibly explicitly define this in HTML5). 
You reply that you think it’s kind of odd behaviour, upon which I agree, 
but say "well if that’s what it takes, it’d work for me". Then I 
continue to say that UAs already do exactly this (maybe I should add 
here again that Firefox does a different thing with <base> than all 
other UAs), give <base> and xml:base as examples, saying "Firefox also 
implements xml:base that way".

So I think you must have confused the two issues because you replied 
"That's not what I see over here", while that *is* Firefox’s behaviour. 
Because the context was snipped away, I had to look up myself where 
exactly I had said "and Firefox with xml:base in XHTML as well" before I 
was able to respond there, so I can imagine that would have confused you 
as well.

If you take my baseuri-test.xhtml testcase, you can verify this yourself 
by clicking the ‘click to remove xml:base’ button (while having a file 
available locally at the images/sitelogo.png path too). The image does 
not change until you click the ‘click to re-set the image’s SRC 
attribute’ button, which means that changes in the base URI set by 
xml:base do not automatically apply to any images already loaded.


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


Received on Friday, 8 June 2007 01:41:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:45 UTC