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

[whatwg] URL resolution of fragment urls in html5 webapps

From: Igor Minar <iminar@google.com>
Date: Tue, 9 Jul 2013 23:11:48 -0700
Message-ID: <CAO9zZYMo79Dqn-EK8S0j-M9sNJeFEGQg_XgP6+fsszDmq5oDMQ@mail.gmail.com>
To: whatwg@whatwg.org
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 06:12:34 UTC

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