W3C home > Mailing lists > Public > public-fx@w3.org > July to September 2016

Re: [css-transforms] CSS3D breaks with opacity flattening

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 19 Sep 2016 09:40:03 +0100
Message-ID: <CAGN7qDCyA5E286JF33izvuzrn=is8ZWYxOF2M81ukm7evoibjg@mail.gmail.com>
To: Matt Woodrow <mwoodrow@mozilla.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>
On Mon, Sep 19, 2016 at 8:22 AM, Matt Woodrow <mwoodrow@mozilla.com> wrote:

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

What you're proposing will also change how content is rendered. :-\

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

Why is that not a showstopper? Your proposal seems very difficult to
implement since it pushes matrix manipulation all the way down to the
individual elements.
It also introduces more rendering surfaces.
You're also relying on how firefox is representing the render tree which
might be completely different from other UA's

Browsers already have a hard time giving a consistent experience with the
simple model and this will make it even more complicated.
Received on Monday, 19 September 2016 08:40:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:57 UTC