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

Wed Jul 20 08:54:22 PDT 2011

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

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

> The current entry is usually an entry for the location of the Document.

and the document's location changes when we call push/replaceState.

In any case, the navigation algorithm is clear as written.

>> 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.  :)

> 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)?  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?

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?

-Justin

<html>
<body>
<a href='#foo'>#foo</a><br>
<a href='?foo'>?foo</a><br>
<a href='foo'>foo</a><br>
 <button onclick='history.pushState("", "", Math.random())'>pushState
to new file</button><br>
<button onclick='history.pushState("", "", Math.random() +
"/file")'>pushState to new directory</button>
</body>
</html>

On Tue, Jul 19, 2011 at 5:35 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Wed, 27 Apr 2011, Justin Lebar wrote:
>>
>> The document base URL is used when fetching resources.
>>
>> Right now, if a page doesn't have a <base> element, the document base
>> URL is set to the document's address.  (I'm going to call this the
>> "document's original address".)  The document's original address does
>> not change when you call pushState; only the document's current address
>> does.
>>
>> I think the base URI should use the document's current address, not the
>> original address.
>>
>> To see why this makes sense, consider the following scenario:
>>
>> * User loads page.html
>> * Page calls pushState and changes its url to page2.html
>> * User clicks on a link with href "#foo".
>>
>> 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.
>>
>> Firefox 4 already implements pushState as I'm suggesting here.
>
> 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/.
>
> 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.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

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

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