KHR_node_hoverability Draft Proposal

[lexaknyazev]

As discussed in the Interactivity DTSG; very similar to #2422.

[emackey]

I wasn't part of the original discussion, but I'm surprised this is entirely separate from selection. I'm struggling to think of a valid modern UX design where hovering was enabled on an object where it and all of its descendants were non-selectable, or the other way around. I can think of a few cases where selection was ignored (but not disabled), for example hovering a fly-out card of some kind that reveals more info and maybe some links, but those links are clickable, they can't have selection disabled. Disabling an event for all descendants is much more heavy-handed than just not placing an event handler on something. So even those fly-out cards would not need this level of separation of glTF extensions, just separate event handlers.

In the interests of reducing complexity, why is this separate extension from selection? Why is it independently controllable from selection? When would one disable hovering for descendants but leave selection enabled? When would one disable selection events for descendants but retain hovering?

If these questions were covered during design, I would recommend copying some of the reasoning into the extension body, as I'm sure I won't be the only one curious about this.

[lexaknyazev]

In the interests of reducing complexity, why is this separate extension from selection?

It's a valid concern and the answer is more formal than practical. The selectability extension is not a part of the KHR_interactivity extension because:

1. It is possible to use behavior graphs without any user input, e.g., as a "procedural animation" system driven by frame times, so event/onSelect is not included there.
2. Some members expressed interest in a standalone selectable flag to use it with their own interactivity-like features without necessarily implementing KHR_interactivity.

Having both selectable and hoverable flags in the same extension object would require implementations to support both, which is not guaranteed.

---

Why is it independently controllable from selection?

Hover events may be used just for visual effects without responding to clicks/taps. Disabling event handlers may be a performance optimization, e.g., depending on distance.

[javagl]

I'd have to allocate some time, and/or create a 'diff' of the respective README.md files, to see whether there are significant structural differences between this, selectability, and visibility.

But... exactly this similarity is the reason why I have to ask a much higher-level question, affecting all of them. (And I probably should have brought that up earlier, and would have done so if all these PRs would have been opened in a narrower time frame).

The question is, at this point: Why not just introduce some KHR_node_flags extension?

We have visible, selectable, hoverable... I could imagine that things like highlighted and pressed, and has_the_favorite_color_of_the_user are only a matter of time.

(I'm usually opposed to representing something like "an object being 'selected'" as a boolean flag within the object on the implementation level - but that may be a different topic).

The point is: This approach - one extension for each boolean property - does not seem to scale.

I'm lacking context from the discussion during the design phase. And there are likely good, profound, technical reasons why this path was taken (and some of them have been addressed in the previous comment).
But I still would like to ask this question, and maybe better understand what the reasons are.

[lexaknyazev]

Why not just introduce some KHR_node_flags extension?

• An extension must have a finite scope and "things like highlighted and pressed ... are only a matter of time".
• Selectability and hoverability extensions define interactivity events unlike the visibility extension.
• Hoverability extension has a slightly different propagation rule.

[javagl]

I'm not sure what "finite scope" refers to, but assume that it is the question about how a meaning is assigned to each flag (except for tossing around some strings like "hoverable" somewhere). Indeed, that's an open question.

Selectability and hoverability extensions define interactivity events unlike the visibility extension.

Which could raise the question of whether there shouldn't be event/onBecameVisible and event/onBecameInvisible.

I'll have to take a closer look at the differences of the propagation rules.

(But I hope that it's still OK to ask such a devil's advocate question once in a while, even when it was very high-level for now...)