On Thu, Jul 16, 2015 at 8:44 PM, Philip Jägenstedt phil...@opera.com
wrote:
OK, so perhaps file two bugs for each of those things and continue
discussion there?
I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28956.
Rob
--
lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e
On Thu, Jul 16, 2015 at 4:32 AM, Robert O'Callahan rob...@ocallahan.org wrote:
On Thu, Jul 16, 2015 at 1:59 AM, Philip Jägenstedt phil...@opera.com
wrote:
On Wed, Jul 15, 2015 at 12:43 AM, Robert O'Callahan
rob...@ocallahan.org wrote:
On Tue, Jul 14, 2015 at 11:24 PM, Philip Jägenstedt
On Thu, Jul 16, 2015 at 1:59 AM, Philip Jägenstedt phil...@opera.com
wrote:
On Wed, Jul 15, 2015 at 12:43 AM, Robert O'Callahan
rob...@ocallahan.org wrote:
On Tue, Jul 14, 2015 at 11:24 PM, Philip Jägenstedt phil...@opera.com
wrote:
Basically a I trust the browser to decide and promise
On Wed, Jul 15, 2015 at 12:43 AM, Robert O'Callahan
rob...@ocallahan.org wrote:
On Tue, Jul 14, 2015 at 11:24 PM, Philip Jägenstedt phil...@opera.com
wrote:
Basically a I trust the browser to decide and promise not to assume
anything state? The auto state is already suitable named and
On Tue, Jul 14, 2015 at 10:33 PM, Philip Jägenstedt phil...@opera.com
wrote:
I see, is this a policy that's applied even with a single video in a
page, or is it something like a limit on the total number of players
that can be created, or limits on how much stuff (decoders) they set
up
On Tue, Jul 7, 2015 at 11:56 AM, Robert O'Callahan rob...@ocallahan.org wrote:
On Tue, Jul 7, 2015 at 9:41 PM, Philip Jägenstedt phil...@opera.com wrote:
Unsurprisingly, I like this, as it's basically what Presto did. However, I
think preload=metadata should reach HAVE_CURRENT_DATA, because
On Tue, Jul 14, 2015 at 3:15 AM, Robert O'Callahan rob...@ocallahan.org wrote:
Apart from the problems already discussed here, there is currently no
specced or interoperably implemented way to set a preload value that
guarantees HAVE_CURRENT_DATA, HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA will be
On Tue, Jul 14, 2015 at 8:51 PM, Philip Jägenstedt phil...@opera.com
wrote:
Would it solve the same practical problems if auto were redefined to
mean that the goal readyState is HAVE_ENOUGH_DATA?
Probably.
Is there a reason it doesn't do this in mobile Firefox?
We don't want a page with
On Tue, Jul 14, 2015 at 1:08 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Tue, Jul 14, 2015 at 10:33 PM, Philip Jägenstedt phil...@opera.com
wrote:
I see, is this a policy that's applied even with a single video in a
page, or is it something like a limit on the total number of players
On Tue, Jul 14, 2015 at 11:57 AM, Robert O'Callahan
rob...@ocallahan.org wrote:
On Tue, Jul 14, 2015 at 8:51 PM, Philip Jägenstedt phil...@opera.com
wrote:
Would it solve the same practical problems if auto were redefined to
mean that the goal readyState is HAVE_ENOUGH_DATA?
Probably.
On Tue, Jul 14, 2015 at 1:17 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Tue, Jul 14, 2015 at 11:13 PM, Philip Jägenstedt phil...@opera.com
wrote:
If the behavior could be made interoperable for when resources are not
a problem, that would be a good start at least. The spec can say
On Tue, Jul 14, 2015 at 11:13 PM, Philip Jägenstedt phil...@opera.com
wrote:
If the behavior could be made interoperable for when resources are not
a problem, that would be a good start at least. The spec can say that
the browser should at least try to ready HAVE_ENOUGH_DATA for
preload=auto,
On Tue, Jul 14, 2015 at 11:24 PM, Philip Jägenstedt phil...@opera.com
wrote:
Basically a I trust the browser to decide and promise not to assume
anything state? The auto state is already suitable named and
defined for that, so if implementing auto as anything other than
try to reach
Apart from the problems already discussed here, there is currently no
specced or interoperably implemented way to set a preload value that
guarantees HAVE_CURRENT_DATA, HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA will be
reached ... auto may do one of those things, but it doesn't have to, and
in fact on
On Tue, Jul 7, 2015 at 4:48 AM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Tue, Jul 7, 2015 at 1:44 AM, Philip Jägenstedt phil...@opera.com
wrote:
On Mon, Jul 6, 2015 at 2:19 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Mon, Jul 6, 2015 at 11:17 PM, Philip Jägenstedt
On Tue, Jul 7, 2015 at 9:41 PM, Philip Jägenstedt phil...@opera.com wrote:
Unsurprisingly, I like this, as it's basically what Presto did. However, I
think preload=metadata should reach HAVE_CURRENT_DATA, because you do
want to decode the first frame. The naming mismatch is weird, but oh well.
On Wed, Jun 10, 2015 at 6:53 AM, Robert O'Callahan rob...@ocallahan.org wrote:
In Gecko, video preload=metadata doesn't fire canplay. This is
allowed (encouraged, even) by the spec, since we can efficiently satisfy
preload=metadata by stopping decoding after one frame, and if we only
decode
On Mon, Jul 6, 2015 at 11:17 PM, Philip Jägenstedt phil...@opera.com
wrote:
On Wed, Jun 10, 2015 at 6:53 AM, Robert O'Callahan rob...@ocallahan.org
wrote:
In Gecko, video preload=metadata doesn't fire canplay. This is
allowed (encouraged, even) by the spec, since we can efficiently satisfy
On Mon, Jul 6, 2015 at 2:19 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Mon, Jul 6, 2015 at 11:17 PM, Philip Jägenstedt phil...@opera.com
wrote:
On Wed, Jun 10, 2015 at 6:53 AM, Robert O'Callahan rob...@ocallahan.org
wrote:
In Gecko, video preload=metadata doesn't fire canplay.
On Tue, Jul 7, 2015 at 1:44 AM, Philip Jägenstedt phil...@opera.com wrote:
On Mon, Jul 6, 2015 at 2:19 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Mon, Jul 6, 2015 at 11:17 PM, Philip Jägenstedt phil...@opera.com
wrote:
On Wed, Jun 10, 2015 at 6:53 AM, Robert O'Callahan
In Gecko, video preload=metadata doesn't fire canplay. This is
allowed (encouraged, even) by the spec, since we can efficiently satisfy
preload=metadata by stopping decoding after one frame, and if we only
decode one frame then readyState will not advance beyond HAVE_CURRENT_DATA.
However, this
21 matches
Mail list logo
