- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sun, 8 Jun 2008 19:10:32 -0700
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. Regards, Maciej
Received on Sunday, 8 June 2008 19:10:32 UTC