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<i...@hixie.ch> 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
