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

[Justin Lebar-3]

The document base URL [1] 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 [2] 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.

-Justin

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#document-base-url
[2] http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#the-document%27s-current-address

[Justin Lebar-3]

The document base URL [1] 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 [2] 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.

-Justin

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#document-base-url
[2] http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#the-document%27s-current-address

[Ian Hickson]

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

[Justin Lebar-3]

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

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

[Justin Lebar-3]

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

[Ian Hickson]

On Wed, 15 Feb 2012, Justin Lebar wrote:
>
> 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?

We fix the implementations to match the spec. :-)


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

Seems to me we should change the implementations then. There isn't any
fundamental difference between linking to #foo and linking to
page.html#foo if the base URL is page.html, as far as I can tell.


If the implementations can't change, then I'll change the spec, but it
really seems bad to me that relative URLs will break depending on when
they are resolved relative to pushState() changes.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Justin Lebar-3]

On Wed, Feb 15, 2012 at 5:31 PM, Ian Hickson <ian@...> wrote:

> On Wed, 15 Feb 2012, Justin Lebar wrote:
>> >  - 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).
>
> Seems to me we should change the implementations then. There isn't any
> fundamental difference between linking to #foo and linking to
> page.html#foo if the base URL is page.html, as far as I can tell.
>
> If the implementations can't change, then I'll change the spec, but it
> really seems bad to me that relative URLs will break depending on when
> they are resolved relative to pushState() changes.

When I implemented pushState, I explicitly didn't want authors to have
to rewrite all their anchor links after they changed the document's
current URI.

From an author's point of view, there's no such thing as the
document's original URI and, unless you're a nerd, you've never heard
of the base URI.  There's just the document's URI, modified by
pushState.

From this point of view, I'd say it's less surprising that relative
URIs would break when you change directories (hey, you *asked* for it)
than that anchor refs would update the browser's address bar and
document.location relative to the old URI.

If we did make the change you're suggesting, we'd have to check that
it doesn't break at least the major sites which use pushstate
(Facebook, anyone?).  And I'd want to try to coordinate the change
with WebKit so we quickly move away from the old behavior.  But I'm
not convinced it's worthwhile, given that there's at least an argument
for the current behavior.

-Justin

> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Sean Hogan]

On 16/02/12 5:03 PM, Justin Lebar wrote:

> On Wed, Feb 15, 2012 at 5:31 PM, Ian Hickson<ian@...>  wrote:
>> On Wed, 15 Feb 2012, Justin Lebar wrote:
>>>>   - 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).
>> Seems to me we should change the implementations then. There isn't any
>> fundamental difference between linking to #foo and linking to
>> page.html#foo if the base URL is page.html, as far as I can tell.
>>
>> If the implementations can't change, then I'll change the spec, but it
>> really seems bad to me that relative URLs will break depending on when
>> they are resolved relative to pushState() changes.
> When I implemented pushState, I explicitly didn't want authors to have
> to rewrite all their anchor links after they changed the document's
> current URI.
>
> > From an author's point of view, there's no such thing as the
> document's original URI and, unless you're a nerd, you've never heard
> of the base URI.  There's just the document's URI, modified by
> pushState.
>
> > From this point of view, I'd say it's less surprising that relative
> URIs would break when you change directories (hey, you *asked* for it)
> than that anchor refs would update the browser's address bar and
> document.location relative to the old URI.

I share your perspective, Justin (if I'm interpreting it correctly).

An obvious use-case for pushState() is facilitating an enhanced
user-experience for page navigation within a site. In this case the
process of document updates + pushState({},null, "foo/bar.html") should
result in the same DOM as if foo/bar.html was browsed to directly.

For example, imagine a site that has some pages amenable to this usage:

/page1.html
/page2.html
/subdir/page3.html

These contain some page specific content wrapped in some generic page
template.
(I'm assuming that pages amenable to document updates + pushState() have
a lot in common, otherwise why use pushState().)

<!DOCTYPE html>
<head>
<link rel="stylesheet" href="/style.css" />
</head>
<body>
<p>I hope you are not distracted by my enormous banner. You may want to
<a href="#content">skip</a> directly to the main content of this page. </p>
<div id="banner">
<h1>
<img src="logo.png" /> My Site
</h1>
</div>
<nav id="nav">
<a href="page1.html">Page 1</a>
<a href="page2.html">Page 2</a>
<a href="subdir/page3.html">Page 3</a>
</nav>
<div id="content">
<!-- Page specific content here -->
</div>
</body>
</html>


The following stylesheets and images are used:
/style.css
/logo.png


If page creation was all performed on the server using this template then...
- /page1.html & /page2.html would be okay
- /subdir/page3.html would be broken:
   1. <img src="logo.png" /> has a relative path and refs the
non-existant /subdir/logo.png
   2. Similarly, <a href=""> with #nav all have rel paths to nowhere
   3. Note that the top skip link is OK in all pages

If a pushState() facilitated mechanism was used for navigation
(a naive implementation which just inserts page-specific content inside
<div id="content"></div>)
and navigation started at /page1.html, thence to /page2.html and
/subdir/page3.html,
the images and hyperlinks in /subdir/page3.html would be fine...
except for the top skip link which references the #content anchor.

Obviously this page template needs fixing and for this example, simply
changing rel paths to absolute will be sufficient for both the server
generated and browser updated documents. Except that pushState()
assisted navigation would break the top skip link (assuming the current
SPECIFIED behavior).

For all the issues in this example I think Justin's proposal is
preferable to what is currently specified.

By the way, this doesn't quite match what is currently implemented in
Firefox and Webkit. According to my testing, although the baseURI after
pushState() is the same as the documentURI (so far I've tested <img>,
<link> and <a> elts) the actual images and stylesheets used for
rendering aren't updated by the pushState() - they should be updated if
@src, @href is a rel path. If they were updated then the ones relying on
rel paths would often break, which I consider a good behavior - an
obvious visual cue to the page author, etc that something was
implemented wrongly.

Sean

[Sean Hogan]

On 20/02/12 2:35 PM, Sean Hogan wrote:

> On 16/02/12 5:03 PM, Justin Lebar wrote:
>> On Wed, Feb 15, 2012 at 5:31 PM, Ian Hickson<ian@...>  wrote:
>>> On Wed, 15 Feb 2012, Justin Lebar wrote:
>>>>>   - 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).
>>> Seems to me we should change the implementations then. There isn't any
>>> fundamental difference between linking to #foo and linking to
>>> page.html#foo if the base URL is page.html, as far as I can tell.
>>>
>>> If the implementations can't change, then I'll change the spec, but it
>>> really seems bad to me that relative URLs will break depending on when
>>> they are resolved relative to pushState() changes.
>> When I implemented pushState, I explicitly didn't want authors to have
>> to rewrite all their anchor links after they changed the document's
>> current URI.
>>
>> > From an author's point of view, there's no such thing as the
>> document's original URI and, unless you're a nerd, you've never heard
>> of the base URI.  There's just the document's URI, modified by
>> pushState.
>>
>> > From this point of view, I'd say it's less surprising that relative
>> URIs would break when you change directories (hey, you *asked* for it)
>> than that anchor refs would update the browser's address bar and
>> document.location relative to the old URI.
>
> I share your perspective, Justin (if I'm interpreting it correctly).
>

<snip>

> By the way, this doesn't quite match what is currently implemented in
> Firefox and Webkit. According to my testing, although the baseURI
> after pushState() is the same as the documentURI (so far I've tested
> <img>, <link> and <a> elts) the actual images and stylesheets used for
> rendering aren't updated by the pushState() - they should be updated
> if @src, @href is a rel path. If they were updated then the ones
> relying on rel paths would often break, which I consider a good
> behavior - an obvious visual cue to the page author, etc that
> something was implemented wrongly.
>
> Sean
>
>

I've just realized that Firefox's behavior matches the spec for dynamic
changes to base URLs,
http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#dynamic-changes-to-base-urls

Personally I think that facilitates broken behavior, but it's not
significant as the issue of this thread.

Sean

[Justin Lebar-3]

> From an author's point of view, there's no such thing as the
> document's original URI and, unless you're a nerd, you've never heard
> of the base URI.  There's just the document's URI, modified by
> pushState.
>
> From this point of view, I'd say it's less surprising that relative
> URIs would break when you change directories (hey, you *asked* for it)
> than that anchor refs would update the browser's address bar and
> document.location relative to the old URI.

In my tests, Chrome and Firefox both immediately change
document.baseURL when you call pushState.  Images (and I presume other
resources) are resolved relative to the new base.

I'm not sure why your earlier test with seemed to "work" in Chrome, Hixie.  :-/

I think this ship may have sailed.

-Justin

<button onclick='push()'>Click me</button>
function push() {
  history.pushState('', '', '/' + Math.random() + '/file');
  alert(document.baseURI);
}

[Ian Hickson]

On Thu, 16 Feb 2012, Justin Lebar wrote:

> On Wed, Feb 15, 2012 at 5:31 PM, Ian Hickson <ian@...> wrote:
> > On Wed, 15 Feb 2012, Justin Lebar wrote:
> >> >  - 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).
> >
> > Seems to me we should change the implementations then. There isn't any
> > fundamental difference between linking to #foo and linking to
> > page.html#foo if the base URL is page.html, as far as I can tell.
> >
> > If the implementations can't change, then I'll change the spec, but it
> > really seems bad to me that relative URLs will break depending on when
> > they are resolved relative to pushState() changes.
>
> When I implemented pushState, I explicitly didn't want authors to have
> to rewrite all their anchor links after they changed the document's
> current URI.
>
> From an author's point of view, there's no such thing as the document's
> original URI and, unless you're a nerd, you've never heard of the base
> URI.  There's just the document's URI, modified by pushState.
>
> From this point of view, I'd say it's less surprising that relative URIs
> would break when you change directories (hey, you *asked* for it) than
> that anchor refs would update the browser's address bar and
> document.location relative to the old URI.
>
> If we did make the change you're suggesting, we'd have to check that it
> doesn't break at least the major sites which use pushstate (Facebook,
> anyone?).  And I'd want to try to coordinate the change with WebKit so
> we quickly move away from the old behavior.  But I'm not convinced it's
> worthwhile, given that there's at least an argument for the current
> behavior.

On Mon, 20 Feb 2012, Sean Hogan wrote:

>
> An obvious use-case for pushState() is facilitating an enhanced
> user-experience for page navigation within a site. In this case the process of
> document updates + pushState({},null, "foo/bar.html") should result in the
> same DOM as if foo/bar.html was browsed to directly.
>
> For example, imagine a site that has some pages amenable to this usage:
>
> /page1.html
> /page2.html
> /subdir/page3.html
>
> These contain some page specific content wrapped in some generic page
> template.
> (I'm assuming that pages amenable to document updates + pushState() have a lot
> in common, otherwise why use pushState().)
>
> <!DOCTYPE html>
> <head>
> <link rel="stylesheet" href="/style.css" />
> </head>
> <body>
> <p>I hope you are not distracted by my enormous banner. You may want to <a
> href="#content">skip</a> directly to the main content of this page. </p>
> <div id="banner">
> <h1>
> <img src="logo.png" /> My Site
> </h1>
> </div>
> <nav id="nav">
> <a href="page1.html">Page 1</a>
> <a href="page2.html">Page 2</a>
> <a href="subdir/page3.html">Page 3</a>
> </nav>
> <div id="content">
> <!-- Page specific content here -->
> </div>
> </body>
> </html>
>
>
> The following stylesheets and images are used:
> /style.css
> /logo.png
>
>
> If page creation was all performed on the server using this template then...
> - /page1.html & /page2.html would be okay
> - /subdir/page3.html would be broken:
>   1. <img src="logo.png" /> has a relative path and refs the non-existant
> /subdir/logo.png
>   2. Similarly, <a href=""> with #nav all have rel paths to nowhere
>   3. Note that the top skip link is OK in all pages
>
> If a pushState() facilitated mechanism was used for navigation
> (a naive implementation which just inserts page-specific content inside <div
> id="content"></div>)
> and navigation started at /page1.html, thence to /page2.html and
> /subdir/page3.html,
> the images and hyperlinks in /subdir/page3.html would be fine...
> except for the top skip link which references the #content anchor.
>
> Obviously this page template needs fixing and for this example, simply
> changing rel paths to absolute will be sufficient for both the server
> generated and browser updated documents. Except that pushState()
> assisted navigation would break the top skip link (assuming the current
> SPECIFIED behavior).
>
> For all the issues in this example I think Justin's proposal is
> preferable to what is currently specified.

Fair enough. I have changed the spec accordingly.


> By the way, this doesn't quite match what is currently implemented in
> Firefox and Webkit. According to my testing, although the baseURI after
> pushState() is the same as the documentURI (so far I've tested <img>,
> <link> and <a> elts) the actual images and stylesheets used for
> rendering aren't updated by the pushState() - they should be updated if
> @src, @href is a rel path. If they were updated then the ones relying on
> rel paths would often break, which I consider a good behavior - an
> obvious visual cue to the page author, etc that something was
> implemented wrongly.

Changing the base URL doesn't cause the image URLs to be reresolved *if
they were already resolved*, but you can still end up with problems, e.g.
in browsers that load images on demand, or, more importantly maybe, on
sites that use the new srcset="" feature (or whatever replaces it, if we
end up replacing it -- I still have 300+ e-mails to go through on the
topic). If a site uses such a feature with relative URLs, and the user
resizes the window, then URLs get reresolved according to a different base
URL, and the page may break. Basically, this means that authors have to
use at least path-absolute URLs (those with a leading "/") when using
pushState() in a manner that changes paths.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'