- From: Lubomir Toshev <lubo_toshev@dir.bg>
- Date: Mon, 31 Jan 2011 22:03:49 +0200
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:simonp@opera.com] Sent: Monday, January 31, 2011 2:18 PM To: 'Monty Montgomery'; Lubomir Toshev Cc: whatwg at whatwg.org Subject: Re: [whatwg] HTML5 Video - Issue and Request for improvment On Sun, 30 Jan 2011 09:58:41 +0100, Lubomir Toshev <lubo_toshev at 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
Received on Monday, 31 January 2011 12:03:49 UTC