Let's have, say, an element with the text content of Clark, Theodore S.
. Note the double white spaces after the "Theodore". Say you have this element be an HTML option, like this: <option>Clark, Theodore S.</option>
. If you try to extract its text content, you would correctly get the result Clark, Theodore S.
. However, if you try to get the option's value
property, you get Clark, Theodore S.
.
As per MDN's docs, white spaces are often times ignored when formatting the DOM. However, wouldn't it be logical to have the textContent
property return the trimmed value and the value
property return the exact value? As far as I know, when you get the value
of an input element no trimming is performed, so why is it done here?
Why is the value
property modified in any way when it is expected that it would most accurately reflect the actual value set? Is this a bug in JavaScript or is it explicitly intended?
It's because in the absence of a value
attribute, the .text
value is used as the <option>
's value.
From the specs for HTMLOptionElement.prototype.text
The
text
IDL attribute, on getting, must return the result of stripping and collapsing ASCII whitespace from the concatenation of data of all theText
node descendants of theoption
element, in tree order, excluding any that are descendants of descendants of theoption
element that are themselvesscript
orSVG script
elements.
Thanks to this, we can write stuff like the following and still have the value foo bar
being sent to the server as is likely expected.
const el = document.querySelector("option");
console.log(el.text, el.text === el.value);
console.log(el.textContent);
<select>
<option>
foo
bar
<script>
// Something
</script>
</option>
</select>