W3C home > Mailing lists > Public > www-style@w3.org > February 2016

Re: box-shadow offset when transform:rotate is used

From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
Date: Fri, 19 Feb 2016 08:42:48 -0700
Message-ID: <CAFDDJ7wQ77_q23i3vJJmGubM6jBiCkbgR3QJcS6VRQk0H0C=kQ@mail.gmail.com>
To: mail@christianmayer.de
Cc: Xidorn Quan <quanxunzhen@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Although I have no fundamental objection to the idea of
rotation-independent shadow settings, my instinct is that this would be
problematic to implement.  Box shadows as spec'ed are simple paint
operations, not 3D lighting effects.

As Tab noted, rotations are applied after the painted layer has been
generated. Although the browser could keep track of the net rotation that
will be applied to an element, and then apply the reverse effect to the
shadow, this would have performance impacts beyond the extra calculations.
Animated transformations are optimized because the painted content does not

For most cases (a 2D rotated shape with a solid border & background), you
can get the desired effect with a drop-shadow filter on an un-transformed
wrapper element.

A drop-shadow might not have the best rendering performance currently, but
it could be improved in future if implementations use GPU blur effects.  If
a future CSS spec introduces proper 3D lighting and shadow effects, that
would also probably be applied via `filter`.  Box-shadows, in contrast, do
not affect containing boxes & stacking contexts, so would be more difficult
to transfer to GPU effects.

Received on Friday, 19 February 2016 15:43:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:00 UTC