Iʼ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.

Iʼ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...