- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Aug 2017 10:15:50 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Additive CSS`, and agreed to the following resolutions:
* `RESOLVED: No concerns wrt shipping Web Animations`
* `RESOLVED: CSSWG is interested in working on additive cascade proposals.`
<details><summary>The full IRC log of that discussion</summary>
<dino> Topic: Additive CSS<br>
<fantasai> ScribeNick: fantasai<br>
<birtles> https://github.com/w3c/csswg-drafts/issues/1594<br>
<fantasai> birtles: This issue covers everything I want to say<br>
<fantasai> birtles: Want to introduce idea of addititve CSS<br>
<fantasai> birtles: Figure out if we want to do this soon or not<br>
<fantasai> birtles: We have something like this in Animations, wanted to see if we should pursue in static CSS also<br>
<fantasai> birtles: Start off with additive animation<br>
<fantasai> birtles: then static additive CSS<br>
<fantasai> birtles: Normally when you have animations in CSS<br>
<fantasai> birtles: basically you can only ever have one animation affecting the same property at the same time<br>
<fantasai> birtles: This demo here has animations spin and swell<br>
<fantasai> birtles: when I apply the both<br>
<fantasai> birtles: you can see only the swell animation is taking effect<br>
<birtles> http://slides.com/birtles/browser-animation-2017-2#/3/11<br>
<fantasai> birtles: This can be due to the nature of the cascade, only one animation declaration will win<br>
<fantasai> birtles: But even when you specify two animations in a isngle declarations<br>
<fantasai> birtles: then the declarations in the keyframes could override each other<br>
<fantasai> birtles: Problem in animations<br>
<fantasai> birtles: There's a means for solving that which comes from SMIL<br>
<fantasai> birtles: and is in Web Animations<br>
<fantasai> birtles: where you define the properties as being addititve<br>
<fantasai> birtles shows demo with Web Animations that shows spinning and growing at the same time<br>
<fantasai> glazou: Do you put composite=add on both of them?<br>
<fantasai> birtles: only the top one<br>
<fantasai> birtles: If you declare an animation as additive, then it adds to underlying unanimated style, or adds to underlying animations<br>
<fantasai> birtles: wherever in the chain doesn't say add, clobbers earlier declarations<br>
<fantasai> glazou: animate(composite=add) that's ok<br>
<fantasai> glazou: but for properties...<br>
<fantasai> glazou: parsing is not done yet?<br>
<fantasai> birtles: That feature is defined in Web Animations, implemented (but not shipping) in Chrome & Firefox<br>
<fantasai> birtles: Property for CSS Animations 2 to give same feature<br>
<fantasai> birtles: How does it actually work?<br>
<fantasai> birtles: different animations types, define what it means to add animations<br>
<fantasai> birtles: then need to define order, since not operations are commutative<br>
<fantasai> birtles: and also need to know which to exclude<br>
<fantasai> birtles: Web Animations there's a defined order<br>
<fantasai> birtles: but for CSS Animations the order of the animations comes from the 'animation-name' property<br>
<fantasai> Florian: If you're trying to add things that are not additive, what happens?<br>
<fantasai> birtles: Just as with interpolation, there are some types are not interpolable and we fall back to discrete<br>
<fantasai> birtles: for types we can't add, we fall back to replace<br>
<fantasai> Florian: Is this stable? Are there things that we could add in the future but can't right now?<br>
<fantasai> Florian: e.g. auto + <length><br>
<fantasai> birtles: Yes, and there is this problem also with interpolation<br>
<fantasai> birtles: Our hope with interpolation is that filling in gaps won't break content, we don't know but we hope<br>
<fantasai> birtles: so in this case also hoping<br>
<fantasai> fantasai: I think switching from replace to add is more likely to break that switching from discrete to gradual interpolation<br>
<fantasai> Florian: in JS, could throw an exception, but not in CSS<br>
<fantasai> birtles: Amelia had a concern about defining addition<br>
<fantasai> birtles: THere are different ways to add things<br>
<fantasai> birtles: e.g. blur(2px) + blur(5px)<br>
<fantasai> birtles: is it blur(2px) blur(5px) (sequence) or blur(7px)<br>
<fantasai> birtles: Web Animations has two different modes of addition<br>
<fantasai> birtles: add and accumulate (corresponding to above, respectively)<br>
<fantasai> birtles: For most types they're the same operation, but for list types are different<br>
<fantasai> birtles: I think Amelia was concerned because accumulation in SMIL is used in repetition<br>
<fantasai> birtles: but here it's just another type of add<br>
<fantasai> melanierichards: You mentioned that if you get to something that doesn't add, does it replace all the values added up below it<br>
<fantasai> melanierichards: [gives an example]<br>
<fantasai> birtles: overrides sum up to that point<br>
<fantasai> birtles: Add means "add myself to what's beneath me"<br>
<fantasai> birtles: You have a stack with A at the top and D at the bottom<br>
<fantasai> birtles: A and B are additive, C and D are not<br>
<fantasai> [discussion of what ordering means]<br>
<fantasai> dino: Don't say it's a stack. Everything is a list. THe last one wins<br>
<dbaron> so this would be like animation-name: D, C, B, A.<br>
<fantasai> birtles: The result of that would be A + B+ C<br>
<fantasai> dino: And if A wasn't additive, then result would be A<br>
<fantasai> birtles: And if all additive, then you get A+ B+ C+ D+ underlying style<br>
<fantasai> Florian: When you're switching into another style, add to the top of the stack, which can override those beneath it<br>
<fantasai> birtles: This proposal suggesting that if we expose in regular standard CSS, then the ordering comes from the Cascade<br>
<fantasai> birtles: if you have something of higher specificity, takes precedence<br>
<fantasai> dbaron: There are two different mechanisms proposed here<br>
<fantasai> birtles: Why have this to begin with?<br>
<dbaron> github: https://github.com/w3c/csswg-drafts/issues/1594<br>
<fantasai> birtles: The most common use of additive animation is for combining transform animations<br>
<glazou> q+ what about !important in such an addition<br>
<fantasai> birtles: to some degree can already do that with separate transform property in L2, where we have translate+rotate+scale properties<br>
<fantasai> birtles: Sovles a number of use cases, but doesn't solve all of them<br>
<glazou> q+ to ask about !important in such an addition<br>
<fantasai> birtles: If you wanted independent animations of the same operation, doesn't allow you to add those<br>
<fantasai> birtles: Doesn't help with other things like filters<br>
<fantasai> birtles: Any cases where separate transformatoins are not split out enough in our syntax<br>
<fantasai> birtles: The other way to solve these problems currently is to add another <div> wrapper element. Not very appealing when you have a lot of transforms<br>
<fantasai> birtles: So that's a summary of additive animation<br>
<fantasai> birtles: It's in Web Animations spec atm because the scope of Web Amnimations was to cover all the features of CSS Animations, ? Animations, and SMIL<br>
<fantasai> birtles: And SMIL already has this feature<br>
<fantasai> birtles: My next proposal is a straw man for providing the same functionality in static contexts for regular CSS, not just animations<br>
<fantasai> birtles: Here's an example of combining filters<br>
<fantasai> birtles shows off examples in the issue<br>
<fantasai> birtles: Some potential use cases<br>
<fantasai> birtles: proposal is to add a !add to the end of the declaration<br>
<glazou> q+ to mention variables for the first Part 2 use case 'filter'<br>
<fantasai> birtles: ordering is given by the cascade<br>
<fremy> q+<br>
<dbaron> q+ to talk about !add as only being for list-valued properties<br>
<fantasai> birtles: Not a fully fleshed-out proposal, just a rough idea<br>
<Rossen> a?<br>
<Rossen> q?<br>
<fantasai> birtles: Last question is whether to ship additive animations as specced or wait to line them up with these other features<br>
<Zakim> glazou, you wanted to ask about !important in such an addition and to mention variables for the first Part 2 use case 'filter'<br>
<Myles_> q+<br>
<fantasai> glazou: First, about your use case, about the filter property<br>
<fantasai> glazou: This is easily doable with variables<br>
<fantasai> glazou: Not for an unlimited number of classes or inputs, but if you know the scope of the styles you can get fairly doable with variables<br>
<fantasai> glazou: Using !add would allow some cases<br>
<fantasai> glazou: Next, !important, how does that interact with this?<br>
<fantasai> birtles: !important continues to affect where it appears in the cascade<br>
<fantasai> dbaron: I've wanted to have additive cascade for a long time, just didn't have a good syntax for it<br>
<fantasai> dbaron: Normal cascading order is that you have a set of declarations and the last declaration wins<br>
<fantasai> s/set/sorted set/<br>
<fantasai> dbaron: [describes something I missed]<br>
<Florian> q+<br>
<fantasai> glazou: What would happen to APIs that climbe the cascade and find *the* rule that wins?<br>
<fantasai> birtles: which APIs?<br>
<fantasai> glazou: Inspectors in borwsers<br>
<fantasai> birtles: Any Web-facing APIs?<br>
<dbaron> s/[describes something I missed]/The cascade just produces a sorted list of declarations. With !add, instead of taking just the highest one for a property, you'd take all of the highest ones down to the highest that doesn't have !add./<br>
<fantasai> s/APIs/APIs affected/<br>
<fantasai> fremy: there's a depreciated API in Chrome<br>
<fantasai> glazou: So browsers internally will have to update something, so OK but be careful<br>
<fantasai> birtles: inspector also shows which ruels were clobbered<br>
<fantasai> fantasai: So you'd have an ordered set of declarations that win, not just one<br>
<glazou> ack glazou<br>
<Rossen> q?<br>
<fantasai> Florian: If you getComputedStyle or some similar thing that give syou the computed value<br>
<fantasai> Florian: when something has been added<br>
<fantasai> Florian: do you return calc()? what do you do?<br>
<fantasai> birtles: Depends on the case<br>
<fantasai> birtles: similar to interpolation<br>
<fantasai> birtles: e.g. adding % and length, get a calc<br>
<fantasai> dbaron: A lot of these are lists, which would append items<br>
<fantasai> astearns: Do you get !add in the computed value?<br>
<fantasai> No<br>
<fantasai> dbaron: There's always a lowest value<br>
<fantasai> astearns: might have !add<br>
<Rossen> q?<br>
<fantasai> dbaron: then there's nothing to add to<br>
<Rossen> ack fremy<br>
<fantasai> fremy: There are two different proposal in this proposal<br>
<fantasai> fremy: There's list-accumulating behavior, which I and Tab have been discussing<br>
<fantasai> fremy: This is reasonable to add to browsers, and solves most of the use cases<br>
<fantasai> fremy: There's another proposal for things like auto + 50px<br>
<fantasai> fremy: That's a different propsoal<br>
<fantasai> fremy: I think thses are two very different proposals<br>
<Florian> q+<br>
<fantasai> dbaron: This is one of the things I wanted to raise as well<br>
<fantasai> fremy: At least in this WG there are ppl working on list things, I thin kit's easier to get there<br>
<fantasai> fremy: trying to transform all properties into this kind of list thing isn't something that we are ready to do yet<br>
<fantasai> astearns: Showing that we might wnat to go there is useful though<br>
<fantasai> birtles: This is implemented in Gecko, Blink, Servo, for more than just these types<br>
<fantasai> birtles: The ability to add different CSS types<br>
<fantasai> TabAtkins: in Web Animations<br>
<fantasai> fremy: I would be curious to see test cases<br>
<fantasai> fremy: Still, should be mentioned they are two different things<br>
<fantasai> fremy: Another thing I dislike !add is that it's mpossible to redefine a value<br>
<fantasai> fremy: e.g. you have filter: blur(val1) ??(val2)<br>
<fantasai> fremy: You can add to the list, but you can't alter preivious values in the list<br>
<astearns> I thought "filter: blur(val) !important;" would override<br>
<fantasai> Florian: You can always wipe out the entire list<br>
<fantasai> astearns, yes it would<br>
<fantasai> TabAtkins: At that point, you should use variables<br>
<fantasai> TabAtkins: variables allow coordinated substitution<br>
<fantasai> TabAtkins: uncoordinated addition is what we have to solve here<br>
<fantasai> fremy: Other concern is that ordering matters, e.g. transform + rotate and roate + transform are not the same<br>
<fantasai> fremy: it's a problem with web animations atm<br>
<fantasai> fremy: We have this problem with ppl making websites where everybody is screaming the highst z-index<br>
<fantasai> birtles: For Web Animations there's no number<br>
<fantasai> fremy: People wnat to control the order, and !add will follow the cascade order<br>
<fantasai> fremy: I think for lists, there are better ways to approach this problem with more control<br>
<fantasai> fremy: plain !add for list is not good enough<br>
<fantasai> fremy: When you are programming, used to being able to modify values and that's something not there, and I think it's really important<br>
<fantasai> astearns: Seems to me that you could fiddle with selector specificity<br>
<fantasai> fremy: specificity isn't always correlated with priority<br>
<fantasai> dbaron: Animations are one of th emore complicated cases<br>
<fantasai> dbaron: There are a bunch of other list-valued properties where you really want to combine<br>
<fantasai> dbaron: E.g. for counter properties, generally would prefer to have declarations combine, ordering doesn't matter<br>
<fantasai> fantasai: Stuff in text decoration also<br>
<fantasai> TabAtkins: a lot of properties are sets, not lists, order doesn't matter<br>
<fantasai> fremy: My proposal would be ot use an array syntax<br>
<fantasai> fremy: And you could put a number as the arg, or a name<br>
<fantasai> fremy writes some declarations<br>
<fantasai> transform: translate(0px, 0px)<br>
<fantasai> transform[zoom]: scale(1.1);<br>
<fantasai> transfomr[rotate]: rotate(180deg)<br>
<fantasai> transform[hover:100]: scale(1.0) translate(0px, 0px);<br>
<fantasai> transition[]: transfomr[hover:100] 0.5s eas-in<br>
<fantasai> birtles: We already have seaparate properties for rotate and zoom in Animations L2<br>
<fantasai> Rossen: So your feedback is there's no way to have selection and authoring of the list after initial decl<br>
<fantasai> Rossen: anything else?<br>
<fantasai> fremy: Also that cascading order is not always the orde ryou want to ocncatenate<br>
<fantasai> fremy: There's also the issue of coordination between frameworks<br>
<fantasai> fremy: If there's no way to coordinate other thandefining / redefining variables, then they can't coordinate<br>
<fantasai> fremy: You can't solve that problem with variables<br>
<Rossen> q?<br>
<fantasai> dbaron: Few comments<br>
<Rossen> ack dbaron<br>
<Zakim> dbaron, you wanted to talk about !add as only being for list-valued properties<br>
<fantasai> dbaron: One is that there are two separate pieces to birtles' proposal<br>
<fantasai> dbaron: I see these as independent<br>
<fantasai> dbaron: I se reasonable to do one and not the other in either way<br>
<fantasai> dbaron: Either one would get us some good benefits<br>
<astearns> I expect that if you're trying to allow more than one framework to compose animations you're going to have a lot of problems<br>
<fantasai> dbaron: But I think they are two independent things<br>
<fantasai> dbaron: When you start having multiple declaration of animations / ?<br>
<fantasai> dbaron: One is about combining declarations, the other about combining animations<br>
<fantasai> dbaron: I think as far as the cascading pieces, bits about combining declarations<br>
<fantasai> dbaron: I think one of the reasons I prefer something simple here is that I think something like !add or something like that<br>
<fantasai> dbaron: It's simple neough, if we can agree on a syntax, it's feasible to implement within existing engines in a reasonable amount of time<br>
<glazou> q+<br>
<fantasai> dbaron: I think fremy's other proposal has a lot more complexity, and I'd be more hesitant to go down that path<br>
<fantasai> fremy: I'm not arguing for names, I'm arguing for numbers<br>
<fantasai> dbaron: There's a bit more complexity there, although a little... I don't know<br>
<fantasai> dbaron:Other comment<br>
<fantasai> dbaron: Like fremy, I saw this as being only for list-valued propeties<br>
<fantasai> dbaron: I see that SMIL has more general mechanisms, and I have mixed feelings for having those in the same system<br>
<fantasai> dbaron: It's pulling in a big part of SMIL to pull into CSS, to do addition of other than comma-separated lists<br>
<fantasai> dbaron: Other small comment is that in that middle example, I would expect animation-composit itself ot be a list-valued property<br>
<fantasai> dbaron: And therefore I would expect that second lne to be animation-composite: add !add;<br>
<fantasai> dbaron: Because I think you want to add youre animation-composite value to the list, not replace the list<br>
<Rossen> ack Myles_<br>
<fantasai> Myles_: I have a couple points<br>
<fantasai> Myles_: One already made iwhich is 2nd piece of proposal can be used in many places<br>
<fantasai> Myles_: We've gotten lots of request for ppl to turn on various font features<br>
<fantasai> Myles_: and this makes that easier<br>
<dbaron> fantasai: font-variant rather than font-feature-settings<br>
<fantasai> Myles_: in WebKit we have an issue with text-decoration<br>
<dbaron> (but it's worse for font-variation-settings!)<br>
<fantasai> Myles_: If parent says text-decoration: underline and child ses text-decoration: strike-through<br>
<fantasai> Myles_: In both of those examples, the addition occurs down the DOM, not across cascade<br>
<fantasai> dbaron: One of the cases we discussed is what happens if you have adds all the way down<br>
<fantasai> dbaron: If you do adds all the way down on an inherited value<br>
<fantasai> dbaron: you add to the base value, which ofr inherited properties is the inherited value<br>
<Rossen> q?<br>
<dbaron> s/inherited value/inherited property/<br>
<dbaron> (the second last one should be substituted)<br>
<fantasai> Myles_: Other comment was on pulling apart a list and inserting stuff in the middle<br>
<fantasai> Myles_: Issue of different teams trying to coordinate, this is difficult for a company<br>
<fantasai> Myles_: we already have two different ways for differnet areas of a document interact<br>
<fantasai> Myles_: The cascade through specificity, and then inheritance through document tree<br>
<fantasai> Myles_: adding yet another way seems complicated, seems better to re-use existing ones<br>
<fantasai> Myles_: Another comment<br>
<fantasai> Myles_: You had na issue of adding values<br>
<fantasai> Myles_: I fyou have line-height: 50px and line-height: normal, how do you add?<br>
<fantasai> birtles: For some we use calc(), but some things can't add and thos efall back to replace<br>
<fantasai> birtles: In our impl, the function that does interpolation is the same as the one that does addition<br>
<fremy> q+ to reply to Myles with new idea<br>
<fantasai> fantasai: On that topic, if we have only the list-valued addition for now<br>
<fantasai> fantasai: That's avoids the problem of forwards-compat for types that we can't add yet<br>
<fantasai> s/add/add (or interpolate)/<br>
<dbaron> Florian: so if you restricted to list-valued properties, then !add would be a syntax error for other properties?<br>
<dbaron> fantasai, dbaron: yes<br>
<fantasai> fantasai^: I think switching from replace to add is a more likely compat problem than switching interpolation from discrete to gradual in the future<br>
<Rossen> q?<br>
<fantasai> birtles: I feel a bit uncomfortable drawing a line between list types and non list types<br>
<fantasai> birtles: in implementation terms there's no distinction<br>
<fantasai> birtles: For an author that you can add translate(200px) to translate(200px) but can't add margins of 200px, seems awkward<br>
<Rossen> q?<br>
<fantasai> birtles: Also ...<br>
<fantasai> Florian: Less likely that people wil use something that gets thrown out and is a syntax error (though still possible they leave it in the stylesheet, less likely)<br>
<fantasai> Florian: than if it has a particular behvaior (replace) and we wnat ot hcange it later to add<br>
<Rossen> ack Florian<br>
<fantasai> Florian: Not an objection, but a concern about the compat path<br>
<fantasai> Florian: This allows things that were impractical<br>
<fantasai> Florian: but also is same as using calc() in some cases<br>
<fantasai> Florian: I'm a bit worried about cases of e.g. Chrome shipping way earlier than other impls and authors relying on it and it being broken in other impls<br>
<fantasai> fantasai: This is an issue with every major feature we add to CSS, can't decide t ojust not add things<br>
<fantasai> glazou: I'm a bit surprised we're using !add<br>
<Rossen> o+:<br>
<fantasai> glazou: Woudl prefer property+:value<br>
<glazou> no<br>
<fantasai> dbaron: would love property += value, but we're not using = :/<br>
<Rossen> q?<br>
<glazou> would prefer +property<br>
<Florian> +prop: value / prop+: value<br>
<fantasai> fantasai: +property:value ?<br>
<Rossen> ack glazou<br>
<Rossen> ack fremy<br>
<Zakim> fremy, you wanted to reply to Myles with new idea<br>
<fantasai> fremy: I'm OK to not have ability resort stacking order<br>
<fantasai> fremy: But I want ability to give added values different weights<br>
<fantasai> s/weights/timing rates/<br>
<astearns> property: value +add;<br>
<fantasai> fremy: I want to say that "for this part I just added, I want to transition the addition at a different rate"<br>
<fantasai> Myles_: For font-features that has no relevance, so this feature should be scoped appropriately<br>
<fantasai> birtles: I would liked to get a go/no-go for shipping additive animations<br>
<fantasai> birtles: and also to gague interest with regards to refining the static CSS proposal<br>
<fremy> btw glazou dbaron: my syntax proposal is { transform[]: added-value; }<br>
<dbaron> s/gague/gauge/<br>
<fantasai> fantasai: I have no idea about Web Animations, but the additive cascade is something people have wanted to have for a long tme, and it seems like your proposal has a lot of interest from the people here<br>
<fantasai> fantasai: No idea how long it'll take but there's interest :)<br>
<TabAtkins> fremy: For poking at individual entries of a list, we have the proposal for list-indexed sub-properties...<br>
<fremy> astearns: yes; could be a different feature really, just want to make sure we think about a path forward ;)<br>
<fantasai> birtles: We have same compat questions for the animated version of the proposal, shoudl they block us from shipping additive animations or are they less sever in the case of Web Animations?<br>
<TabAtkins> fremy: Just need to add commas to the transform syntax, to let it become a comma-separated list.<br>
<dbaron> fantasai: Was a suggestion to throw exception for things you can't add.<br>
<dbaron> fantasai: We can't do that in CSS syntax.<br>
<fremy> TabAtkins: yes, could work<br>
<dbaron> birtles: probably worse for compat, since first browser to ship will see unhandled exceptions<br>
<dbaron> fantasai: if we can throw exceptions for use cases and remove later, less concerned about compat<br>
<dbaron> q+<br>
<dbaron> fantasai: if chrome ships auto+100px working, it's because they've figured out how to make that work, and everyone else will want to make that work<br>
<fantasai> dbaron: I guess I mostly disagree with fantasai's comment on exceptions<br>
<fantasai> dbaron: I think the two things are mostly indpenednet, and I don't see a problem with animations stuff moving forward if additive cascade doesn't<br>
<fantasai> birtles: What we have in the spec is a definition of addition for each type, that needs to be written before shipping<br>
<fantasai> birtles: pretty simple though<br>
<dbaron> s/fremy:/fremy,/<br>
<dbaron> s/TabAtkins:/TabAtkins,/<br>
<fantasai> birtles: additive animations implementation<br>
<fantasai> birtles: go forward, assumign test suite / compat etc.<br>
<fantasai> RESOLVED: No concerns wrt shipping Web Animations<br>
<fantasai> fantasai: Do we want to conclude something on additive cascade?<br>
<fantasai> RESOLVED: CSSWG is interested in working on additive cascade proposals.<br>
<dbaron> fantasai: can someone draft an ED?<br>
<dbaron> alan: I think it's premature to put in a spec.<br>
<fremy> ScribeNick: fremy<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1594#issuecomment-319631001 using your GitHub account
Received on Wednesday, 2 August 2017 10:15:58 UTC