[whatwg] URL resolution of fragment urls in html5 webapps

[Igor Minar]

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


>
> / 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.
> >>
>