- From: Simon Fraser <smfr@me.com>
- Date: Fri, 19 Feb 2016 08:52:23 -0800
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: mail@christianmayer.de, www-style list <www-style@w3.org>
- Message-id: <C095D0EA-9473-4F5C-9E2A-8F7550F31A01@me.com>
> 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
Received on Friday, 19 February 2016 16:52:56 UTC