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

Maciej Stachowiak mjs at apple.com
Sun Jun 8 19:10:32 PDT 2008

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


More information about the whatwg mailing list