- From: Matt Woodrow <mwoodrow@mozilla.com>
- Date: Mon, 19 Sep 2016 19:22:29 +1200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Rik Cabanier <cabanier@gmail.com>, /#!/JoePea <trusktr@gmail.com>, Chris Harrelson <chrishtr@google.com>, Simon Fraser <simon.fraser@apple.com>, "public-fx@w3.org" <public-fx@w3.org>
On 19/09/16 6:27 PM, Tab Atkins Jr. wrote: > No, as I explained in more detail in the GitHub thread I linked > <https://github.com/w3c/svgwg/issues/264#issuecomment-246750601>, this > is a logical consequence of 'opacity' and other filter-type effects > being "group effects". If you want the effect to only apply to the > leaves, you can do that yourself by specifying it on the leaves, but > it has a visibly different effect than doing it "as a group". Sorry, I'm not quite sure I follow. The idea I proposed explicitly *doesn't* break the group nature of opacity, which is why I think it's worth discussing. The example I gave had opacity applied to an intermediate element, and showed the internal representation needed to apply it as a group while maintaining preserve-3d. Are there more complex examples you can think of where this breaks down? >> Obviously this would prevent depth sorting occurring between elements inside >> and outside of 'b', and we need to figure out how to depth sort 'b' itself >> (given that it is an atomic entry for sorting, but isn't a 2d plane), but >> those seem solvable. > That's actually the core problem preventing this from working; it's > not a detail we can just paper over later. Which part of this? The first piece is the exact same situation we have when we flatten for opacity, so I don't see how that's a problem. The latter is somewhat difficult from an implementation standpoint, but it's not obvious that it's a showstopper. - Matt
Received on Monday, 19 September 2016 07:23:03 UTC