Re: [whatwg] HTML5 Video - Issue and Request for improvment
On Sun, 30 Jan 2011 09:58:41 +0100, Lubomir Toshev lubo_tos...@dir.bg wrote: To elaborate a bit, I'm a control developer and I have my own custom controls. But we want to allow for the customer to use the default browser controls if they want to. This can be done by switching an option in my jQuery widget - browserControls - true/false. Or through browser context menu shown by default on right click. So I'm trying to be flexible enough for the customer. I was thinking about this 1) that adding a transparent overlay over the browser controls Or 2) to detect the click position and if it is some pixels away from the bottom of the video tag will fix this, but every browser has different height for its embedded controls and I should hardcode this height in my code, which is just not manageable. I can always add a limitation when using browser controls, toggle play/pause on video area click will be turned off, but I want to achieve similar behavior in all the browsers no matter whether they use embedded controls or not. So I think this tiny click.target thing will be very useful. See http://lists.w3.org/Archives/Public/public-html/2009Jun/0395.html I suggested that the browser would not generate an event at all when using the native controls. Seemingly there was no reply to Hixie's request for opinion from other implementors. -- Simon Pieters Opera Software
Re: [whatwg] HTML5 Video - Issue and Request for improvment
On Mon, Jan 31, 2011 at 7:17 AM, Simon Pieters sim...@opera.com wrote: See http://lists.w3.org/Archives/Public/public-html/2009Jun/0395.html I suggested that the browser would not generate an event at all when using the native controls. Seemingly there was no reply to Hixie's request for opinion from other implementors. There are other meaningful ways to respond to these events; for example, to pull its container to the top of the draw order if it's a floating window. I should be able to capture mousedown on the container to do this, regardless of content. -- Glenn Maynard
Re: [whatwg] HTML5 Video - Issue and Request for improvment
On Mon, 31 Jan 2011 14:26:49 +0100, Glenn Maynard gl...@zewt.org wrote: On Mon, Jan 31, 2011 at 7:17 AM, Simon Pieters sim...@opera.com wrote: See http://lists.w3.org/Archives/Public/public-html/2009Jun/0395.html I suggested that the browser would not generate an event at all when using the native controls. Seemingly there was no reply to Hixie's request for opinion from other implementors. There are other meaningful ways to respond to these events; for example, to pull its container to the top of the draw order if it's a floating window. I should be able to capture mousedown on the container to do this, regardless of content. How about just suppressing activation events like click? -- Simon Pieters Opera Software
Re: [whatwg] HTML5 Video - Issue and Request for improvment
I totally agree that events should not be raised, when they originate from the native browser controls. This would make it much simpler. I filed the same bug for Opera 11 last week. Thanks, Lubomir Infragistics Inc. -Original Message- From: Simon Pieters [mailto:sim...@opera.com] Sent: Monday, January 31, 2011 2:18 PM To: 'Monty Montgomery'; Lubomir Toshev Cc: wha...@whatwg.org Subject: Re: [whatwg] HTML5 Video - Issue and Request for improvment On Sun, 30 Jan 2011 09:58:41 +0100, Lubomir Toshev lubo_tos...@dir.bg wrote: To elaborate a bit, I'm a control developer and I have my own custom controls. But we want to allow for the customer to use the default browser controls if they want to. This can be done by switching an option in my jQuery widget - browserControls - true/false. Or through browser context menu shown by default on right click. So I'm trying to be flexible enough for the customer. I was thinking about this 1) that adding a transparent overlay over the browser controls Or 2) to detect the click position and if it is some pixels away from the bottom of the video tag will fix this, but every browser has different height for its embedded controls and I should hardcode this height in my code, which is just not manageable. I can always add a limitation when using browser controls, toggle play/pause on video area click will be turned off, but I want to achieve similar behavior in all the browsers no matter whether they use embedded controls or not. So I think this tiny click.target thing will be very useful. See http://lists.w3.org/Archives/Public/public-html/2009Jun/0395.html I suggested that the browser would not generate an event at all when using the native controls. Seemingly there was no reply to Hixie's request for opinion from other implementors. -- Simon Pieters Opera Software
Re: [whatwg] HTML5 Video - Issue and Request for improvment
On Mon, Jan 31, 2011 at 8:34 AM, Simon Pieters sim...@opera.com wrote: On Mon, 31 Jan 2011 14:26:49 +0100, Glenn Maynard gl...@zewt.org wrote: On Mon, Jan 31, 2011 at 7:17 AM, Simon Pieters sim...@opera.com wrote: See http://lists.w3.org/Archives/Public/public-html/2009Jun/0395.html I suggested that the browser would not generate an event at all when using the native controls. Seemingly there was no reply to Hixie's request for opinion from other implementors. There are other meaningful ways to respond to these events; for example, to pull its container to the top of the draw order if it's a floating window. I should be able to capture mousedown on the container to do this, regardless of content. How about just suppressing activation events like click? That makes more sense than suppressing the entire mousedown/mouseup events (and keydown, touchstart, etc). Also, it means you can completely emulate the event behavior of the default browser controls with scripts: preventDefault on mousedown to prevent click events. That's probably not what you actually want to do, but it means the default controls aren't doing anything special: their effect on events can be understood entirely in terms of what scripted events can already do. -- Glenn Maynard
Re: [whatwg] HTML5 Video - Issue and Request for improvment
We were trying to add support for subtitles for our player control that uses
video tag as its base. There are two popular subtitle formats *.srt which
uses currentTime to show the subtitles where they should be. Like 0:01:00 -
0:01:30 - What a nice hotel. While the other popular format is *.sub which
uses the currentFrame to show the proper subtitles. Like {45600}, {45689} -
What a nice hotel. And if I want to add this support it would be good if
video tag exposes currentFrame, so that I can show properly the subtitles in
a span positioned over the video. Now does it make more sense?
I know video will have embedded subtitle support, but I think that it should
be flexible enough to allow building such features like the one above. What
do you think? To me this is worth adding because, it should be really easy
to implement?
Thanks,
Lubo
-Original Message-
From: Eric Carlson [mailto:eric.carl...@apple.com]
Sent: Sunday, January 30, 2011 6:21 AM
To: Lubomir Toshev
Cc: wha...@whatwg.org
Subject: 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
Re: [whatwg] HTML5 Video - Issue and Request for improvment
On Sun, Jan 30, 2011 at 3:58 AM, Lubomir Toshev lubo_tos...@dir.bg wrote: will fix this, but every browser has different height for its embedded controls and I should hardcode this height in my code, which is just not manageable. Even as a bad hack it's simply not possible; for example, there's no way to tell whether a pop-out volume control is open or not. I think the primary use case browser controls are meant for is when scripting isn't available at all. They aren't very useful when you're using any kind of scripts with the video. Another problem, related to your other post about captioning, is that it's impossible to put anything between the video and the controls, so your captions will draw *on top of* browser controls. -- Glenn Maynard
Re: [whatwg] HTML5 Video - Issue and Request for improvment
On Sun, Jan 30, 2011 at 6:44 PM, Lubomir Toshev lubo_tos...@dir.bg wrote:
We were trying to add support for subtitles for our player control that uses
video tag as its base. There are two popular subtitle formats *.srt which
uses currentTime to show the subtitles where they should be. Like 0:01:00 -
0:01:30 - What a nice hotel. While the other popular format is *.sub which
uses the currentFrame to show the proper subtitles. Like {45600}, {45689} -
What a nice hotel. And if I want to add this support it would be good if
video tag exposes currentFrame, so that I can show properly the subtitles in
a span positioned over the video. Now does it make more sense?
If you know the frame rate at which that MicroDVD format was authored,
you can easily calculate the time offset. If you don't know that, a
frame number will not mean anything.
You can also use converters to go from your existing subtitle format
to WebVTT or to a single format that you support - that would probably
make a lot more sense.
Cheers,
Silvia.
[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
