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