W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2012

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

From: Justin Lebar <justin.lebar@gmail.com>
Date: Wed, 15 Feb 2012 16:19:07 -0500
Message-ID: <CAFWcpZ7RXd3CYg+cksG7GhUH7_kObTmU97xFa=MVMVs8dz7onw@mail.gmail.com>
> 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. ? `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 15 February 2012 13:19:07 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:40 UTC