- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 Jun 2024 10:35:27 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-values-5] Interpolating calc-size() more generally`, and agreed to the following:
* `RESOLVED: use the name interpolate-size: numeric-only | allow-keywords, as an inherited property`
<details><summary>The full IRC log of that discussion</summary>
<jarhar> dbaron: one of the things that came up the last time we discussee calc size was that people didnt like the idea that you had to write calc size around one of the endpoints of the animation to opt into interpolation between size keywords<br>
<jarhar> dbaron: there was an additional piece of feedback from the tag review hich is that the using that mechanism as the opt in is not good for gradual adoption of the feature in that the opt in mechanism is a change to the way you write the value at one of the endpoints then if you you need to - either you need to explicitly write that value twice<br>
<jarhar> without an opt in and second with a calc size around it or your code will be broken in downlevel browsers for the animation and end states particularly when looking at transition but not animation<br>
<jarhar> dbaron: which raises the priority of ahving another opt in mechanism. what this is about is bikesheding a name for what is the mechanism to let developers opt in to animating height from zero to auto or similar things<br>
<jarhar> dbaron: there was a discussion of two options in the issue, and maybe even more than that but i think i had posted a comment with two options three weeks ago with ? and one was size interpolation<br>
<jarhar> dbaron: there was some discussion about whether it makes sense to combine this with transwition-behavior and i think there are two arguments for why i think it does not make sense to combine it with transition behavior<br>
<astearns> s/?/size-keyword-interpolation/<br>
<jarhar> dbaron: one is that this is about all types of animations, transitions animations and this is also web animations<br>
<astearns> s/size interpolation/size-interpolation/<br>
<jarhar> dbaron: the second and more important one i think is that transition behavior allow discrete is something that in most cases you want to use specifically for a given transition but it doesn't make sense to opt into globally because except for display and content-visibility, you cant really use transition behavior allow discrete usefully without<br>
<jarhar> using different timing functions for both directions, in particular you need to use a step end function etc to do something thats symetrical<br>
<jarhar> dbaron: and doesn't just flip at 50% which is usually not what you want when animating a discrete property<br>
<jarhar> dbaron: and because of that transition behaviro alow discrete is something you want to use granularly to a speicifc property. this really only exists for compat, if we were designing from the start we would have just made this behavior. we've had this on the web for 14 years without this and theres too much dode on the web that would just break if<br>
<jarhar> we turned this on. this is something where what we want is really just a gllbal opt in and we want a property that devs can just set on a root of something and just opt themselves into the new behavior and not have to use it in a granular way when they specify transitions<br>
<jarhar> dbaron: i had two naming options in the issue: ?? and ??, i preferred the first one. there are a number of options in the issue, what i just said is a response to what elika wrote in the issue<br>
<astearns> ack fantasai<br>
<fantasai> https://github.com/w3c/csswg-drafts/issues/10294#issuecomment-2149359260<br>
<jarhar> fantasai: my comemtn was that rather than adding a new property one off for every new thing that we figure out how to animate, it would be nice if we had a single property that said flip on interpolation for these things, and if you want to cascade these we have a longhand<br>
<leaverou2> q+<br>
<fantasai> animation-interpolation: normal | size-keywords || transition-discrete || add stuff here<br>
<fantasai> animation-interpolation-size: normal | allow-keywords<br>
<fantasai> animation-interpolation-transition: <'transition-behavior'><br>
<jarhar> fantasai: my proposal is ? which takes a buncho f keywords and takes longhands so you can set them independently<br>
<astearns> s/?/a animation-interpolation shorthand/<br>
<jarhar> fantasai: a lot of poeple do want to set it glboally ?? step start makes a lot of sense but transition behavior doesn't turn things on unless you have explicitly specified that property in your treansition property list<br>
<jarhar> fantasai: transitioning all properties doesn't run on the discrete properties<br>
<jarhar> dbaron: my memory is that was true in the earlier rounds of the proposal when we were trying to do it with the opt in<br>
<jarhar> fantasai: people have requested a global switch, we should have one that does everything except all. if you're trying to transition a discreet property then you might want to have that work. thats a separate issue from adding this one, we should have a framework to which we are adding these things<br>
<ydaniv> q+<br>
<leaverou2> q?<br>
<jarhar> fantasai: this wont be the last time, this is the second time we are doing it, one off property thats not consistent i dont think is a great forwards plan. we shoul daccept that we are going to do this for a whole bunch of stuff<br>
<jarhar> fantasai: lets put them under a consistent syntax<br>
<jarhar> dbaron: im more willing to accept half that argument. consistent naming and syntax im fine with. the idea of having a shorthand for doing a bunch of them at once i am skeptical of, these are going to be compat things that people are going to opt into at different times and i dont want them to break each other. want them to cascade separately rather<br>
<jarhar> than together<br>
<TabAtkins> +1 to dbaron here, we *need* them separately (unfortunately) *because* of future-compat<br>
<bramus> +1<br>
<TabAtkins> that's the reason we're having to add opt-ins in the first place<br>
<astearns> ack leaverou<br>
<jarhar> leaverou2: we have been discussing how people have to specify ?? for these cases, we have been trying to design for colors how to extend transitions and animations so that authors can provide ?? i wonder if we can solve these with the same properties so that we dont have to keep adding, transition interpolation options, just wanted to throw it in<br>
<astearns> ack ydaniv<br>
<fantasai> s/??/color interpolation space/<br>
<astearns> interpolation-switch-foo and interpolation-switch-bar?<br>
<jarhar> ydaniv: +1 to what elika suggested. i had a similar idea for a way forward with aadding a animation wide ? to sort of fix the way we have css animations with keyframe wide ? entire animation so something like animation timing function mode or is mode that these all folow the same ? of ideas. bramus had a proposal for something like general<br>
<jarhar> configuration polace but another idea is maybe we can have this sort of stuff inherhit buydefault and use the cascade<br>
<jarhar> fantasai: we dont want them to inherit by default. someone will design this component and animations for it and someone else design whats in the slot but didnt expect this extra bheavior so i think you want it on a non inherited property<br>
<astearns> ack dbaron<br>
<bramus> q+<br>
<jarhar> dbaron: for the compatibility opt in i do want it to be an inherited property because its a thing that we really want developers to be able to set once and then have the new thing and they dont have to worry about it. they can just set it on the root or set it on the root of their component and then just have it enabled<br>
<jarhar> fantasai: if you set it as an inheritable property then it will aply to - you will have to know to unset it to certain parts of the document<br>
<emilio> +1 on inherited, otherwise eventually people will *, *::before, *::after { foo: inherit } and that's slower<br>
<jarhar> dbaron: that is a slight disadvantage if you have components that youre not in control of. its a temporary disadvantage, the hope is that people will expect to be on over time and thats a short term problem for components that dont work with it enabled<br>
<fantasai> TabAtkins, yeah, that's why I suggested having longhands<br>
<miriam> q+ to respond<br>
<kbabbitt> +1 to inherited for the same reason as emilio<br>
<TabAtkins> regardless of longhands, an 'all' shorthand value is off the table. (but a shorthand that lets you turn on all the individual opt-ins would be fine, yeah)<br>
<jarhar> dbaron: the other thing i wanted to say is that in response to what both lea and ydaniv were asking, i think one of the key points here is that because this is a compat opt in i want to go back to the point that i want this to cascade separately from other properties so they dont have multiple declarations. im not saying i dont want to do the<br>
<jarhar> things youre asking for, i just want them to be in a different property from this one, maybe with a different naming scheme<br>
<fantasai> TabAtkins, 100% agreed.<br>
<jarhar> dbaron: explicitly no shorthand, naming scheme ties them together<br>
<astearns> ack bramus<br>
<bramus> https://github.com/w3c/csswg-drafts/issues/9109<br>
<fantasai> TabAtkins, unless we want all-2024, all-2025, all-2027 etc. :p<br>
<jarhar> bramus: i want to respond to ?'s remark about config thing which he explicitly mentioned. leads to this issue right here. i dont think that would be a good option for things already mentioned ?? global switch and you would want that here, older animation library thats not using the new way of transitioning, so it needs to be on a per case basis in<br>
<jarhar> your dom<br>
<jarhar> bramus: ?? and not a global on or off thing<br>
<jarhar> q+<br>
<astearns> ack miriam<br>
<Zakim> miriam, you wanted to respond<br>
<dbaron> s/?'s/ydaniv's/<br>
<bramus> s/?? global switch/to have a global switch<br>
<jarhar> miriam: i disagree that the sense that inheritance makes it harder to override because people are going to set it on the universal selector and before and after and thats oging to be slow and you still need to know to override it when you need to override it, dont see ? about inheritance here<br>
<bramus> s/and you would want that here/and you would NOT want that here<br>
<astearns> ack jarhar<br>
<fantasai> fantasai: that's fair<br>
<bramus> jarhar: I feel sad that transition-behavior is not good enough for this<br>
<jarhar> dbaron: if noone else is on the queue, id like to get consensus on a name. i want to get elikas ? if i could get that open<br>
<fantasai> https://github.com/w3c/csswg-drafts/issues/10294#issuecomment-2149359260<br>
<fantasai> animation-interpolation-size: normal | allow-keywords<br>
<jarhar> dbaron: i wanted to try to see if we can get consensus on a name. one of the things elika wrote in a comment was animation interpolation size colon normal or allow keywords. does that seem reasonable? i dont want to add the longhand here.<br>
<jarhar> dbaron: shorthand, sorry<br>
<dbaron> animation-interpolation-size: normal | allow-keywords<br>
<jarhar> dbaron: would people be ok with animation interpolation size normal ? keywords<br>
<jarhar> astearns: should animation be in the name?<br>
<jarhar> fantasai: its confusing to do animation, it applies to transitions and animations, animations in a much more general sense<br>
<lwarlow> q+<br>
<jarhar> fantasai: on the flip side, we also have interpolation used for example gradient, color inteprolation for gradient is much more different<br>
<jarhar> fantasai: too generic idk?<br>
<lwarlow> q-<br>
<fantasai> s/too/interpolation is maybe too/<br>
<jarhar> astearns: it is a ? scheme. ? so back up to irc i suggested interpolation switch as a prefix for this stuff<br>
<jarhar> astearns: you have an interpolation switch size, interpolation switch color space<br>
<kbabbitt> q+<br>
<bramus> q+ for the name: interpolation-behavior?<br>
<jarhar> dbaron: i liked just starting with interpolation, im hesitant to throw switch in there. its almost like interpolation property<br>
<jarhar> fantasai: its like interpolation mode. if we dont need to add mode then dont<br>
<jarhar> astearns: we dont have to make these short, were designing them so that authors dont have to use them very often<br>
<jarhar> fantasai: i dont think switch makes it less generic. we dont need it to be long, just clear<br>
<jarhar> bramus: maybe interpolation behavior like transition behavior?<br>
<bramus> q-<br>
<jarhar> dbaron: i didnt want that because i want a property thats specific to the sizing keywords thing because we might need other things for color or images later on. because of the compat aspects i want these to be separate properties rather than separate values<br>
<astearns> ack kbabbitt<br>
<dbaron> interpolation-size: normal | allow-keywords<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to respond to that<br>
<jarhar> kbabbitt: my comment on the naming is that typically in css the last noun is the sort of type of thing that were modifying or setting, so i guess my issue with interpolation size is that it sounds like its setting a size of something like background size, so id favor size interpolation, interpolation switch<br>
<lwarlow> q+<br>
<jarhar> fantasai: we could make it sizing like box sizing<br>
<jarhar> dbaron: thats the tension between what you want which lines up with my original proposal vs elikas desire to have ? things and i dont see a good way to do both<br>
<jarhar> fantasai: someday id also like to have a size shorthand<br>
<jarhar> astearns: lets not go down that rabbit hole just yet<br>
<dbaron> interpolate-size-keywords: none | normal<br>
<jarhar> lwarlow: we could do size interpolation, although we do want ?<br>
<lwarlow> q-<br>
<jarhar> dbaron: i just typed in one other suggestion which is inteprolate size keywords, none is the initial value. maybe tries to satisfy both because it starts with interpolate, and im ok with interpolation as well, it then tries to talk about what the thing is and by putting words in the name of the property and it doesn't sound like its setting a size<br>
<jarhar> lwarlow: normal as the value seems confusing, dont know which is which<br>
<khush> allow, disallow?<br>
<jarhar> dbaron: the problem is that we try to avoid the values like yes or no because we might want a third one at some point<br>
<jarhar> fantasai: i wonder if using interpolate size instead of interpolation makes it clearer that this isnt going to be a size<br>
<jarhar> dbaron: so youre thinking interpolate size colon auto or allow keywords? or normal?<br>
<dbaron> interpolate-size: normal | allow-kewyords<br>
<jarhar> fantasai: if we want to pick a value other than normal, we would like it to be the new normal<br>
<jarhar> astearns: legacy<br>
<jarhar> astearns: maybe that doesn't convey enough<br>
<jarhar> fantasai: numeric ? keywords<br>
<jarhar> dbaron: numeric only and allow keywords<br>
<dbaron> interpolate-size: numeric-only | allow-keywords<br>
<jarhar> lwarlow: is it actually ? though? could you use it ?<br>
<jarhar> dbaron: calc is numeric, its number<br>
<jarhar> lwarlow: yeah i guess<br>
<jarhar> fantasai: technical term in the spec is dimensions but i dont like that<br>
<jarhar> lwarlow: how important is that keyword? thats the one that you're generally not going to be set in not the deault value so we could give it a slightly ?<br>
<jarhar> fantasai: numeric only works<br>
<jarhar> lwarlow: yeah<br>
<jarhar> lwarlow: ? to normal<br>
<lwarlow> +1<br>
<jarhar> astearns: we have a proposed bikeshedding resolution: inteprolate size which takes ? or keywords as values<br>
<fantasai> astearns: Any concerns? Is anyone sad?<br>
<bramus> s/takes ? or keywords/with numeric-only | allow-keywords<br>
<dbaron> RESOLVED: use the name interpolate-size: numeric-only | allow-keywords, as an inherited property<br>
<jarhar> astearns: remove current restriction to have calc size as one of the values?<br>
<jarhar> dbaron: yeah i should have said more about what th eproperty does, but yes the idea is that if you specify this then it iwll allow interpolation between two thing sneither of which is calc size, using calc sie as one of the intermediate ones so you dont have to use calc size it just shows up in your animation<br>
<jarhar> astearns: still an author facing thing?<br>
<jarhar> dbaron: yes but we woudlnt promote it as the mechanism for opting in to these animations. still an author facing thing that you can use for other things like roma but when we talk about using it for animations we will use the property we just made rather than using calc size<br>
<jarhar> kbabbitt: analogous to using ? to animate from a ? to a length for example<br>
<kbabbitt> s/using ?/using calc()/<br>
<jarhar> TabAtkins: ?? but thats much more ?, this is not needed for most cases<br>
<kbabbitt> s/from a ? to a length/from a percentage to a length/<br>
<jarhar> astearns: do we need a second resolution about removing the requirement for calc size?<br>
<jarhar> TabAtkins: there wasn't any such requirement in the spec, we define the rules for how calc size, and this adds an additional rule to that<br>
<jarhar> astearns: anything more on this issue?<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10294#issuecomment-2165268969 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 June 2024 10:35:28 UTC