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

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>

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

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

/ 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:15:36 UTC