[css-transforms] Handling combined opacity and preserve-3d

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[css-transforms] Handling combined opacity and preserve-3d

Matt Woodrow-2
What is the expected behaviour when transform-style:preserve-3d and
opacity are combined on a single element?

The current working draft [1] makes no mention of what to do.

I wrote a test to check the behaviours of various browsers [2] and it
looks like both Blink and Webkit apply the opacity to each of the
preserve-3d 'leaves' instead of applying it as a group.

Gecko flattens that subtree to apply the opacity as a group, and in
currently Nightly we make a better attempt to sort what remains.

The current editors draft [3] also requires flattening, but I don't
think that's going to be web compatible, as we've already found websites
that are using this [4].

I think it's worth updating the working draft to spec the Blink/Webkit
behaviour, since the editors draft is a big change and unlikely to be
finished quickly. I'll happily fix Gecko to match this behaviour.

Thanks!

- Matt


[1] http://www.w3.org/TR/css-transforms-1/#transform-style-property
[2] http://people.mozilla.org/~mwoodrow/preserve3d-opacity.html
[3] https://drafts.csswg.org/css-transforms/#grouping-property-values
[4] http://lacigrona.com/carta/comida/

Reply | Threaded
Open this post in threaded view
|

Re: [css-transforms] Handling combined opacity and preserve-3d

Simon Fraser-4

On Feb 24, 2016, at 6:45 pm, Matt Woodrow <[hidden email]> wrote:

What is the expected behaviour when transform-style:preserve-3d and opacity are combined on a single element?

The current working draft [1] makes no mention of what to do.

As Tab says, TR = Trash. You should look at the editor’s draft, which is much more recent than the 2013 TR version.

You’re right that the transform-style definition doesn’t specify that opacity causes flattening (it should), but section 6.1.2. does:

Some CSS properties have values that are considered to force "grouping": they require that their element and its descendants are rendered as a group before being composited with other elements; these include opacity, filters and properties that affect clipping. The relevant property values are listed under grouping property values. These grouping property values force the used value for transform-style to be "flat”,


I wrote a test to check the behaviours of various browsers [2] and it looks like both Blink and Webkit apply the opacity to each of the preserve-3d 'leaves' instead of applying it as a group.

I’d consider this a bug, although, as you mention below, there is certainly web compat risk in fixing it. ‘opacity’ in CSS really does mean group opacity, which  requires flattening.

Sadly we missed fixing it before dropping prefixes; the code has:
    // FIXME: when dropping the -webkit prefix on transform-style, we should also have opacity < 1 cause flattening.


Gecko flattens that subtree to apply the opacity as a group, and in currently Nightly we make a better attempt to sort what remains.

The current editors draft [3] also requires flattening, but I don't think that's going to be web compatible, as we've already found websites that are using this [4].

I think it's worth updating the working draft to spec the Blink/Webkit behaviour, since the editors draft is a big change and unlikely to be finished quickly. I'll happily fix Gecko to match this behavior.

When finishing off CSS Transforms, we’re going to have to be willing to create combat issues; there’s no way we can avoid them with the current lack of compat between browsers. I’d like to see more breakage than [4] before speccing broken Blink/WebKit behavior.

Simon

Reply | Threaded
Open this post in threaded view
|

Re: [css-transforms] Handling combined opacity and preserve-3d

Robert O'Callahan-3
On Sat, Feb 27, 2016 at 10:20 AM, Simon Fraser <[hidden email]> wrote:
When finishing off CSS Transforms, we’re going to have to be willing to create combat issues; there’s no way we can avoid them with the current lack of compat between browsers. I’d like to see more breakage than [4] before speccing broken Blink/WebKit behavior.

The current behavior of not flattening is interoperably implemented between Webkit/Blink/Gecko (not sure about Edge). There certainly are compat risks as we align browser behaviors, but this isn't that.

If you think we should move to a better behavior, ship it in Webkit and then I think we'd be willing to follow and update the spec.

Rob
--
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea lurpr  
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr  esn
Reply | Threaded
Open this post in threaded view
|

Re: [css-transforms] Handling combined opacity and preserve-3d

Matt Woodrow-2


On 26/02/16 5:47 PM, Robert O'Callahan wrote:
On Sat, Feb 27, 2016 at 10:20 AM, Simon Fraser <[hidden email]> wrote:
When finishing off CSS Transforms, we’re going to have to be willing to create combat issues; there’s no way we can avoid them with the current lack of compat between browsers. I’d like to see more breakage than [4] before speccing broken Blink/WebKit behavior.

If you think we should move to a better behavior, ship it in Webkit and then I think we'd be willing to follow and update the spec.

Right, the new spec seems like a big improvement, but I think we'll need to coordinate to get away with such big compatibility changes.

It still seems valuable to update some version of the spec, or otherwise document the current state of affairs rather than only having the desired future state.

I plan on fixing Gecko to be compatible with the Blink/WebKit behaviour in the mean time.

- Matt
Reply | Threaded
Open this post in threaded view
|

Re: [css-transforms] Handling combined opacity and preserve-3d

Chris Harrelson


On Mon, Feb 29, 2016 at 2:49 PM Matt Woodrow <[hidden email]> wrote:


On 26/02/16 5:47 PM, Robert O'Callahan wrote:
On Sat, Feb 27, 2016 at 10:20 AM, Simon Fraser <[hidden email]> wrote:
When finishing off CSS Transforms, we’re going to have to be willing to create combat issues; there’s no way we can avoid them with the current lack of compat between browsers. I’d like to see more breakage than [4] before speccing broken Blink/WebKit behavior.

If you think we should move to a better behavior, ship it in Webkit and then I think we'd be willing to follow and update the spec.

Right, the new spec seems like a big improvement, but I think we'll need to coordinate to get away with such big compatibility changes.

It still seems valuable to update some version of the spec, or otherwise document the current state of affairs rather than only having the desired future state.

I plan on fixing Gecko to be compatible with the Blink/WebKit behaviour in the mean time.

Hi Matt/Simon/Rossen/all,

I'm the lead for paint/compositing integration in Blink.

TL;DR:
- Blink/Chrome would like to change its implementation to have opacity force flattening, and AIUI match what Firefox was doing before this Mozilla bug wax recently fixed.
- We'd like other implementations to make the change also if there is consensus.

As noted already in this thread, this changed behavior matches the latest spec, is more well-defined and rational, and significantly reduces the complexity of Blink's implementation. (Matt, from reading the Mozilla bug, I think you would agree?)

Other implementers: does this change sound good? Would you be willing to commit to changing behavior if it is web compatible enough? (We are already collecting compatibility data in the Canary & Dev channels).

Here is one example:

Our work is tracked in this bug.

Thanks,
Chris



Reply | Threaded
Open this post in threaded view
|

Re: [css-transforms] Handling combined opacity and preserve-3d

Matt Woodrow-2


On 27/05/16 5:03 AM, Chris Harrelson wrote:

Hi Matt/Simon/Rossen/all,

I'm the lead for paint/compositing integration in Blink.

TL;DR:
- Blink/Chrome would like to change its implementation to have opacity force flattening, and AIUI match what Firefox was doing before this Mozilla bug wax recently fixed.
- We'd like other implementations to make the change also if there is consensus.

As noted already in this thread, this changed behavior matches the latest spec, is more well-defined and rational, and significantly reduces the complexity of Blink's implementation. (Matt, from reading the Mozilla bug, I think you would agree?)

Other implementers: does this change sound good? Would you be willing to commit to changing behavior if it is web compatible enough? (We are already collecting compatibility data in the Canary & Dev channels).

Here is one example:

Our work is tracked in this bug.

Firefox only temporarily had that behaviour, it was a regression due to a refactoring we did. We reverted to matching the current Blink/WebKit behaviour since we had reports of real sites breaking because of it.

I do agree that this change is the preferable behaviour though, so will be interested in the results of the compatability data you're collecting.

- Matt
Reply | Threaded
Open this post in threaded view
|

Re: [css-transforms] Handling combined opacity and preserve-3d

Chris Harrelson


On Thu, May 26, 2016 at 4:09 PM Matt Woodrow <[hidden email]> wrote:


On 27/05/16 5:03 AM, Chris Harrelson wrote:

Hi Matt/Simon/Rossen/all,

I'm the lead for paint/compositing integration in Blink.

TL;DR:
- Blink/Chrome would like to change its implementation to have opacity force flattening, and AIUI match what Firefox was doing before this Mozilla bug wax recently fixed.
- We'd like other implementations to make the change also if there is consensus.

As noted already in this thread, this changed behavior matches the latest spec, is more well-defined and rational, and significantly reduces the complexity of Blink's implementation. (Matt, from reading the Mozilla bug, I think you would agree?)

Other implementers: does this change sound good? Would you be willing to commit to changing behavior if it is web compatible enough? (We are already collecting compatibility data in the Canary & Dev channels).

Here is one example:

Our work is tracked in this bug.

Firefox only temporarily had that behaviour, it was a regression due to a refactoring we did. We reverted to matching the current Blink/WebKit behaviour since we had reports of real sites breaking because of it.

So far the data seems to show a very small impact. I'll update next week with some actual numbers.
 

I do agree that this change is the preferable behaviour though, so will be interested in the results of the compatability data you're collecting.

Great. Simon/Rossen, what do you think?
 


- Matt
Reply | Threaded
Open this post in threaded view
|

Re: [css-transforms] Handling combined opacity and preserve-3d

Chris Harrelson


On Sat, May 28, 2016 at 2:12 PM Chris Harrelson <[hidden email]> wrote:
On Thu, May 26, 2016 at 4:09 PM Matt Woodrow <[hidden email]> wrote:


On 27/05/16 5:03 AM, Chris Harrelson wrote:

Hi Matt/Simon/Rossen/all,

I'm the lead for paint/compositing integration in Blink.

TL;DR:
- Blink/Chrome would like to change its implementation to have opacity force flattening, and AIUI match what Firefox was doing before this Mozilla bug wax recently fixed.
- We'd like other implementations to make the change also if there is consensus.

As noted already in this thread, this changed behavior matches the latest spec, is more well-defined and rational, and significantly reduces the complexity of Blink's implementation. (Matt, from reading the Mozilla bug, I think you would agree?)

Other implementers: does this change sound good? Would you be willing to commit to changing behavior if it is web compatible enough? (We are already collecting compatibility data in the Canary & Dev channels).

Here is one example:

Our work is tracked in this bug.

Firefox only temporarily had that behaviour, it was a regression due to a refactoring we did. We reverted to matching the current Blink/WebKit behaviour since we had reports of real sites breaking because of it.

So far the data seems to show a very small impact. I'll update next week with some actual numbers.

Data shows this will likely affect < 0.006% of pages, and likely much less. I'd like to send an intent to implement and ship on blink-dev for this change, to go into Chrome 53. What say you?


I do agree that this change is the preferable behaviour though, so will be interested in the results of the compatability data you're collecting.

Great. Simon/Rossen, what do you think?
 


- Matt
Reply | Threaded
Open this post in threaded view
|

Re: [css-transforms] Handling combined opacity and preserve-3d

Simon Fraser-4
In reply to this post by Chris Harrelson
On May 28, 2016, at 2:12 pm, Chris Harrelson <[hidden email]> wrote:


On Thu, May 26, 2016 at 4:09 PM Matt Woodrow <[hidden email]> wrote:


On 27/05/16 5:03 AM, Chris Harrelson wrote:

Hi Matt/Simon/Rossen/all,

I'm the lead for paint/compositing integration in Blink.

TL;DR:
- Blink/Chrome would like to change its implementation to have opacity force flattening, and AIUI match what Firefox was doing before this Mozilla bug wax recently fixed.
- We'd like other implementations to make the change also if there is consensus.

As noted already in this thread, this changed behavior matches the latest spec, is more well-defined and rational, and significantly reduces the complexity of Blink's implementation. (Matt, from reading the Mozilla bug, I think you would agree?)

Other implementers: does this change sound good? Would you be willing to commit to changing behavior if it is web compatible enough? (We are already collecting compatibility data in the Canary & Dev channels).

Here is one example:

Our work is tracked in this bug.

Firefox only temporarily had that behaviour, it was a regression due to a refactoring we did. We reverted to matching the current Blink/WebKit behaviour since we had reports of real sites breaking because of it.

So far the data seems to show a very small impact. I'll update next week with some actual numbers.
 

I do agree that this change is the preferable behaviour though, so will be interested in the results of the compatability data you're collecting.

Great. Simon/Rossen, what do you think?

I think that it makes logical sense that opacity forces flattening, and am willing change WebKit accordingly.

Simon


Reply | Threaded
Open this post in threaded view
|

Re: [css-transforms] Handling combined opacity and preserve-3d

Tab Atkins Jr.
On Wed, Jun 8, 2016 at 7:35 AM, Simon Fraser <[hidden email]> wrote:
> I think that it makes logical sense that opacity forces flattening, and am
> willing change WebKit accordingly.

And we agreed to do so on the call this morning!

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: [css-transforms] Handling combined opacity and preserve-3d

Chris Harrelson
Great, thank you. FYI this is the intent thread on blink-dev for shipping this change in Chrome 53.

Chris

On Wed, Jun 8, 2016 at 3:59 PM Tab Atkins Jr. <[hidden email]> wrote:
On Wed, Jun 8, 2016 at 7:35 AM, Simon Fraser <[hidden email]> wrote:
> I think that it makes logical sense that opacity forces flattening, and am
> willing change WebKit accordingly.

And we agreed to do so on the call this morning!

~TJ
Reply | Threaded
Open this post in threaded view
|

Re: [css-transforms] Handling combined opacity and preserve-3d

Matt Woodrow-2

I've sent this intent thread to mozilla.dev-platform to make the change for Firefox 52.

- Matt

On 9/06/16 8:38 PM, Chris Harrelson wrote:
Great, thank you. FYI this is the intent thread on blink-dev for shipping this change in Chrome 53.

Chris

On Wed, Jun 8, 2016 at 3:59 PM Tab Atkins Jr. <[hidden email]> wrote:
On Wed, Jun 8, 2016 at 7:35 AM, Simon Fraser <[hidden email]> wrote:
> I think that it makes logical sense that opacity forces flattening, and am
> willing change WebKit accordingly.

And we agreed to do so on the call this morning!

~TJ