[whatwg] Should <video controls> generate click events?

[Tab Atkins Jr.]

On Wed, Aug 21, 2013 at 7:21 AM, Brian Chirls <brian.chirls at gmail.com> wrote:
> Okay, that is much more clear. Thank you.
>
> Yes, I think adding information to the click event is a great approach.
> Event objects often have additional information, like mouse coordinates or
> key code, so it wouldn't feel like an unusual or special case. The previous
> approach removes information, where this one adds it. Let's not forget that
> the same information should apply to touch and hover events as well.
>
> Although, how would you handle the case where a user clicks the mouse down
> on the play button, drags it off the play button and then on to, say, the
> fullscreen button before letting go?

The click event doesn't fire until the mouseup occurs, and then it
fires on the element at that time.  This matches OS conventions, which
let you drag a mistaken click somewhere safe before releasing.

The problem with trying to use click, even with additional
information, is that *the UA-defined controls are unknown*.  Maybe
they have a play-pause button.  Maybe they've only got a scrubber, and
rely on clicking on the face to play/pause.  Maybe they do something
quite different.  The HTML spec makes *zero* guarantees about what's
inside of that, which is *intentional*.

The correct thing to do is listen for the defined events which
indicate that a particular state has changed.  I can't think of a
reasonable use-case for wanting to know which button was clicked that
isn't solved at least as well by just listening for the event for the
state change.

> What about an enum-esque integer constant instead of a string? Like
> HTMLMediaElement.PLAY_BUTTON, etc.

Strings are how the web platform does enums - WebIDL even has support
for this in its syntax now.  Integer-based enums are broken legacy
horribleness.

> It's worth thinking about whether this can/should be generalized to all
> elements that have sub-controls. For example, a number input has those
> little up and down buttons.

Again, no, there's no guarantee whatsoever that a number input has
little up and down buttons.  On a mobile device, it might have no
particular controls, and when you click on it, it exposes a modal
thing with a flickable wheel.  In particular, my phone (an Android
running latest stock OS) exposes it as a plain text control, and when
you click on it, it brings up a number-pad virtual keyboard rather
than a qwerty one.

~TJ