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

On Thu, Jul 25, 2013 at 4:14 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Jul 25, 2013 at 4:04 PM, Igor Minar <iminar@google.com> wrote:
> >
> > On Thu, Jul 25, 2013 at 3:09 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >>
> >> On Thu, Jul 18, 2013 at 8:42 AM, Igor Minar <iminar@google.com> wrote:
> >> >
> >> >
> >> >
> >> > On Thu, Jul 18, 2013 at 2:13 AM, Jonas Sicking <jonas@sicking.cc>
> wrote:
> >> >>
> >> >> 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).
> >> >
> >> >
> >> > 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.
> >
> >
> > it's just an easy way how to get baseURI out of sync with the URI of the
> > current document.
> >
> > as I said before, pushState is not even required to get into this
> situation.
> > my demo app above proves that.
> >
> >> 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.
> >
> > it doesn't if base[href] is present. and that's the problem for html5
> apps
> > but again, the problem is more generic it just happens that html5 apps
> are
> > the most affected.
>
> So it sounds like you are saying that:
>
> * Pages that use <base href> are affected
> * Pages that use pushState are affected if they also use <base href>
>

correct


> Seems to me like the problem is more with <base href> than with pushState
> :)
>

yes


>
> >> But yes, <base> can easily mess up all your #foo links.
> >
> > my point is that it shouldn't. fragment urls should always resolve the
> the
> > uri of the current document which in all of these cases is different from
> > baseURI.
>
> I could see the advantages with that, but it sounds awfully
> inconsistent. I'm not convinced that everyone that uses <base href>
> want that. In particular, both <a href> and <base href> are *really*
> old, so chances are that there are tons of pages out there that use
> both of them. So the risk of breakage of existing content seems huge.
>

As mentioned before, IE8 and 9 resolve urls just as I'm proposing, so I
don't think that there are cross browser compatible apps that depend on the
more consistent but less useful url resolution.

/i


>
> / Jonas
>
> >
> > /i
> >
> >>
> >>
> >> / Jonas
> >>
> >> >>
> >> >>
> >> >> / 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, 25 July 2013 23:20:22 UTC