Hi Ian,
You wrote:
On Wed, 30 Jan 2013, Peter Carlson (carlsop) wrote:
Problem: The problem is that the supported playback speeds of a media
element may vary per media item (e.g., an on-demand movie) and as
[…]
Recommendation: We suggest that the application should be able to
discover
Ian
For on-demand movies or VOD, the available playback speeds may be
determined by the server of the content. This cannot be overcome by
client-side buffering.
Peter Carlson
On Mon, 3 Dec 2012, Mikko Rantalainen wrote:
It seems to me like the best solution is to have a new HTTP header,
with the four following values being allowed:
Seamless-Options: allow-shrink-wrap
Seamless-Options: allow-styling
Seamless-Options: allow-shrink-wrap
On Wed, 19 Jun 2013, Justin Novosad wrote:
I was about to launch the implementation of window.createImageBitmap in
Blink, and I received feedback on the blink-dev mailing list that the
Promise API is the wave of the future for asynchronous JS, and that
the new createImageBitmap method
On 18 Jul 2013 07:08, Ian Hickson i...@hixie.ch wrote:
On Wed, 19 Jun 2013, Justin Novosad wrote:
I was about to launch the implementation of window.createImageBitmap in
Blink, and I received feedback on the blink-dev mailing list that the
Promise API is the wave of the future for
On Thu, 18 Jul 2013, Silvia Pfeiffer wrote:
There are basically two styles:
- constructors (new Date(), new Function(), etc)
- factory methods on the parent object (document.createElement(),
implementation.createDocument(), context.createLinearGradient(), etc)
Do we have a
On 18 Jul 2013 07:57, Ian Hickson i...@hixie.ch wrote:
On Thu, 18 Jul 2013, Silvia Pfeiffer wrote:
There are basically two styles:
- constructors (new Date(), new Function(), etc)
- factory methods on the parent object (document.createElement(),
On Thu, 18 Jul 2013, Silvia Pfeiffer wrote:
In this case you did remove the non-promise based approach - presumably
because it has not been implemented in browsers yet, which is fair
enough for browsers.
Right.
However, for JS developers it means that if they want to use this
On Wed, Jul 17, 2013 at 3:12 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
I guess I'm asking for JS dev input here...
FWIW, the feedback I've heard from JS devs is a touchingly agreement
about how much create* functions suck.
/ Jonas
On Wed, Jul 17, 2013 at 6:54 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 18 Jul 2013, Silvia Pfeiffer wrote:
At the same time, I think we should follow a clear pattern for
introducing a Promise based API, which the .create() approach would
provide.
I don't understand what that means.
On Thu, Jul 18, 2013 at 10:00 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 17 Jul 2013, Justin Novosad wrote:
On Wed, Jul 17, 2013 at 6:54 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 18 Jul 2013, Silvia Pfeiffer wrote:
At the same time, I think we should follow a clear pattern for
Hi,
I noticed inconsistency between datalist element example and option
element content model.
In a datalist element's code example, there are option elements which
don't specify label attribute and are empty.
On Wed, Jul 17, 2013 at 5:22 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
It may well be that Promises are the right way to go for
createImageBitmap(), but we are blazing a new trail here and need to
be careful about the implications. For example, here is an interesting
discussion
On Thu, 18 Jul 2013, Silvia Pfeiffer wrote:
We have the same issues with WebRTC, which already has a callback based
API, but there is a suggestion to replace/augment with a Promise based
API, so I just wanted to understand the motivation, potential
complications and implications.
This is exactly what I was thinking when I was reading this. I have been
building a game engine with async JS and I have run into situations
where promises were absolutely sapping performance.
I would encourage people to look over even the faster promise libraries
and understand just how much
On Wed, Jul 17, 2013 at 8:17 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 18 Dec 2012, Kevin Gadd wrote:
Sorry, upon reading over the ImageBitmap part of the spec again I'm
confused: Why is constructing an ImageBitmap asynchronous?
Because it might involve network I/O.
Just to be
On Jul 17, 2013 8:40 PM, Ruben Rodriguez II wha...@therealcha0s.net
wrote:
This is exactly what I was thinking when I was reading this. I have been
building a game engine with async JS and I have run into situations where
promises were absolutely sapping performance.
I would encourage people
On Thu, Jul 18, 2013 at 10:39 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 18 Jul 2013, Silvia Pfeiffer wrote:
We have the same issues with WebRTC, which already has a callback based
API, but there is a suggestion to replace/augment with a Promise based
API, so I just wanted to understand the
I think all I would say with regards to implementing promises is that it's
too early. Primarily for these reasons:
- The developer community (primarily JS) is still debating the semantics of
promises. There is the promises a+ spec (
http://promises-aplus.github.io/promises-spec/) which has
On 07/17/2013 07:51 PM, Tab Atkins Jr. wrote:
On Jul 17, 2013 8:40 PM, Ruben Rodriguez II wha...@therealcha0s.net
wrote:
This is exactly what I was thinking when I was reading this. I have been
building a game engine with async JS and I have run into situations where
promises were absolutely
On Jul 17, 2013 9:00 PM, Ruben Rodriguez II wha...@therealcha0s.net
wrote:
On 07/17/2013 07:51 PM, Tab Atkins Jr. wrote:
On Jul 17, 2013 8:40 PM, Ruben Rodriguez II
It'll take 1 day to wrap
your API with a promise-based API for people who would make that
tradeoff.
If you sacrifice speed
On Wed, Jul 17, 2013 at 5:17 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 18 Dec 2012, Kevin Gadd wrote:
Is it possible to expose the width/height of an ImageBitmap, or even
expose all the rectangle coordinates? Exposing width/height would be
nice for parity with Image and Canvas when
22 matches
Mail list logo
