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 <[email protected]> wrote: > > > > On Wed, Jul 10, 2013 at 10:24 AM, Alex Russell <[email protected]>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 <[email protected]> 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. >>> >> >> >
