- From: Rik Cabanier <cabanier@gmail.com>
- Date: Wed, 14 Sep 2016 20:01:16 -0700
- To: Simon Fraser <simon.fraser@apple.com>
- Cc: "/#!/JoePea" <trusktr@gmail.com>, "public-fx@w3.org" <public-fx@w3.org>
- Message-ID: <CAGN7qDBL2wte0_E2QYKV8RAEprTS-TxWvO-ftmcaJ9DOUSMTgA@mail.gmail.com>
On Wed, Sep 14, 2016 at 5:24 PM, Simon Fraser <simon.fraser@apple.com> wrote: > > On Sep 14, 2016, at 5:09 PM, /#!/JoePea <trusktr@gmail.com> wrote: > > > But are they doing correct group opacity? > > The behavior in Chrome 52, Firefox, and Safari 9 is correct, yes. The > implementation and wording isn't as important as the results, and the > result in Chrome 53 is not correct. > > Actually, Chrome 52 and Safari behavior aren't doing correct group > opacity. Testcase at <http://smfr.org/css/transforms/opacity-preserve- > 3d.html>. You should not see the darkening where the layers overlap. > > Chrome 53 fixes this, but as you say, this can break web content. It's > possible that we'll have to revert this spec change due to web compat > issues. > Chrome had a use counter for content that was going to be affected: https://www.chromestatus.com/metrics/feature/popularity#OpacityWithPreserve3DQuirk 0.0058% of web pages is affected by this change. I thought Safari also changed this behavior. Didn't webkit used to distribute parent opacity to its children? > Do you have public web content that is broken by this change? > > > On Sep 14, 2016 5:08 PM, "/#!/JoePea" <trusktr@gmail.com> wrote: > >> Pardon that I don't know the spec terminology, I'm just iterating what >> the proper behavior is (what we see in Chrome 52). >> >> For reference, try first demo I linked in the Chrome issue, and nite that >> it is now broken in Chrome 53, but works fine in Firefox and Safari 9. >> >> We can't be breaking the web like this, and we can't be introducing >> behaviors that don't make sense from a 3D stand point. >> >> On Sep 14, 2016 5:04 PM, "/#!/JoePea" <trusktr@gmail.com> wrote: >> >>> I see what you're saying: you're just re-iterating the spec, whose >>> design is flawed. >>> >>> The behavior should be just as it were before Chrome 53 was released. >>> It's all works nicely in Chrome 52. >>> >>> How you will word that in the spec is a different issue, and all I'm >>> saying is that Chrome 52 exhibits proper behavior, as do current Firefox >>> and Safari. >>> >>> Chrome 53 follows this flawed spec, and is therefore broken. >>> >>> On Sep 14, 2016 4:58 PM, "Simon Fraser" <simon.fraser@apple.com> wrote: >>> >>>> >>>> On Sep 14, 2016, at 4:24 PM, /#!/JoePea <trusktr@gmail.com> wrote: >>>> >>>> > Authors can work around this by applying opacity on their leaf >>>> elements individually, or by using rgba() colors etc. >>>> >>>> That's not a valid workaround because in many cases there needs to be >>>> opacity on parent elements. >>>> >>>> For example, imagine a game object which is a vehicle. The parent >>>> contains sub children positioned relatively to the parent (using tranforms) >>>> in order to place the doors, wheels, and body of the vehicle (maybe it is a >>>> truck, car, or motorcycle). Now, imagine in this game that the cars are >>>> alive (like in the movie "Cars", and one of them is a ghost. To achieve >>>> this, we apply an opacity to the parent element, which makes the whole car >>>> transparent. Or, imagine that there is a "ghost" car in a racing game in >>>> order to show where you were during your last attempt, so that you can >>>> attempt to beat your last time. We apply opacity to the whole car, and >>>> expect for thecar to remain 3D, not be flattened. >>>> >>>> In cases like with the car examples, we cannot simply apply opacity to >>>> leaf-most elements. Furthermore, rgba() colors apply only to things like >>>> background, border, text colors, etc, but not to the whole element, so >>>> that's not a workaround. >>>> >>>> The only workaround is to NOT use nested elements, but that prohibits >>>> the use of CSS transform caching that we get with the nested approach. It >>>> is imperative that the nested approach works along with opacity without >>>> flattening, otherwise this change is detrimental to 3D in the web, and is >>>> completely unintuitive. Making a 3D object flat because it has opacity >>>> simply does not make sense (it doesn't matter if that's what spec says). >>>> >>>> For reference, the "nested" approach is the form of CSS3D that IE10/11 >>>> does not support, with preserve-3d. >>>> >>>> Grouping is fine, as it makes much sense for all children to inherit >>>> the opacity level and have it multiplied with their own opacity (just like >>>> how positional transformations work), but additional flattening is simply >>>> not a good design choice. >>>> >>>> >>>> Unfortunately you can't have one (grouping) without the other >>>> (flattening), at least with the 3D implementation in WebKit, and I suspect >>>> other UAs too. The way that preserve-3D works is to hoist descendant layers >>>> up to effectively become siblings of their parent/ancestor elements in the >>>> same 3D-rendering context, so they call get positioned and depth-sorted in >>>> the same 3D coordinate space. There's no way you can do group opacity in >>>> this model without rendering some subtree of transformed elements into a >>>> texture (which is flattening). >>>> >>>> Simon >>>> >>>> >>>> Please consider modifying the spec so that opacity does not destroy 3D >>>> scenes. Also please consider the same for mix-blend-mode, and similar >>>> effects. >>>> >>>> Best regards, >>>> - Joe >>>> >>>> */#!/*JoePea >>>> >>>> On Wed, Sep 14, 2016 at 3:58 PM, Simon Fraser <simon.fraser@apple.com> >>>> wrote: >>>> >>>>> On Sep 14, 2016, at 3:51 PM, /#!/JoePea <trusktr@gmail.com> wrote: >>>>> >>>>> The following is a big problem for people making 3D scenes, and I >>>>> really think this needs to be rethought: >>>>> >>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=646993 >>>>> >>>>> Not only does it break existing apps, but it also makes it difficult >>>>> to create 3D HTML scenes that involve opacity. The intuitively expected >>>>> behavior (as listed in that issue) is that opacity applies to children but >>>>> does not cause unintuitive flattening. >>>>> >>>>> If browsers follow the latest spec, then we are making it more >>>>> difficult to do and discouraging 3D in the web, which I don't think is what >>>>> we want. >>>>> >>>>> The faulty part of the spec is here: https://drafts.csswg.org >>>>> /css-transforms/#grouping-property-values >>>>> >>>>> It states that opacity should cause grouping, which is what causes the >>>>> flattening. >>>>> >>>>> Is there an alternative way to achieve opacity less than 1.0 without >>>>> flattening of 3D scenes, that I may have missed? Unless there's an >>>>> alternative, this behavior is a bad idea for authors of 3D HTML scenes. >>>>> >>>>> >>>>> CSS opacity is defined to be "group opacity", which means rendering >>>>> everything into a bitmap, and then paint that bitmap with alpha. This gives >>>>> a different result to painting individual elements with opacity, when those >>>>> elements overlap. >>>>> >>>>> The CSS transforms spec is conforming to this group opacity behavior, >>>>> which, in implementations, requires flattening at rendering time. >>>>> >>>>> Authors can work around this by applying opacity on their leaf >>>>> elements individually, or by using rgba() colors etc. >>>>> >>>>> Simon >>>>> >>>>> >>>>> >>>> >>>> >
Received on Thursday, 15 September 2016 03:01:45 UTC