fix: make <select>
<option value>
behavior consistent
#12316
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Setting the
value
attribute of an<option>
element to a falsy value should result in the empty string. This wasn't happening in all situations previously. Fixes #11616While this fixes the behavior, I'm also somewhat questioning whether or not this should be the way it works. In other situations a falsy value means removing the attribute. In this case it's not. On the other hand for
value
oninput
elements it's the same behavior and it makes sense there, mostly because the value property is not reflected as an attribute - but for option elements it is. So there are arguments both in favor and against this behavior. Either way, it should be consistent, and this makes it consistent with the Svelte 4 behavior (and fixes the spreading inconsistency that was also present in Svelte 4)Side note: During this I checked what the
value
attribute does for different elements. It's ... really different by element, to say the least:Before submitting the PR, please make sure you do the following
feat:
,fix:
,chore:
, ordocs:
.Tests and linting
pnpm test
and lint the project withpnpm lint