Clarify that Location.assign and Location.replace also accept URLs

[silverwind]

Description

Location.assign and Location.replace also accept URLs

Motivation

This works in all browsers I tested (Firefox, Chrome, Safari, PaleMoon), so MDN was incorrect.

Additional details

TypeScript has it correct already:

https://github.com/microsoft/TypeScript/blob/e6ef279403d86440600c866d53839a3e695220d3/src/lib/dom.generated.d.ts#L15107
https://github.com/microsoft/TypeScript/blob/e6ef279403d86440600c866d53839a3e695220d3/src/lib/dom.generated.d.ts#L15119

[github-actions]

Preview URLs

• /en-US/docs/Web/API/Location/assign
• /en-US/docs/Web/API/Location/replace

(comment last updated: 2024-10-26 18:33:22)

[Josh-Cena]

There's nothing special about passing URLs to these APIs. They merely coerce everything to strings. Check the spec: https://html.spec.whatwg.org/multipage/nav-history-apis.html#the-location-interface undefined assign(USVString url);

The reason TypeScript needs to declare the type like this is because it doesn't have a type that means "all objects with sensible toString behavior" and presumably someone complained that they can't pass a URL directly without converting it to string first. But as far as the IDL and the underlying implementation is concerned, URL is not a "blessed type" as an input.

[silverwind]

Saying it accepts "a string" is still incorrect, thought. Maybe it should say "a string, or any object with a .toString() method"?

[Josh-Cena]

I think we have precedents of doing similar stuff elsewhere, so you may want to search for one, but the idea makes sense to me.

[sideshowbarker]

I think we have precedents of doing similar stuff elsewhere, so you may want to search for one, but the idea makes sense to me.

Yeah, for one relevant precedent, see the wording about the url param in the https://developer.mozilla.org/en-US/docs/Web/API/URL/URL#url section of the “URL: URL() constructor” article:

A string or any other object with a stringifier that represents an absolute URL or a relative reference to a base URL.

And in that same article, see the note at https://developer.mozilla.org/en-US/docs/Web/API/URL/URL#sect2:

The url and base arguments will each be stringified from whatever value you pass, such as an HTMLAnchorElement or HTMLAreaElement element, just like with other Web APIs that accept a string. In particular, you can use an existing URL object for either argument, and it will be stringified from the object's href property.

[silverwind]

I think we have precedents of doing similar stuff elsewhere, so you may want to search for one, but the idea makes sense to me.

Yeah, for one relevant precedent, see the wording about the url param in the https://developer.mozilla.org/en-US/docs/Web/API/URL/URL#url section of the “URL: URL() constructor” article:

A string or any other object with a stringifier that represents an absolute URL or a relative reference to a base URL.

And in that same article, see the note at https://developer.mozilla.org/en-US/docs/Web/API/URL/URL#sect2:

The url and base arguments will each be stringified from whatever value you pass, such as an HTMLAnchorElement or HTMLAreaElement element, just like with other Web APIs that accept a string. In particular, you can use an existing URL object for either argument, and it will be stringified from the object's href property.

I agree and have changed to use the form "'A string or any other object with a stringifier'" of that wording now.