[whatwg] URL resolution of fragment urls in html5 webapps
Ian Hickson
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
> 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].
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()?
http://hixie.ch/tests/adhoc/svg/use/001-with-base.html
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
mailing list