Anders Carlsson wrote:
The spec for the add and remove ApplicationCache methods does not say
what to do about how relative URIs should be resolved.
I think it would be most intuitive to resolve them agains't the URI o
the document that the ApplicationCache object is associated with.
Generally I believe URIs have been resolved against the URI of the document that the
script that invoked the method is associated with. For example, if I have origin A and
pages A_1 and A_2, a script on A_1 that uses, say, A_2.XMLHttpRequest.open with a
relative URI will have that URI resolved against A_1.location.href. Similar precedent
applies to loading scripts or iframes, calculating the sender's URI for events dispatched
by postMessage, and other such uses. Think of it this way: a relative URI used from
script is lexically scoped to the document that loaded the script, and any
relative URIs used have the same semantics any time that code executes -- they're not
dependent on the location of the document associated with the ApplicationCache, which
might or might not be what you actually expected it to be at runtime.
What you suggest goes against a lot of precedent, from my point of view. If
only for consistency, I think we're better off making relative URIs be
lexically scoped such that they're resolved against the location of the
document in which the script is executed.
Jeff
