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

> On Feb 18, 2016, at 11:39 pm, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> On Thu, Feb 18, 2016 at 1:55 PM, Christian Mayer <mail@christianmayer.de <mailto: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.

Painting shadows post-transfsrms is hard. You’d have to move shadow rendering into the compositor,
which would mean doing a mask/blur operation on every frame of animation for animated, shadowed things.

I doubt that implementors want to go there.

Simon