Provided an input element in a DOM, it does have a textContent property along with value. It is well known that the value of the input is what shown in the text box, and this element cannot have any children, that is <input>something</input> still gives an empty input followed by a sibling text node, whereas closing tag is pletely ignored. But when we set a value to the textContent of this input, it is somehow survives the round-trip:

input.textContent = 'something'
console.log(input.textContent)  // this works

Also, after setting the property, the input appear as having child elements in the inspector:

Maybe it's just me, but I fail to see any logical consistency here. Wouldn't it be nice to have a Type Error on setting text content to the input?

Is there any reasoning behind present behaviour?

Provided an input element in a DOM, it does have a textContent property along with value. It is well known that the value of the input is what shown in the text box, and this element cannot have any children, that is <input>something</input> still gives an empty input followed by a sibling text node, whereas closing tag is pletely ignored. But when we set a value to the textContent of this input, it is somehow survives the round-trip:

input.textContent = 'something'
console.log(input.textContent)  // this works

Also, after setting the property, the input appear as having child elements in the inspector:

Maybe it's just me, but I fail to see any logical consistency here. Wouldn't it be nice to have a Type Error on setting text content to the input?

Is there any reasoning behind present behaviour?

• javascript
• html
• dom

Share Follow asked May 10, 2016 at 15:39 SchmoSchmo 35322 silver badges1111 bronze badges

Add a ment  | 

1 Answer 1

Sorted by: Reset to default 3

The DOM is not HTML, but an API for tree structures that ply with the XML information set Translating <input>something</input> into an input element followed by a text node is the behaviour of the HTML parser, not the behaviour of the DOM.

In fact, if you use XHTML, served as application/xhtml+xml, <input>something</input> will bee an input element with a text node child, the same as using .textContent. So it's entirely normal that .textContent works the way it does.