Open TimvdLippe opened 3 years ago
Previous occurrences of this kind of issue:
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 😄
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.
Ah right. Yes I understand that now. Thanks again for the explanation!
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
).
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.
Tracking at #2521. We can update the lib once that's checked in
Bug Report
🔎 Search Terms
image src dom
🕗 Version & Regression Information
⏯ Playground Link
Playground link with relevant code
💻 Code
🙁 Actual behavior
🙂 Expected behavior
Compiles cleanly (confirmed supported per https://github.com/whatwg/html/issues/6440)