[whatwg] Document's base URI should use the document's *current* address

[Justin Lebar]

> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1342
>
> It doesn't make sense that the second image is broken.
>
> (For some reason in Firefox I get an exception. Not sure if I'm misusing
> the API or if it's a bug in Firefox.)

Not sure what's going on with that Firefox exception.  But I'm not
terribly surprised that the second image shouldn't work...  :)

>> Similarly, if for some bizarre reason the page pushState's to a new
>> directory, shouldn't all the links point relative to that new directory?
>
> That would break all existing images, stylesheets, scripts, etc, if their
> URLs are reused somehow.

Hm...maybe you're right.  But then, how do we jive this with "#foo"
and "?foo" links, both of which resolve relative to the current URI in
both Firefox and WebKit?

>  - Start the "Follow a hyperlink" algorithm.
> -  [snip]
>  - It sets "the document's current address" to ".../page.html#foo".

Well, this is pretty bad.  document.location is the document's current
address [1].  So clicking #foo changed document.location from
page2.html to page.html#foo, which I certainly wouldn't expect (and
does not match implementations).

-Justin

[1] The href attribute [of document.location] must return the current
address of the associated Document object, as an absolute URL.

On Wed, Feb 15, 2012 at 3:50 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Wed, 20 Jul 2011, Justin Lebar wrote:
>> >
>> > The spec as written decides whether a link is a same-resource
>> > reference or not based on comparing the URLs to what you're calling
>> > the original address, not comparing it to the current address. See the
>> > navigation algorithm, step 7 /Fragment identifiers/.
>>
>> Maybe I'm misunderstanding, but this might not be the case in the
>> history traversal algorithm.
>
> In history traversal, the URLs compared are those of the entries involved.
> However, clicking a link is primarily navigation, not session history
> traversal (though it can involve the latter).
>
>
>> > Step 6: If the specified entry has a URL whose fragment identifier
>> > differs from that of the current entry's when compared in a
>> > case-sensitive manner, and the two share the same Document object,
>> > then let hash changed be true.
>>
>> It's not clear to me what the current/specified entry's URL is, or where
>> this is properly defined, but earlier, we say:
>
> Hm, yes, the spec doesn't quite clearly define the URL in all cases.
> Fixed.
>
>
>> > The current entry is usually an entry for the location of the
>> > Document.
>
> That's a non-normative statement. I've made it more explicitly so.
>
>
>> and the document's location changes when we call push/replaceState.
>
> The current entry is whatever the algorithms last set the current entry
> to. I've made that clearer in the spec.
>
>
>> >> As currently specified, we'll resolve #foo relative to the document's
>> >> original URL; that is, clicking the link will take the user to
>> >> page.html#foo, not page2.html#foo.  But the intent of a link with
>> >> href #foo is clearly to navigate within the current page, not to go
>> >> somewhere else.
>>
>> Were you saying that this isn't the right interpretation of the spec?
>> Because #foo is resolved relative to the document's base URI, which is
>> the same as the document's original URI, so we decide that #foo is a
>> same-document link?  That's comforting, if it's true.  :)
>
> When you click a link to "#foo" on a document whose "current address" is
> page2.html but whose "document's address" is "page.html", then you go
> through these steps:
>
>  - Start the "Follow a hyperlink" algorithm.
>  - "Resolve" href relative to the <a> element.
>  - This uses XML Base, with the fallback base url being "the document's
>   address", which is what you were calling "the original URL".
>  - This results in ".../page.html#foo".
>  - "Navigate" to that URL.
>  - Step "Fragment identifiers" then compares this URL to "the document's
>   address" (page.html, not page2.html), and finds a match.
>  - "Navigating to a fragment identifier" is invoked and creates a new
>   session history entry with the URL "page.html#foo".
>  - "Traverse the history" is then invoked.
>  - It sets "the document's current address" to ".../page.html#foo".
>  - Scrolling happens.
>  - The "current entry"'s URL is "../page2.html" and the specified entry's
>   URL is ".../page.html#foo" so the fragids differ and hashchange fires.
>  - The "current entry" becomes the new specified entry.
>
>
>> > Note that there are problems with what you describe: what if the new
>> > URL has a different path, and there are <img> elements whose URLs are
>> > relative, and after pushState() you clone one? Or what about relative
>> > links in the original markup? I don't think we can change the base URL
>> > on the fly, all kinds of problems could result.
>>
>> I agree there are problems with changing the base URI.  But it seems
>> much less intuitive for common use-cases not to change it.  We can
>> change my example above to use ?foo instead of #foo, and I think the
>> same argument applies.  Should a link with href ?foo always resolve
>> relative to the document's original URI (unless the base is explicitly
>> changed)?
>
> Yes, I'd say so. Otherwise cloning images would break.
>
>
>> Similarly, if for some bizarre reason the page pushState's to a new
>> directory, shouldn't all the links point relative to that new directory?
>
> That would break all existing images, stylesheets, scripts, etc, if their
> URLs are reused somehow.
>
>
>> I kind of think this ship has sailed wrt implementations.  Chrome and
>> Firefox both have the same behavior in this respect.  See
>> http://people.mozilla.org/~jlebar/whatwg/test_pushstate_resolve.html
>> (source included below, since I have a bad habit of deleting these test
>> files right before someone else wants to look at them).
>>
>> Ian, how hard do you think it would be to spec changing the base and
>> resolve the issues with that?
>
> Changing the base URL would be trivial, but I think it would cause all
> kinds of bad things and isn't what we should do. Consider:
>
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1342
>
> It doesn't make sense that the second image is broken.
>
> (For some reason in Firefox I get an exception. Not sure if I'm misusing
> the API or if it's a bug in Firefox.)
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'