html cascade css,[css-cascade] Additive CSS

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.

The full IRC log of that discussion

Topic: Additive CSS

ScribeNick: fantasai

https://github.com//issues/1594

birtles: This issue covers everything I want to say

birtles: Want to introduce idea of addititve CSS

birtles: Figure out if we want to do this soon or not

birtles: We have something like this in Animations, wanted to see if we should pursue in static CSS also

birtles: Start off with additive animation

birtles: then static additive CSS

birtles: Normally when you have animations in CSS

birtles: basically you can only ever have one animation affecting the same property at the same time

birtles: This demo here has animations spin and swell

birtles: when I apply the both

birtles: you can see only the swell animation is taking effect

http://slides.com/birtles/browser-animation-2017-2#/3/11

birtles: This can be due to the nature of the cascade, only one animation declaration will win

birtles: But even when you specify two animations in a isngle declarations

birtles: then the declarations in the keyframes could override each other

birtles: Problem in animations

birtles: There's a means for solving that which comes from SMIL

birtles: and is in Web Animations

birtles: where you define the properties as being addititve

birtles shows demo with Web Animations that shows spinning and growing at the same time

glazou: Do you put composite=add on both of them?

birtles: only the top one

birtles: If you declare an animation as additive, then it adds to underlying unanimated style, or adds to underlying animations

birtles: wherever in the chain doesn't say add, clobbers earlier declarations

glazou: animate(composite=add) that's ok

glazou: but for properties...

glazou: parsing is not done yet?

birtles: That feature is defined in Web Animations, implemented (but not shipping) in Chrome & Firefox

birtles: Property for CSS Animations 2 to give same feature

birtles: How does it actually work?

birtles: different animations types, define what it means to add animations

birtles: then need to define order, since not operations are commutative

birtles: and also need to know which to exclude

birtles: Web Animations there's a defined order

birtles: but for CSS Animations the order of the animations comes from the 'animation-name' property

Florian: If you're trying to add things that are not additive, what happens?

birtles: Just as with interpolation, there are some types are not interpolable and we fall back to discrete

birtles: for types we can't add, we fall back to replace

Florian: Is this stable? Are there things that we could add in the future but can't right now?

Florian: e.g. auto +

birtles: Yes, and there is this problem also with interpolation

birtles: Our hope with interpolation is that filling in gaps won't break content, we don't know but we hope

birtles: so in this case also hoping

fantasai: I think switching from replace to add is more likely to break that switching from discrete to gradual interpolation

Florian: in JS, could throw an exception, but not in CSS

birtles: Amelia had a concern about defining addition

birtles: THere are different ways to add things

birtles: e.g. blur(2px) + blur(5px)

birtles: is it blur(2px) blur(5px) (sequence) or blur(7px)

birtles: Web Animations has two different modes of addition

birtles: add and accumulate (corresponding to above, respectively)

birtles: For most types they're the same operation, but for list types are different

birtles: I think Amelia was concerned because accumulation in SMIL is used in repetition

birtles: but here it's just another type of add

melanierichards: You mentioned that if you get to something that doesn't add, does it replace all the values added up below it

melanierichards: [gives an example]

birtles: overrides sum up to that point

birtles: Add means "add myself to what's beneath me"

birtles: You have a stack with A at the top and D at the bottom

birtles: A and B are additive, C and D are not

[discussion of what ordering means]

dino: Don't say it's a stack. Everything is a list. THe last one wins

so this would be like animation-name: D, C, B, A.

birtles: The result of that would be A + B+ C

dino: And if A wasn't additive, then result would be A

birtles: And if all additive, then you get A+ B+ C+ D+ underlying style

Florian: When you're switching into another style, add to the top of the stack, which can override those beneath it

birtles: This proposal suggesting that if we expose in regular standard CSS, then the ordering comes from the Cascade

birtles: if you have something of higher specificity, takes precedence

dbaron: There are two different mechanisms proposed here

birtles: Why have this to begin with?

github: https://github.com//issues/1594

birtles: The most common use of additive animation is for combining transform animations

q+ what about !important in such an addition

birtles: to some degree can already do that with separate transform property in L2, where we have translate+rotate+scale properties

birtles: Sovles a number of use cases, but doesn't solve all of them

q+ to ask about !important in such an addition

birtles: If you wanted independent animations of the same operation, doesn't allow you to add those

birtles: Doesn't help with other things like filters

birtles: Any cases where separate transformatoins are not split out enough in our syntax

birtles: The other way to solve these problems currently is to add another

wrapper element. Not very appealing when you have a lot of transforms

birtles: So that's a summary of additive animation

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

birtles: And SMIL already has this feature

birtles: My next proposal is a straw man for providing the same functionality in static contexts for regular CSS, not just animations

birtles: Here's an example of combining filters

birtles shows off examples in the issue

birtles: Some potential use cases

birtles: proposal is to add a !add to the end of the declaration

q+ to mention variables for the first Part 2 use case 'filter'

birtles: ordering is given by the cascade

q+

q+ to talk about !add as only being for list-valued properties

birtles: Not a fully fleshed-out proposal, just a rough idea

a?

q?

birtles: Last question is whether to ship additive animations as specced or wait to line them up with these other features

glazou, you wanted to ask about !important in such an addition and to mention variables for the first Part 2 use case 'filter'

q+

glazou: First, about your use case, about the filter property

glazou: This is easily doable with variables

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

glazou: Using !add would allow some cases

glazou: Next, !important, how does that interact with this?

birtles: !important continues to affect where it appears in the cascade

dbaron: I've wanted to have additive cascade for a long time, just didn't have a good syntax for it

dbaron: Normal cascading order is that you have a set of declarations and the last declaration wins

s/set/sorted set/

dbaron: [describes something I missed]

q+

glazou: What would happen to APIs that climbe the cascade and find *the* rule that wins?

birtles: which APIs?

glazou: Inspectors in borwsers

birtles: Any Web-facing APIs?

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./

s/APIs/APIs affected/

fremy: there's a depreciated API in Chrome

glazou: So browsers internally will have to update something, so OK but be careful

birtles: inspector also shows which ruels were clobbered

fantasai: So you'd have an ordered set of declarations that win, not just one

ack glazou

q?

Florian: If you getComputedStyle or some similar thing that give syou the computed value

Florian: when something has been added

Florian: do you return calc()? what do you do?

birtles: Depends on the case

birtles: similar to interpolation

birtles: e.g. adding % and length, get a calc

dbaron: A lot of these are lists, which would append items

astearns: Do you get !add in the computed value?

No

dbaron: There's always a lowest value

astearns: might have !add

q?

dbaron: then there's nothing to add to

ack fremy

fremy: There are two different proposal in this proposal

fremy: There's list-accumulating behavior, which I and Tab have been discussing

fremy: This is reasonable to add to browsers, and solves most of the use cases

fremy: There's another proposal for things like auto + 50px

fremy: That's a different propsoal

fremy: I think thses are two very different proposals

q+

dbaron: This is one of the things I wanted to raise as well

fremy: At least in this WG there are ppl working on list things, I thin kit's easier to get there

fremy: trying to transform all properties into this kind of list thing isn't something that we are ready to do yet

astearns: Showing that we might wnat to go there is useful though

birtles: This is implemented in Gecko, Blink, Servo, for more than just these types

birtles: The ability to add different CSS types

TabAtkins: in Web Animations

fremy: I would be curious to see test cases

fremy: Still, should be mentioned they are two different things

fremy: Another thing I dislike !add is that it's mpossible to redefine a value

fremy: e.g. you have filter: blur(val1) ??(val2)

fremy: You can add to the list, but you can't alter preivious values in the list

I thought "filter: blur(val) !important;" would override

Florian: You can always wipe out the entire list

astearns, yes it would

TabAtkins: At that point, you should use variables

TabAtkins: variables allow coordinated substitution

TabAtkins: uncoordinated addition is what we have to solve here

fremy: Other concern is that ordering matters, e.g. transform + rotate and roate + transform are not the same

fremy: it's a problem with web animations atm

fremy: We have this problem with ppl making websites where everybody is screaming the highst z-index

birtles: For Web Animations there's no number

fremy: People wnat to control the order, and !add will follow the cascade order

fremy: I think for lists, there are better ways to approach this problem with more control

fremy: plain !add for list is not good enough

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

astearns: Seems to me that you could fiddle with selector specificity

fremy: specificity isn't always correlated with priority

dbaron: Animations are one of th emore complicated cases

dbaron: There are a bunch of other list-valued properties where you really want to combine

dbaron: E.g. for counter properties, generally would prefer to have declarations combine, ordering doesn't matter

fantasai: Stuff in text decoration also

TabAtkins: a lot of properties are sets, not lists, order doesn't matter

fremy: My proposal would be ot use an array syntax

fremy: And you could put a number as the arg, or a name

fremy writes some declarations

transform: translate(0px, 0px)

transform[zoom]: scale(1.1);

transfomr[rotate]: rotate(180deg)

transform[hover:100]: scale(1.0) translate(0px, 0px);

transition[]: transfomr[hover:100] 0.5s eas-in

birtles: We already have seaparate properties for rotate and zoom in Animations L2

Rossen: So your feedback is there's no way to have selection and authoring of the list after initial decl

Rossen: anything else?

fremy: Also that cascading order is not always the orde ryou want to ocncatenate

fremy: There's also the issue of coordination between frameworks

fremy: If there's no way to coordinate other thandefining / redefining variables, then they can't coordinate

fremy: You can't solve that problem with variables

q?

dbaron: Few comments

ack dbaron

dbaron, you wanted to talk about !add as only being for list-valued properties

dbaron: One is that there are two separate pieces to birtles' proposal

dbaron: I see these as independent

dbaron: I se reasonable to do one and not the other in either way

dbaron: Either one would get us some good benefits

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

dbaron: But I think they are two independent things

dbaron: When you start having multiple declaration of animations / ?

dbaron: One is about combining declarations, the other about combining animations

dbaron: I think as far as the cascading pieces, bits about combining declarations

dbaron: I think one of the reasons I prefer something simple here is that I think something like !add or something like that

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

q+

dbaron: I think fremy's other proposal has a lot more complexity, and I'd be more hesitant to go down that path

fremy: I'm not arguing for names, I'm arguing for numbers

dbaron: There's a bit more complexity there, although a little... I don't know

dbaron:Other comment

dbaron: Like fremy, I saw this as being only for list-valued propeties

dbaron: I see that SMIL has more general mechanisms, and I have mixed feelings for having those in the same system

dbaron: It's pulling in a big part of SMIL to pull into CSS, to do addition of other than comma-separated lists

dbaron: Other small comment is that in that middle example, I would expect animation-composit itself ot be a list-valued property

dbaron: And therefore I would expect that second lne to be animation-composite: add !add;

dbaron: Because I think you want to add youre animation-composite value to the list, not replace the list

ack Myles_

Myles_: I have a couple points

Myles_: One already made iwhich is 2nd piece of proposal can be used in many places

Myles_: We've gotten lots of request for ppl to turn on various font features

Myles_: and this makes that easier

fantasai: font-variant rather than font-feature-settings

Myles_: in WebKit we have an issue with text-decoration

(but it's worse for font-variation-settings!)

Myles_: If parent says text-decoration: underline and child ses text-decoration: strike-through

Myles_: In both of those examples, the addition occurs down the DOM, not across cascade

dbaron: One of the cases we discussed is what happens if you have adds all the way down

dbaron: If you do adds all the way down on an inherited value

dbaron: you add to the base value, which ofr inherited properties is the inherited value

q?

s/inherited value/inherited property/

(the second last one should be substituted)

Myles_: Other comment was on pulling apart a list and inserting stuff in the middle

Myles_: Issue of different teams trying to coordinate, this is difficult for a company

Myles_: we already have two different ways for differnet areas of a document interact

Myles_: The cascade through specificity, and then inheritance through document tree

Myles_: adding yet another way seems complicated, seems better to re-use existing ones

Myles_: Another comment

Myles_: You had na issue of adding values

Myles_: I fyou have line-height: 50px and line-height: normal, how do you add?

birtles: For some we use calc(), but some things can't add and thos efall back to replace

birtles: In our impl, the function that does interpolation is the same as the one that does addition

q+ to reply to Myles with new idea

fantasai: On that topic, if we have only the list-valued addition for now

fantasai: That's avoids the problem of forwards-compat for types that we can't add yet

s/add/add (or interpolate)/

Florian: so if you restricted to list-valued properties, then !add would be a syntax error for other properties?

fantasai, dbaron: yes

fantasai^: I think switching from replace to add is a more likely compat problem than switching interpolation from discrete to gradual in the future

q?

birtles: I feel a bit uncomfortable drawing a line between list types and non list types

birtles: in implementation terms there's no distinction

birtles: For an author that you can add translate(200px) to translate(200px) but can't add margins of 200px, seems awkward

q?

birtles: Also ...

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)

Florian: than if it has a particular behvaior (replace) and we wnat ot hcange it later to add

ack Florian

Florian: Not an objection, but a concern about the compat path

Florian: This allows things that were impractical

Florian: but also is same as using calc() in some cases

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

fantasai: This is an issue with every major feature we add to CSS, can't decide t ojust not add things

glazou: I'm a bit surprised we're using !add

o+:

glazou: Woudl prefer property+:value

no

dbaron: would love property += value, but we're not using = :/

q?

would prefer +property

+prop: value / prop+: value

fantasai: +property:value ?

ack glazou

ack fremy

fremy, you wanted to reply to Myles with new idea

fremy: I'm OK to not have ability resort stacking order

fremy: But I want ability to give added values different weights

s/weights/timing rates/

property: value +add;

fremy: I want to say that "for this part I just added, I want to transition the addition at a different rate"

Myles_: For font-features that has no relevance, so this feature should be scoped appropriately

birtles: I would liked to get a go/no-go for shipping additive animations

birtles: and also to gague interest with regards to refining the static CSS proposal

btw glazou dbaron: my syntax proposal is { transform[]: added-value; }

s/gague/gauge/

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

fantasai: No idea how long it'll take but there's interest :)

fremy: For poking at individual entries of a list, we have the proposal for list-indexed sub-properties...

astearns: yes; could be a different feature really, just want to make sure we think about a path forward ;)

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?

fremy: Just need to add commas to the transform syntax, to let it become a comma-separated list.

fantasai: Was a suggestion to throw exception for things you can't add.

fantasai: We can't do that in CSS syntax.

TabAtkins: yes, could work

birtles: probably worse for compat, since first browser to ship will see unhandled exceptions

fantasai: if we can throw exceptions for use cases and remove later, less concerned about compat

q+

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

dbaron: I guess I mostly disagree with fantasai's comment on exceptions

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

birtles: What we have in the spec is a definition of addition for each type, that needs to be written before shipping

birtles: pretty simple though

s/fremy:/fremy,/

s/TabAtkins:/TabAtkins,/

birtles: additive animations implementation

birtles: go forward, assumign test suite / compat etc.

RESOLVED: No concerns wrt shipping Web Animations

fantasai: Do we want to conclude something on additive cascade?

RESOLVED: CSSWG is interested in working on additive cascade proposals.

fantasai: can someone draft an ED?

alan: I think it's premature to put in a spec.

ScribeNick: fremy