[Feature Request] block native form events and properties

[LarsDenBakker]

I was using the change event in a couple of places in my code. This causes different results across browsers, using model-value-changed fixed it.

Perhaps it would be a good idea to prevent leaking any native events and exposing any native properties that should not be used.

[tlouisse]

I like the idea: it makes our api simpler and more predictable.
The philosophy behind our form system is indeed to have one normalized api for all form controls.

We definitely need to create documentation for best practices and propagate the use of .modelValue and @model-value-changed only.

If we would block native events(which we could consider for a next breaking release), we would actually loose some information, since @model-value-changed ≈≈ @input, but (for a regular text field) @change ≈≈ @blur && (/*input value was changed since user focused the input*/). The question would be whether the native change functionality still would be needed by application developers, since it serves a slightly different purpose than @model-value-changed.

Questions

• How is the change event exactly behaving different across browsers? We should document this and might consider normalizing ourselves.
• Which properties do you want to block? Currently our form controls try to adhere to the platform api by delegating properties. Things like placeholder we already block (for a11y, you should use something like a floating label instead).

[LarsDenBakker]

Good point about change being fired also in blur. I used change to detect input changes and reflect it back to a property like so:

<lion-checkbox 
  .choiceChecked=${this.checked} 
  @change=${(e) => this.checked = !this.checked}
></lion-checkbox>

On IE11 this didn't work correctly, changing the checkbox caused it to flip back to it's initial state. Changing this to model-value-changed fixed it, so I didn't look further into it. But my guess is that change was fired before the internal state of the checkbox updated.

[tlouisse]

Good catch. Looking at the code, I think we listen for an input event internally (in FormatMixin). Based on that the model-value-changed fires. Maybe IE fires the change event first, followed by the input event, whereas other browsers do it the other way around? We've seen similar deviations in the <select>, not firing an input event on IE at all

[erikkroes]

Hi,

We are closing this issue because we're changing the way we handle feature requests. Your issue will get the "votes needed" label, and people can add 👍 reactions to vote and show interest. It will be reopened when this feature gets picked up.

This we way we clearly focus on bugs in our open issues. At the same time we can see what community interest there is for new features.

Thanks!

[daKmoR]

sounds like a good idea 💪