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

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'