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

Elliott Sprehn esprehn at chromium.org
Thu Aug 22 10:21:02 PDT 2013

On Thu, Aug 22, 2013 at 10:03 AM, Elliott Sprehn <esprehn at chromium.org>wrote:

> On Tue, Aug 6, 2013 at 2:30 PM, Ian Hickson <ian at hixie.ch> wrote:
>> On Thu, 27 Jun 2013, Philip Jägenstedt wrote:
>> >
>> > In a discussion about a "click to play/pause" feature for Opera on
>> > Android, the issue of click event handlers came up.[1] The problem is
>> > that pages can do things like this:
>> >
>> > ...
>> I've made the spec say this is a valid (and recommended) implemenation
>> strategy.
> This means that if I have <video controls> on the page and then I click
> something that shows a non-modal dialog that should dismiss on clicking
> elsewhere in the page, and then click the video the page popup doesn't
> disappear.
> Should authors be listening for mouseup instead to take actions when users
> click inside <video>?
I see now that even this isn't possible:


If the user agent exposes a user interface to the user by displaying
controls over the media element, then the user agent should suppress any
user interaction events while the user agent is interacting with this
interface. (For example, if the user clicks on a video's playback control,
mousedown events and so forth would not simultaneously be fired at elements
on the page.)

This is wrong, it means I have no way to tell if you click inside the
<video> to dismiss popups or notifications. I don't think we should be
making <video controls> a blackhole to events, it breaks lots of use cases.

Instead we should expose the controls as a pseudo element on the event,
just like TransitionEvent has a String pseudoElement so you can tell if the
thing transitioning is the "::before" or the "::after", we should add
::controls and inside the click handler you can take no action if the
target is the controls. If we assume the new Shadow DOM spec, we could just
use the "part" feature which was designed specifically for this kind of
thing and should be exposed on all events.

(User agents don't need to actually allow styling using the ::controls
pseudo element)

I already raised a bug about adding this to all MouseEvents specifically to
handle cases like this:

- E

More information about the whatwg mailing list