Location.canonical proposal

I think there’s a useful but missing piece of window.location which is the page’s canonical URL.

Currently you have to get the <link rel="canonical" /> element if it exists for something which seems like it should be available with other location related properties. It also ignores that canonical can be sent with the HTTP headers.

It’s not a massive change but I think a small quality of life improvement that would also be relatively easy to polyfill.

Can you provide more information about the use case? What would the page do with this information? (I understand the use case for link rel=canonical … but not so much the use case for the API you are proposing)

It was more noticed as an apparent gap in the existing API rather than something that came from personal need on a project. Arguably any usecase could also work by getting the <link rel="canonical"> tag however location.canonical is a clearer alternative to document.querySelector("link[rel='canonical']").href and is shorter and cleaner once you take into account null checking on the link element before accessing href.

As mentioned an API like this could also take into account a canonical HTTP header which is not taken into account by the link element.

Some example usecases would be:

An analytics script. Just as canonical URLs are helpful in terms on SEO by not splitting pagerank on duplicate pages they would be as helpful in not splitting results in analytics reports, as well as tracking down referrals that may link in to non-canonical versions of a URL.

Sharing scripts (particularly with web share on the way) could easily be set to share the canonical version of a page rather than the current page (as opposed to eg AMP or mobile versions of a page).

User scripts or extensions to automatically break out of AMP or mobile pages from links could easily discover and reload the page at the canonical URL.

@marcosc are the provided use cases helpful or relevant? Being such a simple feature I wouldn’t mind doing some work writing it up spec-wise but obviously wouldn’t bother if it was a non-starter.

So, I think there is a more generalized problem of giving scripts access to HTTP header information that is not exposed to the page itself via any API (without doing a fetch(window.location.href, {method: "HEAD"})).

That could cover this use case, along with a bunch of other use cases… so maybe,

window.location.headers; 

Would cover all the use cases.