You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd expect the inputs value to be preserved since nothing changed and an inputs value is only loosely coupled to the attribute of the same name, similar to the play state of a video.
According to this part the value of an input is reset if
the new content (from) does not have a value attribute
the beforeAttributeUpdate callback does not return false
Imho it would be better to simplify this to a mismatch in the value attribute like this:
I'd be glad to open a PR if you agree with the premise of this issue and if you tell me how to run your test suite 😉 - because I only got a conn refused from mocha-chrome 😅
hey @hesxenon I htink this should at least be an option. we are in the process of reworking the test suite, are you OK with revisiting it when we are done? Probably early 2025 timeframe?
Since it is possible(-ish) to work around this feel free to close this issue, but imho the current behaviour around input values is wrong/confusing.
Consider the following structure:
If I type something into this input and then do
I'd expect the inputs value to be preserved since nothing changed and an inputs
value
is only loosely coupled to the attribute of the same name, similar to the play state of a video.According to this part the value of an input is reset if
from
) does not have avalue
attributebeforeAttributeUpdate
callback does not return falseImho it would be better to simplify this to a mismatch in the value attribute like this:
meaning that the behaviour can be depicted as the following table
to
(existing)from
(new content)from
from
The text was updated successfully, but these errors were encountered: