W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2013

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

From: Rafael Weinstein <rafaelw@google.com>
Date: Wed, 10 Jul 2013 10:27:14 -0700
Message-ID: <CABMdHiTv6hoDF5Y0Ar5mL1XFDPkXpnmR8soNT-eR5ez0nmoAAw@mail.gmail.com>
To: Alex Russell <slightlyoff@google.com>
Cc: whatwg <whatwg@whatwg.org>, Jake Archibald <jakearchibald@google.com>, Jeni Tennison <jeni@jenitennison.com>, Igor Minar <iminar@google.com>
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.

On Wed, Jul 10, 2013 at 10:24 AM, Alex Russell <slightlyoff@google.com> 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?
>
> 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@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.
>
>
Received on Wednesday, 10 July 2013 17:27:39 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:03 UTC