5 ms·

Ad `textInput.checked = true;`, this quite a misconception. You can totally set `anyDOMnode.whateverProperty = 'batman'` and retrieve it back. Itʼs just few s

by myfonj 11y ago

Ad `textInput.checked = true;`, this quite a misconception. You can totally set `anyDOMnode.whateverProperty = 'batman'` and retrieve it back. Itʼs just few special DOM object properties that are mapped to HTML attributes on certain types of elements that actually do something meaningful, like the @checked property of HTMLinputElement objects that happen to have @type="checkbox".

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 ago
  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...
X-Cubed 11y ago
So why does it default to a value of false in her example? Shouldn't it return undefined if that were the case?

by myfonj 11y ago

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 ago
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...

X-Cubed 11y ago

So why does it default to a value of false in her example? Shouldn't it return undefined if that were the case?