- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Oct 2019 16:42:09 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Is it necessary to serialize all 3 components of translate given the 3rd component is 0px`, and agreed to the following: * `RESOLVED: For the individual transform properties if they spec a value that can be expressed as 2d we treat as 2d and serialize accordingly` * `RESOLVED: Require transform funcitons to be downgraded to 2d if possible` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Is it necessary to serialize all 3 components of translate given the 3rd component is 0px<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/3305<br> <astearns> s/ring/read this/<br> <dael> TabAtkins: Question was the individual transform for translate spec distinction between 2d and 3d. If you explicitly give 2d it always does 2d, 3d is always 3d even if z is 0. Question of if it violates shortest serialization. Originally thought no because 3d has a meaning, but after looking any differences left we treat as bugs<br> <dael> TabAtkins: We're fine serializing as 3d. Fine with doing what heycam suggests.<br> <dael> TabAtkins: Does have minor changes b/c some difference as you do 3d animation as you pass through 0 if you pause right there it looks a little different. Considered minor by those in thread<br> <dael> dbaron: No longer animation diff between 2 value and 3 value syntax?<br> <dael> TabAtkins: If you pause a 3d transform while it's animating and at a state where it's 2d transform it will serialize differently. We're fine with that for now and consider it a bug being fixed<br> <dael> dbaron: I thought another difference was animation behavior depending on if you spec 2 or 3 values. My memory is a bunc hof the is it 2d or 3d are related to interpolation<br> <dael> AmeliaBR: If before and after states one is 2d and one is 3d they won't match us as being consistently the same. If one of them uses 3 values and 3rd is 0 I don't know how it's interpolated<br> <dael> AmeliaBR: With this proposal the 3 value disappears at computed and interpolates as a 2d<br> <dael> TabAtkins: dbaron do you have an example for your concern?<br> <dael> dbaron: If you're trying to interpole between translate and matrix and if the translate is 2d or 3d might effect if interpolation goes into 3rd dimension. But interpolation rules have changed so I'm not sure current state<br> <dael> TabAtkins: THink I'm in the same board.<br> <dael> dbaron: Basically want to make sure when you said there aren't significant differences you ran it by someone who is up to date<br> <dael> TabAtkins: eric w and chris have been in support<br> <dael> dbaron: Okay<br> <dbaron> s/up to date/up to date on the interpolation rules/<br> <dael> astearns: Would it be emilio on gecko's side?<br> <dael> dbaron: Possibly birtles, but I'm not sure.<br> <dael> dbaron: Possibly [missed]<br> <dael> astearns: dbaron would you be okay resolving<br> <dael> dbaron: I'm okay<br> <dbaron> s/[missed]/hiro/<br> <dael> AmeliaBR: I want to mention that this complicates how transforms are spec for svg which does make distinction between 2d transforms being regular layout vs 3d transforms being an isolating, flattening effect.<br> <dael> AmeliaBR: We haven't had a lot of implementors following spec to distinguish for SVG so might not be breaking. We do need people to commit to following through and cleaning up those areas of the spec and how do they work if we don't have clear consistent way to define 2d transform and 3d transform<br> <dael> TabAtkins: Yeah. Other evidence, Eric points out all 4 engines serialize scale 3d with 1 z-index as a 2d matrix. In general engines are loose even when you explicitly say 3d. Remaining errors with z-axis translate we're fine treating as a bug<br> <dael> astearns: Proposal?<br> <dael> TabAtkins: Option 1: For individual transform properties should they make 2d vs 3d distinction vs number of properties. We propose go on the value of the z-index<br> <dael> TabAtkins: In general should transforms be more permissive about 3d functions without 3d requiring transform being eq. to 2d. Have a mixture of behaviors, Blink is in favor oh downgrade to 2d when possible model<br> <dael> TabAtkins: Individual transform is easier.<br> <smfr> s/z-index/z value/<br> <dael> astearns: Prop: When there is a 3d value the transform properties are only 3d if the value is not 0<br> <dael> TabAtkins: If the transform can be expressed as a 2d we serialize as a 2d<br> <dael> astearns: Just serialization then?<br> <dael> AmeliaBR: More then serialization. It means that the round tripping is if you serialize and re-parse it's 2d so we don't want it to behave differen wiether you set the 3rd parameter or leave as default<br> <dael> TabAtkins: A translate with 3 values but z is 0 should not trigger full compositing<br> <dael> astearns: Trying to figure out how to state option 1<br> <dael> TabAtkins: For the individual transform properties if they spec a value that can be expressed as 2d we treat as 2d and serialize accordingly<br> <dael> RESOLVED: For the individual transform properties if they spec a value that can be expressed as 2d we treat as 2d and serialize accordingly<br> <dael> astearns: Second?<br> <dael> TabAtkins: Apply the above to all transform functions in normal transform property and then figure out implications for serialization and interpolation<br> <dael> AmeliaBR: Have some sort of resolution conditional on people doing web compat tests and get feedback from more authors?<br> <dael> TabAtkins: I'd rather not resolve if we're waiting for that.<br> <dael> AmeliaBR: At this point without a clear text of all places it'll impact it's hard to get author feedback<br> <dael> AmeliaBR: I'm a little worried about web compat depending on fine details<br> <dael> TabAtkins: I suspect this will be hard to get author feedback because it's technical and tiny. Compat-wise sure. Blink is okay with eating the compat, but if others are uncomfortable we can wait<br> <dael> AmeliaBR: You're right feedback won't happen until it's pushed.<br> <dael> astearns: I expect that making this change to figure out compat problems requires a resolution? Or would Blink experiment?<br> <dael> TabAtkins: We'd like spec text, but in a proposal is okay. So we can point to that's what we're doing<br> <dael> fantasai: We can resolve and say checking web compat<br> <dael> AmeliaBR: Not sure anywhere it makes sense to talk about this as at risk. I guess it's not a CR change<br> <dael> AmeliaBR: Widely impl but not officially stable<br> <dael> TabAtkins: Yes<br> <dael> AmeliaBR: Make the change with the awareness we might get author screams and have to revert<br> <dael> astearns: Prop: Require transform funcitons to be downgraded to 2d if possible<br> <dael> astearns: And we'll see what web compat shakeout is. Objections?<br> <dael> smfr: Just for serialization?<br> <dael> TabAtkins: Not sure the distinction. What would be different between yes and no to that<br> <dael> smfr: I guess not interpolation b/c 2d and 3d matching<br> <dael> TabAtkins: preserves compositing if you're in an animation<br> <dael> AmeliaBR: 2d gets upgraded to 3d to match endpoint<br> <dael> smfr: webkit uses it as a trigger<br> <dael> TabAtkins: That's what we're willing to stop doing<br> <dael> astearns: Any concerns smfr ?<br> <dael> smfr: No, worth experimenting<br> <dael> astearns: Objections?<br> <dael> RESOLVED: Require transform funcitons to be downgraded to 2d if possible<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3305#issuecomment-545532745 using your GitHub account
Received on Wednesday, 23 October 2019 16:42:11 UTC