[whatwg] HTML5 Video - Issue and Request for improvment
Hi all, I've submitted the following bug to Chrome Opera browsers: http://code.google.com/p/chromium/issues/detail?id=70778 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? Another thing that I see as a limitation is that video should expose API for currentFrame, so that when control developers want to add support for subtitles on their own, to be able to support formats that display the subtitles according to the current video frame. This is a limitation to the current design of the video tag. Thanks, Lubomir Toshev
Re: [whatwg] HTML5 Video - Issue and Request for improvment
On Sat, Jan 29, 2011 at 6:21 AM, Lubomir Toshev lubo_tos...@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?
Re: [whatwg] HTML5 Video - Issue and Request for improvment
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. You can do it by writing your own controls for an overlay div. It's not as involved as it sounds. One of the demos at OVC this past fall was a ten-minute demo of writing full custom controls from scratch, including drawing the buttons, etc. Monty
Re: [whatwg] HTML5 Video - Issue and Request for improvment
On Jan 29, 2011, at 3:21 AM, Lubomir Toshev wrote: Another thing that I see as a limitation is that video should expose API for currentFrame, so that when control developers want to add support for subtitles on their own, to be able to support formats that display the subtitles according to the current video frame. This is a limitation to the current design of the video tag. I don't understand what you are suggesting, what would currentFrame return and how exactly would you use it? eric
