On Tue, Feb 8, 2011 at 6:57 PM, Silvia Pfeiffer
silviapfeiff...@gmail.comwrote:
Hi Philip, all,
On Sun, Jan 23, 2011 at 1:23 AM, Philip Jägenstedt phil...@opera.com
wrote:
On Fri, 14 Jan 2011 10:01:38 +0100, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
5. Ability to move captions
On Wed, Feb 16, 2011 at 10:23 AM, Kevin Marks kevinma...@gmail.com wrote:
Moving them only within the video viewport is a bug, not a feature.
Of note, the big tv we had in 2000 (probably purchased circa 1998) at
a college communal area would display captions for the PIP window
below the PIP. So
On Wed, Feb 16, 2011 at 9:27 PM, timeless timel...@gmail.com wrote:
On Wed, Feb 16, 2011 at 10:23 AM, Kevin Marks kevinma...@gmail.com wrote:
Moving them only within the video viewport is a bug, not a feature.
Of note, the big tv we had in 2000 (probably purchased circa 1998) at
a college
On 2011/02/16 00:23 (GMT-0800) Kevin Marks composed:
Classic TV required this (especially with overscan), but on modern TV's
there is often a letterbox or pillarbox are that captions should go in. On
a decent-sized computer screen, there is no real excuse for obscuring the
video with the
On Wed, Feb 16, 2011 at 2:36 PM, Anne van Kesteren ann...@opera.com wrote:
This is just a thought. Instead of acquiring a Stream object asynchronously
there always is one available showing transparent black or some such.
:)
E.g.
navigator.cameraStream. It also inherits from EventTarget. Then
On Feb 15, 2011 6:34 PM, Nicholas Zakas nza...@yahoo-inc.com wrote:
1) Should the default behavior for dynamic script nodes be to start
downloading the file upon the setting of src and only execute when added to
the document (IE's behavior) or not?
Could the default behavior be defined by the
Hi Anne,
On Wed, Feb 16, 2011 at 12:36 PM, Anne van Kesteren ann...@opera.com wrote:
On Tue, 15 Feb 2011 17:48:24 +0100, Leandro Graciá Gil
leandrogra...@chromium.org wrote:
All feedback will be greatly appreciated.
This is just a thought. Instead of acquiring a Stream object asynchronously
Andrei Popescu wrote:
Hi Anne,
On Wed, Feb 16, 2011 at 12:36 PM, Anne van Kesterenann...@opera.com wrote:
On Tue, 15 Feb 2011 17:48:24 +0100, Leandro Graciá Gil
leandrogra...@chromium.org wrote:
All feedback will be greatly appreciated.
This is just a thought. Instead of acquiring a Stream
On Tue, Feb 15, 2011 at 9:42 AM, Bjartur Thorlacius svartma...@gmail.comwrote:
2. When a user decides to use it, they have to follow a set of complex
instructions (http://www.google.com/search?q=switch+default+search+engines
)
Annoying implementation issue.
I agree with this sentiment, the specification should simply state the
returned values are guaranteed to be cryptographically secure, that's all that
needs to be said. There is no need to describe how this is implemented, if an
implementation provides predictable values then that
On Wed, Feb 16, 2011 at 9:28 AM, Will Alexander
serverherder+wha...@gmail.com wrote:
In this bug report Boris Zbarsky expresses concern that prefetching without
creating memory leaks is difficult.
https://bugzilla.mozilla.org/show_bug.cgi?id=621553
Possibly related:
Silvia, all,
We're working with multitrack MPEG transport streams, and have an
implementation of the TimedTrack interface integrating with in-band metadata
tracks. Our prototype uses the Metadata Cues to synchronize a JavaScript
application with a video stream using the stream's embedded EISS
On Wed, Feb 16, 2011 at 11:36 AM, Oliver Hunt oli...@apple.com wrote:
I agree with this sentiment, the specification should simply state the
returned values are guaranteed to be cryptographically secure, that's all
that needs to be said. There is no need to describe how this is
implemented,
Hi Eric,
I'm curious: if you are using @kind=metadata - which is not
generically applicable, but only has application-specific data in it -
then this implies that the web page knows what type of data is in the
track's cues and knows how to parse it. Why do you need a mime type on
the cues then?
On Mon, Feb 14, 2011 at 8:03 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
but we're now talking about a pure ECMAScript function so DOM conventions
shouldn't be applicable. But consistency with common JavaScript practices
should be.
If you want to apply it to an already allocated array
So, let's get back to the design of an actual ECMAScript API.
I'll repeat a couple of initial points:
We are now talking about a pure JavaScript API, not a DOM API so it should
follow JavaScript conventions.
If we want this to appear in browsers in the very near future we should
minimize any
BTW, there seems to be significant interest around this subject here:
http://code.google.com/p/chromium/issues/detail?id=73226
w.r.t. the below, binary data types seem important for getting
randomness right. In particular, using strings is bad news bears. We
have binary data types available in
Also note that that bug is accumulating use cases that might be worth
considering in this effort. As an example, many banks in various
parts of Asia require the use of ActiveX controls in IE. One could
hope that the web platform could provide those sorts of facilities
natively.
Adam
On Wed,
On Wed, Feb 16, 2011 at 4:29 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
So, let's get back to the design of an actual ECMAScript API.
I'll repeat a couple of initial points:
We are now talking about a pure JavaScript API,
Good stuff.
Recall that part of what started this is
On Feb 16, 2011, at 4:54 PM, David Herman wrote:
I say: let's make it typed array in the short term, but TC39 will spec it as
an array of uint32 according to the binary data spec. We will try to make the
binary data spec as backwards compatible as possible with typed arrays
anyway. So in
On Thu, Feb 17, 2011 at 08:29, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Array.randomFill= function (length){...};
This would create a new array of the specified length where each element is a
random value in some range. I propose that this range be 0..65535 as these
are easily
21 matches
Mail list logo
