On Tue, Apr 14, 2015 at 10:53 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
I guess there are really two different sets of use-cases:
1) Use-cases where the ImageBitmap is sized to fill a particular area of
the screen.
2) Use-cases where the ImageBitmap is sized subject to some other
I think the original approach of adding a fourth argument is much better.
It's also a better API in general, since the URL should always be given.
If we had a one-argument form with a dictionary, people would consider
not
giving the URL but just disabling scrolling, which is
On Wed, Apr 15, 2015 at 12:07 PM, Justin Novosad ju...@google.com wrote:
In the interest of moving forward with this, I began an experimental
implementation of the renderedPixelWidth/Height propsal (
https://wiki.whatwg.org/wiki/CanvasRenderedPixelSize) in Blink. I ran
into
some issues,
On 16 Apr 2015, at 6:42 am, Elliott Sprehn espr...@chromium.org wrote:
3. Accessing rendered pixel size is layout-inducing. To avoid layout
thrashing, we should consider making this an asynchronous getter (e.g.
asyncGetBoundignClientRect). This would also prevent renderedsizechanged
events
In the interest of moving forward with this, I began an experimental
implementation of the renderedPixelWidth/Height propsal (
https://wiki.whatwg.org/wiki/CanvasRenderedPixelSize) in Blink. I ran into
some issues, which I documented in the issues section of the proposal. I
would like to draw
On Wed, Apr 15, 2015 at 1:46 PM, Dean Jackson d...@apple.com wrote:
On 16 Apr 2015, at 6:42 am, Elliott Sprehn espr...@chromium.org wrote:
3. Accessing rendered pixel size is layout-inducing. To avoid layout
thrashing, we should consider making this an asynchronous getter (e.g.
On Wed, Apr 15, 2015 at 6:45 PM, Martin Thomson
martin.thom...@gmail.com wrote:
I believe that the easiest way to avoid this is to make an attempt to
read Response.body raise a SecurityError if the origin is different
(in Firefox terms, we would say if the response principal is not
subsumed by
