- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 04 Jul 2018 02:33:00 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Images Level 3`, and agreed to the following: * `RESOLVED: cross-fade() takes one or more args, each has an optional %` * `RESOLVED: At computed value time, simplify directly nested cross-fade()s into a single cross-fade()` * `RESOLVED: At computed value time we collapse same <image> values in cross-fade()s and adding their percentages` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Images Level 3<br> <heycam> ScribeNick: heycam<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/2852<br> <heycam> leaverou: we were trying to define interoplation between crossfades more reasonably with Elika yesterday<br> <fantasai> s/Elika/fantasai/<br> <heycam> ... when we're interpolating two cross fades with same images in a different order, A B , then B A<br> <heycam> ... it ends up creating a cross fade of the cross fade<br> <heycam> ... this comes up a lot, this interpolation happens when you're reversing a transition<br> <heycam> ... so fantasai suggested when adding a rule, when the images is the same and the order is different, we flip the order and change the percentages to account for it<br> <heycam> ... so 100% minus what it was<br> <heycam> ... is that OK? since it's CR we should check<br> <heycam> fantasai: the use case for getting this to work simply is that when you're doing transitions between one image and another, when you interrupt that transition, you're half way between<br> <heycam> ... so you want to interpolate between a crossfade and a start point<br> <heycam> ... your computed value gets more and more complex<br> <heycam> dbaron: is this the only interoplation type that has this problem?<br> <heycam> emilio: I suspect it can happen with transform as well<br> <heycam> dbaron: yes<br> <heycam> birtles: with calc<br> <heycam> ericwilligers: with transform didn't we define ...<br> <heycam> TabAtkins: the interpolate() function<br> <heycam> dbaron: so transform can do the same thing with interpolate() nesting in the same way<br> <heycam> fantasai: we should probably do the same thing for transform then<br> <heycam> ericwilligers: does interpolate() make cross-fade() redundant?<br> <heycam> leaverou: it only helps you get the intermediate values<br> <heycam> fantasai: there are use cases for cross fade where the author explicitly wants to fade between two things<br> <heycam> ... and there are differnet ways of interpolating images, cross fade is one of them<br> <heycam> fantasai: the proposed resolution is that interpolating crossfade or the interpolate function, where the end point and start point have opposite order of arguments, you swap the order, so you don't nest the interpolating function<br> <heycam> xidorn: shouldn't we just merge things when one side is crossfade A to B, and the other side is A or B?<br> <heycam> fantasai: that's the next question<br> <heycam> dbaron: what stage is this happening?<br> <heycam> fantasai: computed value?<br> <heycam> dbaron: so part of the process of computing the value of a nested cross fade is to un-nest<br> <heycam> fantasai: no, when you're computing the mid point for<br> <heycam> dbaron: so you're changing the interpolation rules<br> <heycam> fantasai: yes<br> <heycam> Rossen: does that sounds reasonable to people?<br> <heycam> dbaron: yes, if you make it consistently apply to other places where this problem comes up<br> <heycam> TabAtkins: yes<br> <heycam> Rossen: any objections to this? do we need to add a note for the general interpolate function to be added as well?<br> <heycam> birtles: I misunderstood<br> <heycam> ... I thought this was just about computed value simplification of nested cross-fade<br> <heycam> ericwilligers: [writes examples on white board]<br> <heycam> birtles: I'm just wondering why we're adding rules to interpolation. would the alternative be to say this is how nested crossfades are simplified at computed value time?<br> <heycam> ... then you don't need to do anything particular for interpolation<br> <heycam> fantasai: we could do that<br> <heycam> leaverou: I'd be fine with that<br> <heycam> dino: cross-fade(A, B, 50%) is not the same as cross-fade(B, A, 50%)<br> <heycam> ... it's 50% of src-overing the second on top of the first<br> <heycam> fantasai: and with transparency?<br> <heycam> dino: you can tell the difference between B over A 50% and A over B 50%, yes<br> <heycam> ericwilligers: would you advocate nested cross-fades()?<br> <heycam> dino: I'd advocate not interpolating<br> <heycam> fantasai: I don't think that's a good solution<br> <heycam> dino: if we're going to do it, then nested cross-fade(), maybe<br> <heycam> leaverou: nested cross-fades() should be supported anyway<br> <heycam> dino: so, yes, nested cross-fades() would be my preferred solution<br> <heycam> leaverou: I think it's Safari and Chrome at the moment<br> <heycam> birtles: pre-fork, so one implementation<br> <heycam> TabAtkins: dino your point before about A B 50% and B A 50% being different is wrong, since it's a dissolve<br> <heycam> ... dissolve op rather than src-over op<br> <heycam> ... since that's the correct way to fade between two images with potential transparencies<br> <heycam> Rossen: do we need a whiteboarding breakout for this?<br> <heycam> leaverou: if reversing the order does produce the same image, what's the argument against it<br> <heycam> ... if nobody has any then why do we need to break out<br> <fantasai> http://drafts.csswg.org/css-images-3/<br> <fantasai> https://drafts.csswg.org/css-images-3/#cross-fade-function<br> <heycam> TabAtkins: only options are (a) do nothing, allowing nesting, (b) accept these rules for interpolation simplification, or (b) accept these rules for computed value simplification and allow interpolation to fall out<br> <heycam> emilio: why (c)?<br> <heycam> leaverou: then it also allows us to simplify computed values returned<br> <heycam> emilio: I thought the point was nested cross fade is hard<br> <heycam> TabAtkins: it's not that it's hard, but in common cases, like repeatedly interrupting a transition, it resutls in a stack of cross-fade()s<br> <heycam> ... when you could simplify it down<br> <heycam> emilio: the difference between (b) and (c) is not observable<br> <heycam> TabAtkins: yes it is<br> <heycam> emilio: I think I prefer (b)<br> <heycam> leaverou: [shows demo]<br> <heycam> emilio: if you want to simplify what you interpolate, to avoid growing stacks of cross-fades(), you do it there<br> <heycam> ... but you also need to do it at computed values<br> <heycam> ... because the author might have specified a nested cross-fade()<br> <heycam> fantasai: the interoplated intermediate value must be a computed value<br> <TabAtkins> Note that if we *do* finally do the "any number of images" extension, then we can simplify *all* nested cross-fades, in all situations.<br> <heycam> leaverou: if I'm understanding emilio correctly, you don't want to create this thing if you're going to simplify it anyway<br> <heycam> ... if you're already going to simplify serialization of a specified (and computed) value<br> <heycam> emilio: it complicates the code<br> <heycam> birtles: I wonder if you're going to need to simplify it first anyway, in order to interpolate potentially nested inputs that you get<br> <heycam> ericwilligers: yes<br> <heycam> birtles: also will need to do it for addition, assuming that makes sense<br> <heycam> leaverou: ideally it would be nice if cross-fade() accepted any number of arguments, and flatten them down to a single one<br> <heycam> ericwilligers: then you've got more computations<br> <heycam> s/computations/permutations/<br> <heycam> leaverou: if you could collapse the tree down to a flat cross fade list of values, it's simpler to apply<br> <heycam> TabAtkins: since dissolve commutes, you can collapse all cross fades<br> <heycam> dino: plus commutes, dissolve doesn't<br> <heycam> dino: what I got wrong is I'm src-overing not plusing<br> <heycam> TabAtkins: plusing an appropriate dissolved image commutes, such that you can take nested cross fades and flatten it to a list of images that plus together<br> <heycam> leaverou: should we just do that, allow cross-fade() to take a list of arguments<br> <heycam> birtles: I think it's nicer from an authoring point of view too<br> <birtles> that is, parsing the result of getComputedStyle is easier if you don't need to handle nested cross-fade functions<br> <heycam> leaverou: another issue, if you're interpolating between A and cross-fade(A, ...), with the current rules you'll get a nested cross-fade()<br> <heycam> ... we could define that the A gets promoted to 100% cross-fade, and just interpolate percentage<br> <leaverou> https://github.com/w3c/csswg-drafts/issues/2853<br> <heycam> fantasai: I think the proposal one this one is you get a single cross-fade() with A and B with arguments and the appropriate percentage<br> <heycam> leaverou: we can, but if we're collapsing trees of cross-fade()s, it's less important<br> <heycam> fantasai: collapsing trees is different from merging<br> <heycam> TabAtkins: depends how we collapse<br> <heycam> dino: [looking at the issue] wouldn't it be x is between 0 and p, not p and 100?<br> <heycam> leaverou: you're interpolating between full A and the cross-fade<br> <heycam> ... you want it to start at 100<br> <heycam> dbaron: I think we should try to resolve both at the same tim<br> <heycam> s/tim/time/<br> <heycam> ... where the simplification happens, turning into multi arg cross-fade(), applies to both<br> <heycam> myles: the proposal is change the behavior because it makes it easier to compute?<br> <heycam> leaverou: this way you wouldn't need to interpolate to make a new cross-fade() at all<br> <heycam> myles: there is a difference between having a tree of cross fades and not having a tree<br> <heycam> TabAtkins: nobody has trees yet<br> <heycam> ... we're trying to avoid that now<br> <heycam> TabAtkins: overall proposal is, avoid all trees of cross-fades, in all situations, by making it accept more than two arguments, just dissolve and plus throughout those<br> <fantasai> fantasai explains that interpolating cross-fade(x% A, B) and cross-fade(y% A, B) results in cross-fade(z% A, B), not a tree of cross-fades()s<br> <heycam> ... and make nested cross-fade() invalid, and make interpolations between them build the appropriate multi-arg value<br> <fantasai> this issue about treating interpolation of A & cross-fade(y% A, B) and cross-fade(100% A, B) & cross-fade(y% A, B) the same way<br> <dbaron> q+ to comment on (a) nesting through other functions and (b) validity of percentages that add to more than 100%<br> <heycam> [whiteboard discussion of particular interpolations]<br> <heycam> leaverou: I still think nested cross-fades() should be valid, since they could come from variables<br> <heycam> myles: if the goal is to avoid avoiding trees, by making a list that has all the nodes of the tree, I don't see why that's better<br> <heycam> TabAtkins: you don't need to generate all the intermediate images<br> <heycam> myles: is there a behaviour change?<br> <heycam> TabAtkins: no<br> <heycam> myles: then we should just say "as if", a browser optimization<br> <heycam> myles: so we're talking about computed values<br> <heycam> florian: do we disallow in specified value?<br> <heycam> TabAtkins: before we decide on that, let's look at the core thing<br> <heycam> ... multi-arg cross-fade(), does it sound reasonable<br> <heycam> dino: and you must provide %s up to the last one?<br> <heycam> ... allowed to go over 100%?<br> <heycam> TabAtkins: yes [for first], and no.<br> <heycam> TabAtkins: if the percentages add up to over a 100%, you sum them and normalize to 100%<br> <heycam> ... then the last one gets zero<br> <heycam> myles: every time gets a percentage<br> <heycam> TabAtkins: except the last<br> <heycam> ... last one gets what's left over<br> <heycam> dino: complete error if you did (A 10%, B, C)?<br> <heycam> TabAtkins: syntax error<br> <heycam> myles: is the purpose of this that humans will write this? or just to make the getCS output smaller?<br> <heycam> TabAtkins: so clearly we want this for interpolation<br> <fantasai> heycam: Simplifying trees down to one level is same as flat list<br> <fantasai> heycam: Want to collapse list to minimum number of items<br> <fantasai> TabAtkins: If the goal is to avoid explosion...<br> <heycam> myles: if this is for humans to use, it's useful<br> <heycam> ericwilligers: negative %s allowed?<br> <heycam> TabAtkins: no, individual %s above 100% should be disallowed<br> <fantasai> s/disallowed/invalid/<br> <fantasai> TabAtkins: But we can't syntacitcally restrict the sum<br> <heycam> birtles: I'm not 100% sure about the normalization part<br> <heycam> ... the syntax I like<br> <heycam> ericwilligers: not sure about normalization when you have interpolations between lists<br> <heycam> birtles: I was thinking, once the bucket's full, the overflow could be dropped<br> <heycam> myles: should make it possible for the last one to have a %<br> <heycam> florian: to use them as 'fr's?<br> <heycam> leaverou: right now, cross-fade() percentage is optional<br> <heycam> ... probably it should retain this<br> <heycam> ... right now (A, B), the 50% is implied<br> <heycam> ... (A 20%, B, C) should make sense<br> <heycam> shans: distribute the rest<br> <heycam> leaverou: yes<br> <heycam> myles: allow the last percentage to be specified, then just weight them<br> <astearns> q?<br> <heycam> fantasai: if you have (A 20%, C 20%, C 20%)<br> <heycam> ... you could simply transparent black to take the slack<br> <heycam> florian: rather than normalizing to 100%?<br> <heycam> fantasai: if you're under<br> <heycam> shans: one problem with diff behaviours on either side of 100% gets you non-linearities, bad for animation<br> <heycam> ericwilligers: like opacity:1<br> <astearns> ack dbaron<br> <Zakim> dbaron, you wanted to comment on (a) nesting through other functions and (b) validity of percentages that add to more than 100%<br> <heycam> TabAtkins: the suggest grammar is, cross-fade() takes one or more args, each has an optional %<br> <heycam> ... we'll work out what missing %s mean<br> <heycam> Rossen: any objections to that?<br> <heycam> RESOLVED: cross-fade() takes one or more args, each has an optional %<br> <heycam> leaverou: next, collapsing trees of cross-fade()s<br> <heycam> ... it's much easier to define interpolatino that way<br> <heycam> ... for authors reading it back<br> <heycam> ... don't know why we wouldn't collapse it down, esp given it's commutative<br> <heycam> emilio: can we disallow nested cross-fade() in specified values?<br> <heycam> TabAtkins: no for the same reason you allow nested calc()s<br> <heycam> leaverou: with variables<br> <heycam> dbaron: two other points<br> <Rossen> q?<br> <heycam> ... there are going to be other image-ish functions<br> <heycam> ... cross-fade() one of these other functions continaing a cross-fade() will be a reasonable thing<br> <heycam> ... I think the other piece is that I think one of the things that results from disallowing it, everyone has to go and implement that, then later we'll allow it, which is more work<br> <heycam> ... so we should just allow it now<br> <heycam> TabAtkins: agreed<br> <heycam> ... specified values should allow it. interpolated values collapse to a single value<br> <heycam> ... interpolated values, don't care?<br> <heycam> leaverou: I would collapse<br> <heycam> birtles: collapse<br> <heycam> fantasai: I thin kso<br> <heycam> s/thin kso/think so/<br> <heycam> florian: both kinds of smooshing down, flattening tree, and merging items in the list?<br> <heycam> leaverou: they are separate issues but I support both<br> <heycam> myles: so it's not just a simple substitution, there are formulas to calcalate the %s<br> <heycam> TabAtkins: yes. it's just mulitplican tho<br> <heycam> RESOLVED: At computed value time, simplify directly nested cross-fade()s into a single cross-fade()<br> <heycam> xidorn: that means the flattened value is the canonical form of that<br> <heycam> TabAtkins: yes<br> <heycam> leaverou: now dropping duplicated images<br> <heycam> TabAtkins: if you have multiple args which are the same image<br> <heycam> ... should the canonical form automatically collapse those together and add their percentage<br> <heycam> leaverou: do we have an algorithm for same image?<br> <heycam> fantasai: the compued value of the <url> is the absolute URL<br> <heycam> Rossen: the reason for simplifying is avoiding growth of the values<br> <heycam> leaverou: we should not only combine the duplicates but also sort them<br> <heycam> fantasai: I think we need to simplify this, to avoid growing lists<br> <heycam> ... we can do it very simply<br> <heycam> emilio: how do you define sorting images?<br> <heycam> myles: if you didn't want this, didn't want to collapse -- internally you want to<br> <Rossen> heycam: are the cases where we want avoid this?<br> <heycam> fantasai: I don't think so<br> <heycam> ... it's going to be the same when you collapse it all down<br> <heycam> fantasai: notion of equality we want is "computed values are the same"<br> <heycam> frremy: with gradients, with px and %s ....<br> <heycam> fantasai: that's not computed value<br> <heycam> ... that's used value<br> <heycam> RESOLVED: At computed value time we collapse same <image> values in cross-fade()s and adding their percentages<br> <heycam> leaverou: sorting<br> <heycam> fantasai: you don't want computed value of cross-fade() where you randomly swap the order<br> <heycam> fantasai: re-sort into the target order and go from there?<br> <heycam> ... so don't sort the computed value<br> <heycam> ... but when interpolating, you re-sort the start point into the end point order<br> <heycam> myles: that's cool then CSS doesn't have to define order<br> <heycam> so no sorting occurs, for interpolation it falls out of the simplification process<br> <TabAtkins> When interpolating be3tween A and B, you just cross-fade(A,B) then collapse; whatever that results in is the answer.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2852#issuecomment-402345433 using your GitHub account
Received on Wednesday, 4 July 2018 02:33:05 UTC