- From: Matt Woodrow <mwoodrow@mozilla.com>
- Date: Wed, 21 Sep 2016 16:38:31 +1200
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: "Tab Atkins Jr." <jackalmage@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>
- Message-ID: <7ae78f68-f4db-c5e6-83ca-22bea2bab22a@mozilla.com>
On 21/09/16 12:57 PM, Rik Cabanier wrote: > What makes opacity so special? (Or are you proposing that other > effects also inherit this behavior?) > "naturally" is also ambivalent. I find the current Chrome behavior > more natural. > > Opacity is special because it doesn't really matter if you apply > it before or after the transform. Filter might also fall into this > category, but most of the others (mix-blend, clipping) seem like > their position in the preserve-3d really matter. > > > I don't see why that is. clipping and blending can be done pre/post > transform. I guess that's true as well. We have existing web content relying on us not flattening opacity, so I think it makes sense to start with opacity. The others might make sense too, or we might have webcompat issues changing those. > > I guess natural is a poor choice of words. I was thinking of the > use case where you take a set of elements to form an 'object' (say > a 3d cube), apply opacity to that (true, group opacity) and then > position it within the outer scene (say a whole set of cubes that > rotate in a carousel). As far as I can tell, there's no way to > achieve this effect with the current spec and my suggestion makes > it possible. > > > Yes, that is a current issue in the spec. Once you're in a 3d context, > you can't introduce group opacity and not expect it to flatten. > Simon Fraser made a proposal 2 years ago to fix this: > https://logs.csswg.org/irc.w3.org/css/2014-01-28/#e237881/https://lists.w3.org/Archives/Public/www-style/2014Feb/0053.html > > His proposal was to redefine the values of transform-style so it's not > ambiguous. Unfortunately, since the prefix was dropped, we likely have > to introduce a new name if we go down that path :-\ This is the core of my point, why should you have to expect it to flatten? I've shown that this isn't actually a requirement, only the convenient way of handling group opacity Given that we have existing content that depends on *not* flattening, then I feel that we've missed the chance to do the convenient thing and we have to handle opacity without flattening. I made a simple testcase that shows what I mean, and then hacked up a prototype of my suggestion in Firefox to show rendering it as I suggest: http://people.mozilla.org/~mwoodrow/cube.html Rendering examples: Chrome: http://people.mozilla.org/~mwoodrow/chrome-cube.png Safari: http://people.mozilla.org/~mwoodrow/safari-cube.png Firefox-with-prototype: http://people.mozilla.org/~mwoodrow/firefox-prototype-cube.png You can try out my prototype builds if you'd like, though there's probably bugs for harder cases: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c1df8944930e https://archive.mozilla.org/pub/firefox/try-builds/mwoodrow@mozilla.com-c1df8944930e39bea120afd5e86ba45ffc4b1c3d/ - Matt
Received on Wednesday, 21 September 2016 04:39:07 UTC