Re: [whatwg] Implementation difficulties for MediaController

of the broadest use cases. If adding independent playback rates becomes necessary later, adding this support in a future revision will be possible. -Jer  Jer Noble jer.no...@apple.com

Re: [whatwg] Implementation difficulties for MediaController

On Mar 29, 2011, at 9:05 PM, Ian Hickson wrote: On Tue, 29 Mar 2011, Jer Noble wrote: Contained is Eric and my feedback as to the difficulty of implementing this proposal in Apple's port of WebKit: Thank you very much for your feedback. I'll look into it more tomorrow when I update

Re: [whatwg] How to handle multitrack media resources in HTML

explicit support for them in API form would not (imho) be unduly burdensome. -Jer  Jer Noble jer.no...@apple.com

Re: [whatwg] How to handle multitrack media resources in HTML

On Apr 11, 2011, at 5:26 PM, Ian Hickson wrote: On Fri, 8 Apr 2011, Jer Noble wrote: Sorry, by playbackState, I meant readyState. And I was suggesting that, much in the same way that you've provided .buffered and .seekable properties which expose the intersection of the slaved media

[whatwg] Full Screen API Feedback

it to be dispatched when and if the UA denies a full-screen request. Thanks, -Jer  Jer Noble jer.no...@apple.com

Re: [whatwg] Full Screen API Feedback

On May 11, 2011, at 3:03 PM, Jonas Sicking wrote: On Wed, May 11, 2011 at 11:27 AM, Jer Noble jer.no...@apple.com wrote: 3. fullscreenchange events and their targets. The current proposal states that a fullscreenchange event must be dispatched when a document enters or leaves full-screen

Re: [whatwg] Full Screen API Feedback

On May 11, 2011, at 7:41 PM, Robert O'Callahan wrote: On Thu, May 12, 2011 at 6:27 AM, Jer Noble jer.no...@apple.com wrote: 1. Z-index as the primary means of elevating full screen elements to the foreground. The spec suggests that a full screen element is given a z-index of BIGNUM

Re: [whatwg] Full Screen API Feedback

On May 11, 2011, at 11:25 PM, Robert O'Callahan wrote: On Thu, May 12, 2011 at 4:45 PM, Jer Noble jer.no...@apple.com wrote: 2. Animating into and out of full screen. WebKit's current video full-screen support will animate an element between its full-screen and non-full-screen states

Re: [whatwg] Full Screen API Feedback

On May 12, 2011, at 12:31 AM, Boris Zbarsky wrote: On 5/12/11 3:24 AM, Jer Noble wrote: A) If an author calls requestFullScreen(), at some point in the future they will receive either a fullscreenchanged event or a fullscreendenied event. B) If an author calls requestFullScreen(), at some

Re: [whatwg] Full Screen API Feedback

On May 12, 2011, at 12:54 AM, Jer Noble wrote: Surely there's a way to achieve the security benefits you're hoping for without requiring intentionally obtuse API? Okay, here's another proposal that should work with Firefox's passive permission system: Proposal: - Add a new boolean

Re: [whatwg] Full Screen API Feedback

the fullscreenchanged event before allowing the user to continue. -Jer  Jer Noble jer.no...@apple.com

Re: [whatwg] Full Screen API Feedback

On May 12, 2011, at 5:44 AM, Boris Zbarsky wrote: On 5/12/11 3:54 AM, Jer Noble wrote: No, that still doesn't make sense. At the time when the user decides to allow or deny full screen access The point is this may be never. They might just wake forever to make a decision. Saying

Re: [whatwg] Full Screen API Feedback

On May 12, 2011, at 5:47 AM, Boris Zbarsky wrote: On 5/12/11 4:12 AM, Jer Noble wrote: - Add a new boolean Element property canRequestFullScreen. This would map to Firefox's Never permission choice. - Add the fullscreendenied event. This would map to Firefox's Not now permission choice

Re: [whatwg] Full Screen API Feedback

trying to focus in on the full-screen API. Continuing... On May 12, 2011, at 11:24 AM, Boris Zbarsky wrote: On 5/12/11 12:48 PM, Jer Noble wrote: I'm saying that if authors expect to get one or the other but then never do, that will confuse authors. Again, I fail to see how

Re: [whatwg] Full Screen API Feedback

On May 12, 2011, at 4:23 PM, Robert O'Callahan wrote: That only works if the browser can detect a deferral. If the user simply ignores the browser's UI, you wouldn't know when to fire the event. And there's also the issue of a fullscreendenied being followed by a fullscreenchange, which

Re: [whatwg] Proposal: Remove canplaythrough event from audio/video tag

On Nov 1, 2011, at 3:10 PM, Victoria Kirst wrote: - *What are some real examples of how canplaythrough is useful for a web developer?* Even if it were 100% accurate, what is the benefit of the event? Given that it's* not* 100% accurate and that the accuracy is largely up to the

[whatwg] MediaController feedback

Hi, I'm currently working on implementing MediaController in WebKit https://bugs.webkit.org/show_bug.cgi?id=71341, and have a couple pieces of feedback from an implementor's POV: * MediaController Playback State and Ready State The spec defines both a most recently reported readiness state[1]

Re: [whatwg] Firing canplaythrough when caches/buffers are full

On May 27, 2012, at 5:51 PM, Robert O'Callahan rob...@ocallahan.org wrote: I propose fixing this by having the UA enter the HAVE_ENOUGH_DATA readyState when the UA decides to suspend a download indefinitely and the preload state is Automatic (or overriden by autoplay being set). We have

Re: [whatwg] Fullscreen events dispatched to elements

On Jun 1, 2012, at 6:45 PM, Chris Pearce cpea...@mozilla.com wrote: Because we exit fullscreen when the fullscreen element is removed from the document, so if you dispatch events to the context element, the fullscreenchange event never bubbles up to the containing document in the

Re: [whatwg] Fullscreen events dispatched to elements

On Jun 4, 2012, at 10:43 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jun 5, 2012 at 9:13 AM, Jer Noble jer.no...@apple.com wrote: On Jun 1, 2012, at 6:45 PM, Chris Pearce cpea...@mozilla.com wrote: Because we exit fullscreen when the fullscreen element is removed from

Re: [whatwg] MediaController feedback

On Jun 4, 2012, at 5:12 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 2 Nov 2011, Jer Noble wrote: I'm currently working on implementing MediaController in WebKit https://bugs.webkit.org/show_bug.cgi?id=71341, and have a couple pieces of feedback from an implementor's POV

Re: [whatwg] Fullscreen events dispatched to elements

On Jun 4, 2012, at 11:23 PM, Robert O'Callahan rob...@ocallahan.org wrote: If you implemented that proposal as-is then authors would usually need a listener on the document as well as the element, and as Chris pointed out, it's simpler to just always listen on the document. Is that true

Re: [whatwg] Fullscreen events dispatched to elements

On Jun 5, 2012, at 1:06 AM, Anne van Kesteren ann...@annevk.nl wrote: Why should we standardize this if we always notify the document? Is there a benefit to notifying both the element and the document? I think Vincent put forward a reasonable argument. The document is a finite, shared

Re: [whatwg] MediaController feedback

On Jun 5, 2012, at 3:02 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 4 Jun 2012, Jer Noble wrote: This too looks good. We already store the results when we report the controller state, so at a first glance, exposing this property will be trivial. Make sure you're setting

Re: [whatwg] MediaController feedback

On Aug 27, 2012, at 5:02 PM, Ian Hickson i...@hixie.ch wrote: With JavaScript, it's certainly possible for a page author to play() or pause() a slaved media element directly, but that author could just as easily remove the media element from the media group / media controller. [...]

Re: [whatwg] video feedback

On Sep 17, 2012, at 12:43 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 9 Jul 2012, adam k wrote: i have a 25fps video, h264, with a burned in timecode. it seems to be off by 1 frame when i compare the burned in timecode to the calculated timecode. i'm using rob coenen's test app at

Re: [whatwg] video feedback

On Dec 20, 2012, at 7:27 PM, Mark Callow callow.m...@artspark.co.jp wrote: On 2012/12/21 2:54, Ian Hickson wrote: On Thu, 20 Dec 2012, Mark Callow wrote: I draw your attention to Don't Store that in a float http://randomascii.wordpress.com/2012/02/13/dont-store-that-in-a-float/ and its

Re: [whatwg] Background audio channels

On Mar 15, 2013, at 10:57 AM, Wesley Johnston wjohns...@mozilla.com wrote: In most situations, when the user puts a webpage in the background, any media being played by the page should be paused. Any attempts to play audio by a background page should also be prevented. However, for some

Re: [whatwg] Background audio channels

On Apr 10, 2013, at 12:14 PM, Wesley Johnston wjohns...@mozilla.com wrote: Again, IMO 1.) The EVENTUAL default behavior here has to be to mute tabs in the background. I disagree. The current default behavior (allowing audio to play in the background) is working just fine for Safari. Maybe

Re: [whatwg] VIDEO and pitchAdjustment

> On Mar 11, 2016, at 1:11 PM, Garrett Smith <dhtmlkitc...@gmail.com> wrote: > > > > On Tuesday, March 8, 2016, Jer Noble <jer.no...@apple.com > <mailto:jer.no...@apple.com>> wrote: > > > On Mar 8, 2016, at 4:42 PM, Garrett Smith <dhtmlkitc...@

Re: [whatwg] VIDEO and pitchAdjustment

> On Mar 1, 2016, at 8:00 PM, Philip Jägenstedt wrote: > > On Wed, Mar 2, 2016 at 9:19 AM, Garrett Smith wrote: >> On Thu, Nov 12, 2015 at 11:32 AM, Philip Jägenstedt >> wrote: >>> On Thu, Nov 12, 2015 at 10:55 AM, Garrett Smith

Re: [whatwg] VIDEO and pitchAdjustment

> On Mar 4, 2016, at 3:19 PM, Garrett Smith <dhtmlkitc...@gmail.com> wrote: > > On Fri, Mar 4, 2016 at 1:55 PM, Jer Noble <jer.no...@apple.com> wrote: >> >>> On Mar 1, 2016, at 8:00 PM, Philip Jägenstedt <phil...@opera.com> wrote: >>>