Polymer 1.0 rewrites links to be relative to source document rather than page.

[augustoroman]

In polymer 1.0, my elements that have links in the template dom are re-written to be relative to where the element is loaded rather than relative to the current browser location.

That is, if (in my element) I have:

  <a href="/about">About us</a>

and the page is at http://widgets.com/ but the static content is served from http://cdn.com/path/to/content/, the link will point to http://cdn.com/about instead of http://widgets.com/about.

This appears to be occurring due to the urlResolver code:

    function resolve(url, ownerDocument) {
        if (url && url[0] === '#') {
            return url;
        }
        var resolver = getUrlResolver(ownerDocument);
        resolver.href = url;
        return resolver.href || url;
    }
    function getUrlResolver(ownerDocument) {
        return ownerDocument.__urlResolver || (ownerDocument.__urlResolver = ownerDocument.createElement('a'));
    }

which is getting applied to my element.

A workaround at the moment is to inject the url via data-binding to a computed function, e.g.:

  <a href="{{str('/about')}}">About us</a>

with

  str: function(s) { return s; },

in my element... but that's just silly.

[oderby]

Bump. This is a big gotcha that's bitten me a few times.

[kevinpschaaf]

Absolute paths should not be rewritten -- this should be fixed.

[ktiedt]

Ping @azakus / @tjsavage -- This has been a hot topic in the Slack channel today, It seems most people were not inclined to +1 this but, it does seem like a pretty important issue to address.

[aletorrado]

It definitely should not behave different when using computed binding like this:

<iron-ajax
    url="/api/v1[[endpoint]]"
></iron-ajax

(this way it's resolved against the page)