Re: parsing URI (references) according to RFC 3986

* Boris Zbarsky wrote:
>But what happens with
>
>   window.open("#foo")
>
>?  What about situations in which base URIs change?  What if instead of 
>clicking the link, someone gets the .href of the anchor and then sets 
>location of this or some other window to that?  Per the spec, the result 
>of that .href should be a same-document reference which should scroll 
>whatever window it's set to to the anchor 'foo' in that window, but 
>that's not what UAs do.

I do not share this reading of RFC 3986. I would say that the effects of
using some JavaScript API are up to the definition of that API up to the
constraints of RFC 3986, which in this case I would read as saying, if
the argument to window.open is a URL, then

  window.open("#foo")

and

  window.open("http://example.org/#foo")

must be treated the same assuming the former URI is a shorthand for the
latter (as specified in RFC 3986 via "base URIs" and such). If that is
not the case, then I would say window.open does not take a URI as first
argument, but rather something similar with different effects (or that
the behavior is a bug if there is a desire to fix it).

>Basically, the spec seems to assume that whatever action you plan to 
>take with the URI immediately follows resolution wrt a base uri, and 
>that this action is known at the time the resolution happens.  It's not 
>clear to me why this assumption is justified.

I do not understand this comment. I would think that RFC 3986, to put it
this way, defines various Pure functions; and you seem to be concerned
about what effect state changes have on the pure functions. And by defi-
nition, pure functions are not affected by state (that's not passed to
them). So your concern seems to be about something that's not meant to
be covered by RFC 3986.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Thursday, 23 June 2011 17:55:31 UTC