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

On Fri, Feb 19, 2016 at 3:39 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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.)

Hmmm... I didn't say his solution is complicated... I just didn't
think the "screen" looks like the right word here, so I ignored
this... But it seems my proposal was almost identical to his
otherwise, except how I described it.

> 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.

Actually, I did say this is way too complicated for such simple usecase.

- Xidorn

Received on Friday, 19 February 2016 08:43:06 UTC