W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

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

From: Elliott Sprehn <esprehn@chromium.org>
Date: Thu, 22 Aug 2013 10:21:02 -0700
Message-ID: <CAO9Q3iKwpDwFpxaQOBeeg7SQZJR+9rmAVbobF7QU7jcHcO7Uhg@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>, Erik Arvidsson <arv@chromium.org>, Dimitri Glazkov <dglazkov@chromium.org>
Cc: WHAT Working Group <whatwg@whatwg.org>, Philip Jägenstedt <philipj@opera.com>, Simon Pieters <simonp@opera.com>
On Thu, Aug 22, 2013 at 10:03 AM, Elliott Sprehn <esprehn@chromium.org>wrote:

> On Tue, Aug 6, 2013 at 2:30 PM, Ian Hickson <ian@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
Received on Thursday, 22 August 2013 17:22:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC