- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 9 Apr 2015 18:25:30 -0700
- To: Kenneth Russell <kbr@google.com>
- Cc: Ian Hickson <ian@hixie.ch>, Jake Archibald <jaffathecake@gmail.com>, Robert O'Callahan <robert@ocallahan.org>, WHATWG <whatwg@whatwg.org>
On Thu, Apr 9, 2015 at 5:23 PM, Kenneth Russell <kbr@google.com> wrote: > 1. An image element that didn't have a width or height explicitly > specified in the markup has an ImageBitmap transferred in. Will its > width and height attributes change? Will layout have to occur on the > page? Its width and height *attributes* won't change, but its *intrinsic* width and height will, to match the bitmap and density. (Btw, the ImageBitmap feature needs to have a notion of density.) Yes, layout occurs, assuming the size changed. > 2. The same image element has another ImageBitmap transferred in which > has a different width and height. Do the image's width and height > change? Will layout have to occur on the page? Yes and yes, assuming the size changed. > When an image's src is set to a URL and its width and height > attributes aren't set, the page is laid out again when the image is > loaded. For acceptable performance it's important that this not happen > when displaying a new ImageBitmap. Using a new canvas context type > solves this problem. The OffscreenCanvas proposal defines the > ImageBitmap as being rendered at the upper left corner of the canvas's > box with no scaling applied, and clipped to the box. It's not as > flexible as having the object-fit and object-position CSS properties > available, but will give developers explicit control over when they > want layout to happen, and still let them display their content as > they wish. Why not just use object-fit/position? I think we support those. No need to make new weird behavior when you can just opt into the desired behavior with existing standardized stuff. ~TJ
Received on Friday, 10 April 2015 01:26:14 UTC