- From: Igor Minar <iminar@google.com>
- Date: Thu, 25 Jul 2013 16:19:36 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: whatwg <whatwg@whatwg.org>, Alex Russell <slightlyoff@google.com>, Rafael Weinstein <rafaelw@google.com>, Jeni Tennison <jeni@jenitennison.com>, Jake Archibald <jakearchibald@google.com>
On Thu, Jul 25, 2013 at 4:14 PM, Jonas Sicking <jonas@sicking.cc> wrote: > On Thu, Jul 25, 2013 at 4:04 PM, Igor Minar <iminar@google.com> wrote: > > > > On Thu, Jul 25, 2013 at 3:09 PM, Jonas Sicking <jonas@sicking.cc> wrote: > >> > >> On Thu, Jul 18, 2013 at 8:42 AM, Igor Minar <iminar@google.com> wrote: > >> > > >> > > >> > > >> > On Thu, Jul 18, 2013 at 2:13 AM, Jonas Sicking <jonas@sicking.cc> > wrote: > >> >> > >> >> On Wed, Jul 10, 2013 at 10:24 AM, Alex Russell < > slightlyoff@google.com> > >> >> wrote: > >> >> > hey Igor, > >> >> > > >> >> > Was just discussing this with Rafael, and it seems like the core > >> >> > issue > >> >> > you're flagging is that if a document has a <base> element, all > >> >> > #anchor > >> >> > navigations (which would otherwise be document relative) are now > >> >> > full-page > >> >> > navigations to the URL specified in the <base>, not the document's > >> >> > "natural" URL. Is that right? > >> >> > > >> >> > If so, we might be able give you some control over this in the > >> >> > Navigation > >> >> > Controller (although it's not currently scoped as many folks didn't > >> >> > want > >> >> > to > >> >> > contemplate in-document navigation for the time being). > >> >> > > >> >> > But perhaps we don't need to do that: is the current behavior the > >> >> > same > >> >> > across browsers? If it's not, we might be able to change the spec. > If > >> >> > it > >> >> > is, it'll be harder. > >> >> > >> >> I really don't want to add something to the navigation controller > >> >> specifically for this unless we can show that this is a common use > >> >> case. > >> >> > >> >> Navigation controller is hairy enough as it is without trying to toss > >> >> in edge cases into it in at least the first version. > >> >> > >> >> Igor: I don't quite understand the problem that you are running in > to. > >> >> Can you provide an example which includes URLs of the initial > document > >> >> url, the url that you pass to pushState (including if it's relative > or > >> >> absolute), the value in <base> (again, including if it's relative or > >> >> absolute). > >> > > >> > > >> > pushState is actually not even needed to reproduce the same problem. > >> > It's > >> > enough when the base[href] doesn't match the url of the current > >> > document. > >> > > >> > Check out this simple document: > >> > - code+preview: http://plnkr.co/edit/TtH7rjQVKU6qN0QOxULW?p=preview > >> > - preview only: http://run.plnkr.co/bY3fF8OOXKq5MrSu/ > >> > > >> > pushState is just an easy way how you can get into situation where the > >> > url > >> > of the current document changes, and base[href] prevents all > in-document > >> > links to resolve correctly. > >> > >> I still don't understand how pushState plays into this. > > > > > > it's just an easy way how to get baseURI out of sync with the URI of the > > current document. > > > > as I said before, pushState is not even required to get into this > situation. > > my demo app above proves that. > > > >> And the > >> example doesn't use pushstate so it doesn't help with answering that > >> question. Note that pushState also should update the page's baseURI. > > > > it doesn't if base[href] is present. and that's the problem for html5 > apps > > but again, the problem is more generic it just happens that html5 apps > are > > the most affected. > > So it sounds like you are saying that: > > * Pages that use <base href> are affected > * Pages that use pushState are affected if they also use <base href> > correct > Seems to me like the problem is more with <base href> than with pushState > :) > yes > > >> But yes, <base> can easily mess up all your #foo links. > > > > my point is that it shouldn't. fragment urls should always resolve the > the > > uri of the current document which in all of these cases is different from > > baseURI. > > I could see the advantages with that, but it sounds awfully > inconsistent. I'm not convinced that everyone that uses <base href> > want that. In particular, both <a href> and <base href> are *really* > old, so chances are that there are tons of pages out there that use > both of them. So the risk of breakage of existing content seems huge. > As mentioned before, IE8 and 9 resolve urls just as I'm proposing, so I don't think that there are cross browser compatible apps that depend on the more consistent but less useful url resolution. /i > > / Jonas > > > > > /i > > > >> > >> > >> / Jonas > >> > >> >> > >> >> > >> >> / Jonas > >> >> > >> >> > On Wed, Jul 10, 2013 at 7:11 AM, Igor Minar <iminar@google.com> > >> >> > wrote: > >> >> > > >> >> >> The current url resolution as > >> >> >> described< > >> >> >> http://www.whatwg.org/specs/web-apps/current-work/#resolving-urls > >in > >> >> >> the spec results in some unhelpful behavior when the following > >> >> >> combination of web technologies are used in a client-side web app: > >> >> >> > >> >> >> - a combination of path-relative urls (<a > >> >> >> href="relative/url/to/somewhere">link</a>) and fragment/anchor > urls > >> >> >> (<a > >> >> >> href="#anchorUrl">link</a>) > >> >> >> - history.pushState - used for deep-linking > >> >> >> - base[href] - used to properly resolve the relative urls to the > >> >> >> root > >> >> >> of > >> >> >> the application in various deployment environments > >> >> >> > >> >> >> > >> >> >> Once history.pushState is used to change location.href, the > >> >> >> path-relative > >> >> >> urls resolve correctly as expected against the base[href], but > >> >> >> anchor > >> >> >> urls > >> >> >> that are only useful if resolved against the current > >> >> >> document.baseURI > >> >> >> also > >> >> >> unsurprisingly resolve against the base[href]. This behavior makes > >> >> >> them > >> >> >> unsuitable for this kind of applications which is a big loss in > >> >> >> developers > >> >> >> toolbox and in fact breaks existing web features like svg that > >> >> >> depend > >> >> >> on > >> >> >> anchor urls to reference nodes in the current document. > >> >> >> > >> >> >> Does anyone have thoughts on how one could build a client-side app > >> >> >> that > >> >> >> can > >> >> >> be deployed in various contexts without any special server-side > >> >> >> templating > >> >> >> or build-time pre-processing? > >> >> >> > >> >> >> The base element looks like a perfect solution for this, if only > it > >> >> >> didn't > >> >> >> break anchor urls. > >> >> >> > >> > > >> > > > > > >
Received on Thursday, 25 July 2013 23:20:22 UTC