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

On Thu, 16 Feb 2012, Justin Lebar wrote:
> On Wed, Feb 15, 2012 at 5:31 PM, Ian Hickson <ian@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.
> 
> 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.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 29 June 2012 01:24:06 UTC