[whatwg] URL resolution of fragment urls in html5 webapps

[Alex Russell]

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.

Regards


On Wed, Jul 10, 2013 at 7:11 AM, Igor Minar <iminar at 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.
>