Re: [whatwg] VIDEO and pitchAdjustment

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

Re: [whatwg] VIDEO and pitchAdjustment

> On Mar 4, 2016, at 3:19 PM, Garrett Smith wrote: > > On Fri, Mar 4, 2016 at 1:55 PM, Jer Noble wrote: >> >>> On Mar 1, 2016, at 8:00 PM, Philip Jägenstedt wrote: >>> >>> On Wed, Mar 2, 2016 at 9:19 AM, Garrett Smith >>> wrote: >&

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 >>> wrote: On 11/12/15, Philip Jägenstedt wrote: > On

Re: [whatwg] Background audio channels

On Apr 10, 2013, at 12:14 PM, Wesley Johnston 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 to play in the background) is working just fine for Safari. Maybe it isn't for Gecko, but

Re: [whatwg] Background audio channels

On Mar 15, 2013, at 10:57 AM, Wesley Johnston 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 sites (music or > rad

Re: [whatwg] feedback

On Dec 20, 2012, at 7:27 PM, Mark Callow 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 >>> " >>> and its suggestion to

Re: [whatwg] feedback

On Sep 17, 2012, at 12:43 PM, Ian Hickson 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 >> http:

Re: [whatwg] MediaController feedback

On Aug 27, 2012, at 5:02 PM, Ian Hickson 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] MediaController feedback

On Jun 5, 2012, at 3:02 PM, Ian Hickson 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

Re: [whatwg] Fullscreen events dispatched to elements

On Jun 5, 2012, at 1:06 AM, Anne van Kesteren 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 resource. Requiring

Re: [whatwg] Fullscreen events dispatched to elements

On Jun 4, 2012, at 11:23 PM, Robert O'Callahan 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 for the Webkit i

Re: [whatwg] MediaController feedback

On Jun 4, 2012, at 5:12 PM, Ian Hickson 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

Re: [whatwg] Fullscreen events dispatched to elements

On Jun 4, 2012, at 10:43 PM, Robert O'Callahan wrote: > On Tue, Jun 5, 2012 at 9:13 AM, Jer Noble wrote: > On Jun 1, 2012, at 6:45 PM, Chris Pearce wrote: > > > Because we exit fullscreen when the fullscreen element is removed from the > > document, so if you disp

Re: [whatwg] Fullscreen events dispatched to elements

On Jun 1, 2012, at 6:45 PM, Chris Pearce 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 > exit-on-remove case.

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

On May 27, 2012, at 5:51 PM, Robert O'Callahan 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 checked in a p

[whatwg] MediaController feedback

Hi, I'm currently working on implementing MediaController in WebKit , 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"

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 di

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",

Re: [whatwg] Full Screen API Feedback

responding to some of the points raised below. I'm not trying to be evasive in doing so, but just 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 a

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 "fullscreend

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 for

Re: [whatwg] Full Screen API Feedback

ust require the "fullscreenchanged" event before allowing the user to continue. -Jer  Jer Noble

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: Propos

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"

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 wrote: > > > 2. Animating into and out of full screen. > > > > WebKit's current video full-screen support will animate an element between > > its full-

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 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 3:03 PM, Jonas Sicking wrote: > On Wed, May 11, 2011 at 11:27 AM, Jer Noble wrote: >> 3. "fullscreenchange" events and their targets. >> >> The current proposal states that a "fullscreenchange" event must be >> dispatch

[whatwg] Full Screen API Feedback

akes failing over to another full screen technique (such as a "full-window" substitute mode) impossible. Proposal: add a "fullscreenrequestdenied" event and require it to be dispatched when and if the UA denies a full-screen request. Thanks, -Jer  Jer Noble

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 "

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

As are likely going to have do these calculations anyway to support things like autoplay, so adding explicit support for them in API form would not (imho) be unduly burdensome. -Jer  Jer Noble

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

Re: [whatwg] Implementation difficulties for MediaController

27; playback rate and current time to a single master media element, Silvia and Eric's proposal, seems to achieve the needs 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