[whatwg] URL resolution of fragment urls in html5 webapps

[Jonas Sicking]

On Thu, Jul 18, 2013 at 8:42 AM, Igor Minar <iminar at google.com> wrote:
>
>
>
> On Thu, Jul 18, 2013 at 2:13 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> On Wed, Jul 10, 2013 at 10:24 AM, Alex Russell <slightlyoff at 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).
>
>
> pushState is actually not even needed to reproduce the same problem. It's
> enough when the base[href] doesn't match the url of the current document.
>
> Check out this simple document:
> - code+preview: http://plnkr.co/edit/TtH7rjQVKU6qN0QOxULW?p=preview
> - preview only: http://run.plnkr.co/bY3fF8OOXKq5MrSu/
>
> pushState is just an easy way how you can get into situation where the url
> of the current document changes, and base[href] prevents all in-document
> links to resolve correctly.

I still don't understand how pushState plays into this. And the
example doesn't use pushstate so it doesn't help with answering that
question. Note that pushState also should update the page's baseURI.

But yes, <base> can easily mess up all your #foo links.

/ Jonas

>>
>>
>> / Jonas
>>
>> > On Wed, Jul 10, 2013 at 7:11 AM, Igor Minar <iminar at 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.
>> >>
>
>