- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Sat, 29 Jan 2011 19:23:40 -0500
On Sat, Jan 29, 2011 at 6:21 AM, Lubomir Toshev <lubo_toshev at dir.bg> wrote: > And it was closed as won't fix because the behavior is expected. I think it > should be changed. A brief description of the problem is that when the video > tag has embedded browser controls displayed and I click anywhere on the > controls, they cause a video tag click event. If I want to toggle play/pause > on video area click, then I cannot do this, because clicking on the play > control button, fires play, then click event fires for video tag and when I > toggle It pauses. So this behavior that every popular flash player has > cannot be achieved. There is no way to understand that the click.target is > the embedded browser controls area. I think that a nice improvement will be > to expose this information, in the target, that it actually is embedded > browser controls. Or clicking the embedded browser controls should not > produce a click event for video tag. After all browser controls are native > and do not have representation in the DOM. Let me know what do you think > about this? Well, to begin with, you could just use your own controls rather than the browser's built-in controls. Then you have no problem. If you're using the browser's built-in controls, maybe you should stick with the browser's control conventions throughout, which presumably doesn't include toggling play/pause on click. I'm not sure this is a broad enough problem to warrant exposing the extra information in the target. Are there any other use-cases for such info?
Received on Saturday, 29 January 2011 16:23:40 UTC