Image element src property does not allow URL assignment

[TimvdLippe]

Bug Report

🔎 Search Terms

image src dom

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about 4.3.0

⏯ Playground Link

Playground link with relevant code

💻 Code

let image = document.createElement('img');
image.src = new URL("http://google.com");
console.log(image.src)

🙁 Actual behavior

Type 'URL' is not assignable to type 'string'.(2322)

🙂 Expected behavior

Compiles cleanly (confirmed supported per whatwg/html#6440)

[TimvdLippe]

Previous occurrences of this kind of issue:

• new URL() does not take URL object as base parameter #15246 (comment)
• Allow URL in ServiceWorkerContainer#register TypeScript-DOM-lib-generator#965 IDL: https://github.com/microsoft/TypeScript-DOM-lib-generator/blob/78a230840d46b3cd30a19e8ce5a2dcada6162ce3/inputfiles/idl/Service%20Workers.widl#L58
• Allow URLs in Worker constructor TypeScript-DOM-lib-generator#600 IDL: https://github.com/microsoft/TypeScript-DOM-lib-generator/blob/78a230840d46b3cd30a19e8ce5a2dcada6162ce3/inputfiles/idl/HTML%20-%20Web%20workers.widl#L44

At this point, should we assume that USVString implies string | URL? The handling of USVString is currently implemented in https://github.com/microsoft/TypeScript-DOM-lib-generator/blob/07ea4e8bf58f9907d22024cca6433e002fffd251/src/helpers.ts#L6 I am not sure how many other IDL definitions use USVString, but wouldn't accept a URL (which would be implicitly .toString'd per the linked HTML issue)

CC @domenic do you mind confirming if we can assume type USVString = string | URL in TypeScript or am I still misunderstanding the terminology here 😄

[domenic]

It's more subtle than that. Every DOMString or USVString will convert any input to a string. Technically, everything in JavaScript is convertible to a string, at the very least through Object.prototype.toString(). So hard-coding URL doesn't make sense to me.

[TimvdLippe]

Ah right. Yes I understand that now. Thanks again for the explanation!

[DanielRosenwasser]

You want separate types for reading and writing properties, which @RyanCavanaugh is iterating on over at #42425.

I guess we did discuss a few things in a previous design meeting about how much of lib.d.ts needed to change and punted on it, but this seems like a reasonable one (write of URL | string, read of string).

[DanielRosenwasser]

So hard-coding URL doesn't make sense to me.

We'd want to be more permissive to a degree; letting anything in with a toString() seems undesirable, whereas unblocking a scenario like assigning URL instances to a property called url the src property seems reasonable.

[RyanCavanaugh]

Tracking at #2521. We can update the lib once that's checked in