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

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.

I really don't want to add something to the navigation controller
specifically for this unless we can show that this is a common use
case.

Navigation controller is hairy enough as it is without trying to toss
in edge cases into it in at least the first version.

Igor: I don't quite understand the problem that you are running in to.
Can you provide an example which includes URLs of the initial document
url, the url that you pass to pushState (including if it's relative or
absolute), the value in <base> (again, including if it's relative or
absolute).

/ Jonas

> 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 Thursday, 18 July 2013 09:14:32 UTC