Allow input controls to indicate significant user interaction

[Michael Strauß]

It's true that a choice needs to be made as to what should be
considered a significant interaction.
This proposal delegates the choice to skins, as that's where these
kinds of choices are generally made.
For example, skins also decide when a button's action is invoked, or
when a context menu opens.
In fact, many of these kinds of semantic choices are internally
represented as behavior classes, which are intrinsically tied to
skins.
Since skins define the behavior of controls, it seems fitting that
they should also define what should be a significant interaction for
the control.
If control authors want to change that, they can create a new skin for
that, the same as what one would do to change any other behavioral
aspect of a control.


On Mon, Mar 27, 2023 at 6:31 PM mkpaz <quizynox at gmail.com> wrote:
>
> I can compare this with Vuetify framework, generally because it uses
> good abstractions. It provides the three types of validation.
>
> 1. Eager - an input is validated immediately after loading (adding to
> the scene). Usually it's initialized with some default valid value to
> not disturb user.
> 2. Input - an input is validated after a user interaction (lazy
> validation). It puts the input to the *dirty state* and that state is
> used to trigger the validation.
> 3. Submit - an input is validated after the form submission.
>
> While it's already possible to implement the second option, one "simply"
> need to subscribe to all focus, keyboard and mouse events and manage the
> dirty state manually, it seems reasonable to delegate this work to the
> skins. The question is what should be considered as a "significant
> interaction". Some implementations set dirty state immediately after the
> input loses focus state, others require some actual keyboard input.