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
