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
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
explicit support for them in
API form would not (imho) be unduly burdensome.
-Jer
Jer Noble jer.no...@apple.com
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
it to be dispatched
when and if the UA denies a full-screen request.
Thanks,
-Jer
Jer Noble jer.no...@apple.com
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
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
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
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
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
the fullscreenchanged event before allowing the user to continue.
-Jer
Jer Noble jer.no...@apple.com
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
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
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
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
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
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]
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
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
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
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
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
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
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
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.
[...]
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
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
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
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
> 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...@
> 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
> 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:
>>>
32 matches
Mail list logo