[whatwg] Issues concerning the <base> element and xml:base

[Jonas Sicking]

Maciej Stachowiak wrote:
> 
> On Jun 6, 2008, at 12:01 PM, Ian Hickson wrote:
> 
>>
>> On Sat, 1 Mar 2008, Jonas Sicking wrote:
>>>
>>> I very much agree it's an edge case and would be fine with leaving it
>>> undefined.
>>
>> Well, right now it's implicitly defined that changing the base changes
>> anything refering to that base instantly. I'm not really sure how to
>> unspecify that without adding a really weird clause like "in the event
>> that the attribute is changed, user agents may, whenever convenient,
>> pretend, for the sake of url resolution, that it has not changed".
>>
>>
>> I have made notes in the spec that this is an area that needs defining.
>> Right now I'm leaning towards defining a "base href change notification
>> behaviour" for all elements that have URI attributes or are otherwise
>> sensitive to base href changes, and defining that when the base href
>> changes, all the elements in the document with such behaviour defined
>> should have that behaviour activated (this would, in the simple case, 
>> just
>> be a walk over the document with a virtual method call per element; it
>> might be a bit slow for some documents, but then this is a very rare
>> occurance anyway). We would also invoke this behaviour on the entire
>> subtree of an element whenever that element is inserted into a different
>> document, in case it matters in any cases.
>>
>> In practice I think this only actually affects :link/:visited and url()
>> rules in style="" attributes. I plan on making <img>/<iframe>/<link
>> rel=stylesheet> etc not reload their content if the base href changes
>> (though that does mean that .src and .href will end up pointing to URIs
>> that aren't actually what was loaded). I can't think of any other cases
>> that are sensitive off the top of my head, but I'll be thorough if I do
>> end up specifying this.
>>
>> The question is, are people ok with that plan?
> 
> It seems weird for src and href attributes to have a URI other than what 
> the element has loaded or is loading - this would be the only case where 
> they may not match. (Also, would setting href or src to itself in such a 
> case trigger a load of a different resource?)

I agree it's undesirable, but I don't think it's a particularly big 
problem. I would imagine it is extremely rare that any pages out there 
is ever going to run in to this. We've never handled dynamic changes to 
<base> in gecko, and I've never heard any complaints about it. Similarly 
we end up in the situation where .href/.src returns a different URI than 
what was loaded, but I don't think that's a big deal either.

> I have to admit I am not especially excited about implementing instant 
> dynamic updates of everything in the document referencing a URI, whether 
> it triggers a load or not, when the <base> element is changed. That 
> seems like a lot of coding and testing work solely to serve a very 
> unimportant edge case that right now likely no one depends on. In 
> general if the spec requires significant implementation work for 
> something that has no real user or author benefit, just because that is 
> easier to define, then I think we have chosen poorly.

I feel exactly the same way. This is something that no-one is going to 
run in to most likely. And if they do it seems like something they could 
easily fix.

I honestly think this is a case where the web would do better with 
implementations spending time fixing other issues than adding code that 
no real website is going to trigger.

/ Jonas