Another use case to think about is: XHR->Blob->ImageBitmap->Canvas(2D or
With that data flow, there is no opportunity to use a CSS property to tweak
image orientation.

There is this idea though:

Boris' point about adding a dependency on style computation is concerning.
This could potentially seriously regress performance of existing apps that
(inadvertently?) invalidate style of image elements at each animation frame.

>From an implementation standpoint though, it would make sense for image
elements to to store decoded images with the corrected orientation
baked-in, and to be able to use that cached decoded image buffer directly
in drawImage, without having to re-apply (or even verify) orientation
correction at that time.  But of course, that implies resolving style at
image decode time.  What to do?

On Wed, Apr 16, 2014 at 8:15 AM, Boris Zbarsky <> wrote:

> On 4/16/14 11:09 AM, Anne van Kesteren wrote:
>> I don't really follow the reasoning. But I guess if this has been
>> shipping in Firefox for a while we might be out of luck changing this.
> I doubt image-orientation is widely used, esp. in combination with
> drawImage.
> But if we want to use it here, we should coordinate with the CSS WG at
> least.
> -Boris

Reply via email to