- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 29 Jun 2012 01:23:36 +0000 (UTC)
- To: Justin Lebar <justin.lebar@gmail.com>, Sean Hogan <shogun70@westnet.com.au>
- Cc: WHAT Working Group <whatwg@whatwg.org>
- Message-ID: <Pine.LNX.4.64.1206290118250.30734@ps20323.dreamhostps.com>
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