3 ms·
But "checked" on a text input isn't undefined; it exists and is false. It's not the same as just being able to hang arbitrary crap on any DOM node; it exists in
by apendleton 11y ago
But "checked" on a text input isn't undefined; it exists and is false. It's not the same as just being able to hang arbitrary crap on any DOM node; it exists in the API, and some other nonsensical input properties don't and are undefined, and still others throw errors when you try to access them. It's bonkers API inconsistency that can reasonably be called out.
- myfonj 11y agoIʼm not defending the API, and I admit I was commenting without proper understanding here, so yes, you are right that that property is really defined as false. But Iʼd like to correct your statement about 'some defined some undefined' properties. Fact is that all [HTMLInputElement] interface instances no mater what [type] they are shares exactly the same set of properties. And because that "type" is also just one of the them you can for example convert password input into text input and text input into checkbox just by setting itʼs @type value: data:text/html,<input id=i type=text checked><script>document.write(i.multiple);i.type='checkbox'</script> Yes, it is weird and in retrospect it seems silly that there are not extra interface for each type of input (there is no HTMLRadioButton interface for <radio> tag DOM elements inheriting from some abstract HTMLFormElement interface). Perhaps some witness of standardizing process have good argument for that. (My guess it something like "Oooh, so many Elements, that means so many tags, no, letʼs keep that simple, ok? They are mostly similar anyway.") [HTMLInputElement]: https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputEl... [type]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-type https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...