- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Jun 2018 16:27:42 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Smarter interpolation of truncated transform lists`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Smarter interpolation of truncated transform lists<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/927<br> <dael> krit: There's one issue on smart interpolation for transform functions. You have to interpolate when there's an animation. Usually they have to have same paremeters to map. Every time those functions do not match tehre is matrix interpolation<br> <dael> krit: Previous we allowed the transforms to be of differnet size. As long as they map to same size we do the interpolation per transform function. Concern was this wasn't good enough<br> <dael> krit: In this issue request is interpolation per transform function as long as they match with each other. If they do not match we do matrix intrp but just for the ones that come after the non-mathcing<br> <dael> krit: Support from TabAtkins , request from smfr to defer to L2. I think we keep what we have b/c it's interop.<br> <dael> krit: I don't think we can defer because it would change animation in certain situations. Doesn't happen too often that you don't have 2 matching and an animation.<br> <dael> krit: So do we agree to this proposal? Or do we keep the current spec text where everything multiplied to a matrix.<br> <dael> krit: Complex, but important for animations<br> <dael> krit: Questions on what hte request is?<br> <dael> fantasai: I agree with making the animations do closer to what authors expect and making them more powerful in terms of accurate representation. In favor of the change.<br> <dael> fantasai: Only question I have is we're using the prefix and padding the end with additional ID transforms. Do we want to allow...if the end of the transform list matches rather then the beginning. You don't interopalte ones you don't have, but if one sequenence is a subset allow padding on either side?<br> <dael> krit: There are requests to make it smarter, but it's complicated. YOu have to find the pattern and there might be multiple ptterns so you have to decide.<br> <dael> fantasai: I'm suggesting it has to be exact match. If you have multiple we pick a rule like match against the first one.<br> <dael> krit: I'm a bit confused. You want them to match on start or end and only if same length?<br> <dael> fantasai: Different, but only if one is an exact subset of the other.<br> <dael> krit: List 1 is a subset of list 2<br> <dael> fantasai: Yes<br> <dael> krit: And only beginning or end or also middle?<br> <dael> fantasai: Both. Middle or end.<br> <dael> dbaron: I worry matching in middle will be harder to understand. We want behavior to be good and understandable and expected. Matching in the middle feels...oh, it'llrandomly search, but only if you have an exact match of seq. I think there's value in doing something simple and explainable.<br> <dael> fantasai: Okay. That's fine. I wanted to know if it was thought through<br> <dael> krit: Does the issue in question have support? everything matches at the beginning but not end so we do matrix for the things that do not match at end?<br> <dael> fantasai: Seems fine<br> <dael> krit: Looking for browser impl feedback as that's not impl<br> <dael> krit: If people need time it's fine, but input at some point would be great.<br> <dael> Rossen_: smfr isn't on the call. We are going to make this change as a part of transforms L1, right?<br> <dael> krit: Yes, need to for L1 because if we do L2 there will be unexpected repercussions for Animations<br> <dael> Rossen_: Do people feel they need more time? Can we resolve now and reopen if needed? Preference?<br> <dael> Rossen_: Objections to...krit?<br> <dael> krit: I'm not proposing. I'm in favor of not changing text<br> <dael> Rossen_: Proposal: No change to the current specification<br> <dael> krit: Only b/c it's impl currently<br> <dael> Rossen_: Objections to stay with current impl behavior and not change transforms L1?<br> <dael> fantasai: We've talked about if we make this change it should be L1.<br> <dael> krit: Correct<br> <dael> Rossen_: Yes if we make the change it should be L1.<br> <dael> fantasai: So asking to not change ever?<br> <dael> Rossen_: No, we can defer this to L2 but for L1 we can stay with current impl solution in the spec.<br> <dael> fantasai: If you want to eventually make this change, why not put it in L1?<br> <dael> krit: Depends on impl interest. If there isn't doesn't make sense to put it in.<br> <dael> fantasai: I don't think it makes sense to decide if we're putting in L1. If we do it it should go in L1. We can put it in L1 and mark as at-risk. This is a WD still.<br> <dael> fantasai: The longer that we don't impl, content...this is a change in an existing deployed feature. If we want a change we should do it sooner rather than later. Waiting doesn't seem should do<br> <dael> Rossen_: But I'm not hearing impl step up.<br> <dael> florian: Then we shouldn't have it at all rather than have it in L2<br> <dael> Rossen_: And that's the no change resolution. Don't impl it.<br> <dael> Rossen_: Any interest in working on this feature? If not we can resolve on rejecting it.<br> <dael> fantasai: Note that birtles and TabAtkins aren't here. Can anyone represent their positions?<br> <dael> Rossen_: People from Mozilla or Chrome on?<br> <dael> Rossen_: none to represent this issue<br> <dael> fantasai: I recommend that given they're not here and critical we resolve on if we do it this is how and then the question of do we do it waits until next week.<br> <dael> Rossen_: We can try and get to this in F2F<br> <dael> fantasai: You can resolve on how interpolation happens<br> <dael> Rossen_: Prefer not to in absense of the people you mentioned. If will discuss at F2F let's do it at that time.<br> <fantasai> s/absense/absence/<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/927#issuecomment-400741457 using your GitHub account
Received on Wednesday, 27 June 2018 16:27:45 UTC