- From: Igor Minar <iminar@google.com>
- Date: Thu, 18 Jul 2013 01:16:11 -0700
- To: Alex Russell <slightlyoff@google.com>
- Cc: whatwg <whatwg@whatwg.org>, Rafael Weinstein <rafaelw@google.com>, Jeni Tennison <jeni@jenitennison.com>, Jake Archibald <jakearchibald@google.com>
Holly cow! IE8 and 9 (but not 10) actually resolve the in-document urls just as I want even with base[href] set. Could that be used as an argument for clarifying the spec on url resolution and making the in-document navigation with base set possible? btw Alex, I looked at the Navigation Controller and it would definitely help if the in-document navigation was something that I could control with it. But ideally, I shouldn't need to do anything for the in-document navigation to work. On Wed, Jul 10, 2013 at 11:14 AM, Igor Minar <iminar@google.com> 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? >> > > correct > > >> >> 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. >> > > As far as I can tell it is, because that the easiest thing to implement. > It sort of makes sense why - a relative anchor url is treated just as any > relative url and it is resolved as such. However, just as Rafael pointed > out, unlike path-relative urls, I can't think of a scenario where resolving > relative anchor urls against anything but "self" would be useful and > therefore I have a hard time thinking of an existing code that would take > advantage and rely on this kind of resolution. > > In the ideal world, I'd love for the spec to say that > - all relative urls except for relative anchor urls should be resolved > against document.baseURI (which is tied to location.href unless base[href] > is set) > - relative anchor urls should always resolve against location.href > > I think that this kind of behavior would make the url resolution work in > all common and currently used scenarios. > > /i > > > > >> >> Regards >> >> >> 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, 18 July 2013 08:16:57 UTC