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

On Thu, Feb 18, 2016 at 1:55 PM, Christian Mayer <mail@christianmayer.de> wrote:
> Hello all,
>
> currently the the box-shadow offset is calculated with regard to the
> element and then the transform is applied to both, the element and it's
> shadow.
>
> For a transform:translate() this makes mostly sense, but for a
> transform:rotate() it usually doesn't:
> The box-shadow offset should fake a lighting of the design so it should
> always go in the same direction for all elements (ignoring special uses
> for special effects). So when a element is rotated by a
> transform:rotate() the box-shadow is currently also rotated.
>
> The only way to show a consistently lighted design is to do the maths
> for the inverted rotation yourself and apply that to the box-shadow
> offset to compensate the transform:rotate().
> But this will only work on a static design.
>
> Once the design is e.g. animated by a transition things are getting very
> ugly. As
> http://stackoverflow.com/questions/35102216/keep-box-shadow-direction-consistent-while-rotating
> shows, some non obvious tricks must be used to do the compensation.
>
> So is there a way (or can it be added?) to make the offset always work
> in screen coordinates and not in element coordinates?
> E.g. by adding an additional keyword?
>
> Like
>
>   box-shadow: screen 2px 3px 4px #000
>   transform: translate(10px, 20px) rotate(40deg)
>
> to have the element translated and rotated and then on the final place
> of the screen a box shadow added that is painted 2px to the right and
> 3px to the bottom from exactly that place.
>
> This also applies to the text-shadow as well, of course.

I share Xidorn's concern about this being fairly complicated.  But
more importantly, it's *incomplete* - your suggestion handles
rotations, but not skews or anything 3d.  (Scale, and translation as
you point out, don't need to be "handled", at least on their own. When
combined with other things, though, they do.)

I don't think it's very easy at all to do an actual late shadow -
transforms happen fairly late in the process. But then, I could be
wrong - an implementor with more knowledge of their painting
subsystems would have to answer.

If handling just the rotation is fine, though, then the nearish future
with variables and custom functions will help in handling this -
someone can write a custom function to translate a length+angle into
two axis-aligned offsets, and then you can use a custom property to
share the rotation value between the box-shadow and the transform
without having to duplicate them.

~TJ

Received on Friday, 19 February 2016 07:40:12 UTC