Re: [whatwg] URL resolution of fragment urls in html5 webapps

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.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 10 September 2013 19:34:47 UTC