[whatwg] URL resolution of fragment urls in html5 webapps

[Igor Minar]

Holly cow! IE8 and 9 (but not 10) actually resolve the in-document urls
just as I want even with base[href] set.

Could that be used as an argument for clarifying the spec on url resolution
and making the in-document navigation with base set possible?

btw Alex, I looked at the Navigation Controller and it would definitely
help if the in-document navigation was something that I could control with
it. But ideally, I shouldn't need to do anything for the in-document
navigation to work.




On Wed, Jul 10, 2013 at 11:14 AM, Igor Minar <iminar at google.com> 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?
>>
>
> correct
>
>
>>
>> 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.
>>
>
> As far as I can tell it is, because that the easiest thing to implement.
> It sort of makes sense why - a relative anchor url is treated just as any
> relative url and it is resolved as such. However, just as Rafael pointed
> out, unlike path-relative urls, I can't think of a scenario where resolving
> relative anchor urls against anything but "self" would be useful and
> therefore I have a hard time thinking of an existing code that would take
> advantage and rely on this kind of resolution.
>
> In the ideal world, I'd love for the spec to say that
> - all relative urls except for relative anchor urls should be resolved
> against document.baseURI (which is tied to location.href unless base[href]
> is set)
> - relative anchor urls should always resolve against location.href
>
> I think that this kind of behavior would make the url resolution work in
> all common and currently used scenarios.
>
> /i
>
>
>
>
>>
>> Regards
>>
>>
>> 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.
>>>
>>
>>
>