[whatwg] URL resolution of fragment urls in html5 webapps
ian at hixie.ch
Tue Sep 10 12:34:23 PDT 2013
On Tue, 9 Jul 2013, Igor Minar wrote:
> The current url resolution as described 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
> - 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].
The fragment identifiers resolve that way before the pushState(), too.
> 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.
How do they work in SVG with a <base> with no pushState()?
In Safari and Firefox, the relative URLs, even in SVG, are affected by
<base>, so again, it seems it's <base> that is relevant here, not
pushState(). (In Chrome, some URLs are resolved locally and some not,
which is wacked.)
> 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.
Use only site-absolute URLs, and not <base>, and then everything will work
fine, as far as I can tell.
On Wed, 10 Jul 2013, Alex Russell wrote:
> 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.
It seems pretty consistent.
On Wed, 10 Jul 2013, Rafael Weinstein wrote:
> I'm curious: Is it useful to have fragment URL resolve against anything
> other than the "display" url? I.e. when is the current behavior wrt
> fragments appropriate.
It's a good question. I thought the old IETF specs for URLs said you had
to do otherwise, but nobody seems to have implemented that.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg