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

Point taken about string enums. Didn't know that.

I'm not trying to feature creep here, nor am I proposing that every single
complex input needs this kind of stuff. I'm just proposing that we think
more generally to help break some assumptions. Tab makes a number of
correct and useful points about the number controls which also apply to
video. If you read the spec on the "controls" attribute/property for media
elements (
http://www.w3.org/TR/html5/embedded-content-0.html#attr-media-controls),
there's no guarantee which specific controls are available or even that the
controls are rendered on top of the video, only that "the user agent should
expose a user interface to the user." I can easily imagine some very
different interfaces, especially if you consider non-desktop platforms like
TVs, phones, wristwatches, etc. The controls could be in a browser chrome
toolbar or even in hardware, for example.

So, perhaps we need a separate set of events. So, when a user clicks the
play button, events would fire in this order:
1. play requested by user agent from some UI. Cancelable.
2. 'play' event. The browser has been asked to play the video, whether by
the UI or by API.
3. 'playing' event. After all the network magic has happened, the video is
actually playing.




On Wed, Aug 21, 2013 at 10:45 AM, Simon Pieters <simonp@opera.com> wrote:

> On Wed, 21 Aug 2013 16:21:25 +0200, Brian Chirls <brian.chirls@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?
>>
>
> What happens when you do that? If nothing happens, it seems like
> controlsTarget should return null.
>
>
>  What about an enum-esque integer constant instead of a string? Like
>> HTMLMediaElement.PLAY_BUTTON, etc.
>>
>
> Integer constants are usually avoided for new stuff.
>
>
>  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.
>>
>
> Let's start from use cases instead of feature creeping a solution for one
> thing to all other things that have similar shape. I'd rather simplify
> controlsTarget to be a boolean since that also addresses the problem at
> hand.
>
>
> --
> Simon Pieters
> Opera Software
>

Received on Wednesday, 21 August 2013 15:57:52 UTC