- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 21 Jul 2023 18:04:45 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-animations-2] Make animation shorthand syntax future-proof`, and agreed to the following: * `RESOLVED: Add a new syntax for the animation shorthand where the animation-name comes first, followed by a slash, so that the new syntax (but not the old one) can accept animation-timeline and animation-composition in the shorthand. Work out further details in issue.` <details><summary>The full IRC log of that discussion</summary> <dbaron> SebastianZ: There are multiple additions -- new longhands -- to animation. Starting to collide because data types are the same.<br> <dbaron> ... I was proposing to have a new syntax that avoids collisions.<br> <dbaron> ... collisions between those additions.<br> <dbaron> ... I had different proposals on how to solve that.<br> <dbaron> ... I think we already had a resolution to reset new properties that are added but if we want to add new ones to the shorthand we should discuss how to do that.<br> <dbaron> ... One proposal by me was to animation-name animation-timeline are colliding now.<br> <dbaron> flackr: Is there a proposal/<br> <dbaron> SebastianZ: Proposal is to change syntax or use a new syntax that avoids issues with additions to the shorthand.<br> <dbaron> ... so if we want to include animation-timeline in the shorthand, we have to find a way to do it so it doesn't collide with animation-name.<br> <flackr> q+<br> <dbaron> ... I don't remember what other longhand was added, but there was another one that collided with animation-name<br> <dbaron> ... So we have to find a way how to include them without any ambiguities.<br> <dbaron> ... my proposal was to add slashes between them.<br> <ydaniv> animation-range, maybe?<br> <astearns> ack flackr<br> <dbaron> flackr: We already have ambiguity with anything that specifies time values -- they're positional. It's an option but not a great option. Other option that's come up in the past was having functional notation like timeline(timeline-name), which I think makes it clearer what's going on.<br> <fremy> +1 to what flackr said<br> <TabAtkins> my earlier proposal was `animation-name / <all other stuff>`<br> <TabAtkins> and if you didn' thave the slash it reset all the new properties<br> <dbaron> astearns: Something we could do in general for shorthands that could have ambiguities is to decide whether we go with slashes or with bracketed named sections of the shortand value.<br> <dbaron> SebastianZ: ideally we'd find a solution that's broader than just the animation shorthand<br> <dbaron> SebastianZ: It could be something other than slashes like functions or something else.<br> <TabAtkins> q+<br> <astearns> ack dbaron<br> <TabAtkins> dbaron: two things<br> <TabAtkins> dbaron: generally pretty positive about functions<br> <TabAtkins> dbaron: also, one reason we ahve difficult here is animation-name property accepts arbitrary custom-idents, not --prefixed<br> <TabAtkins> dbaron: which we now decide is a bad practice<br> <TabAtkins> dbaron: if we followed current best practices we'd have required keyframes to establish --prefix names<br> <TabAtkins> SebastianZ: even with dashes there is collision with timeline names<br> <dbaron> SebastianZ: even with -- there would be collisions between name and timeline both having dashes<br> <dbaron> TabAtkins: Other mistake with animation -- custom idents should be positionally unambiguous. Custom ident should have been required to be first in the shorthand.<br> <dbaron> TabAtkins: It's usually what authors write anyway. That we have to serialize the animation name last for these weird parsing reasons looks weird.<br> <astearns> ack TabAtkins<br> <dbaron> TabAtkins: That's why my suggestion was ...<br> <TabAtkins> that's why my suggestion was for "name / other stuff", that way the name comes first, where it belongs<br> <fantasai> +1 that seems nice<br> <ydaniv> +1<br> <flackr> +1 name / other stuff seems good to unblock adding things<br> <dbaron> astearns: what will we do for adding animation-timeline to the shorthand?<br> <dbaron> TabAtkins: we need to decide on one of the ways<br> <dbaron> SebastianZ: proposals were (1) adding slashes (2) positional stuff or (3) adding functions<br> <dbaron> astearns: given we're already in a bad situation with animation-name that can be anywhere I think we're limited to functional<br> <fantasai> strongly in favor of 1)<br> <dbaron> TabAtkins: no,... we could have a grammar fork. If you do name/stuff you can write a timeline name, otherwise you can't express timeline name in the shorthand. So allof them are compatible.<br> <fremy> slash is very unclear<br> <fantasai> positional is hard<br> <dbaron> s/allof/all of/<br> <fantasai> and really dislike introducing functional notations for a shorthand, we don't do that anywhere else<br> <TabAtkins> we use / for positional separation in several properties<br> <TabAtkins> like it's not *great* but<br> <dbaron> fantasai: I think hard to remember order required for positional things. We generally try to allow reordering.<br> <fremy> q+<br> <dbaron> ... using functional notation just to work around a shorthand thing, we don't do anywhere. Not pleasant to type. We use slashes in a bunch of places for syntactic ambiguity.<br> <flackr> q+<br> <dbaron> ... It's not amazing working with syntax in that way... we have to serialize the older things as older things for compat, but you can express any past/future possibilites as input using the new less confusing syntax.<br> <dbaron> fremy: I want to disagree that we never use functions for that. We do quite often. We have counter() that takes a name. If you want to ??? you can use a counter() function.<br> <dbaron> fantasai: counter() functions are different, you're processing the counter name and returning the result. It's actually a function, not something to disambiguate.<br> <astearns> ack fremy<br> <dbaron> fantasai: ... tagging values with function names is not a CSS pattern.<br> <astearns> ack flackr<br> <dbaron> flackr: I'm good with / being used to remove challenges with animation-name. But this only allows us to add one name before we can add positional stuff again.<br> <fremy> https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Functions#animation_functions<br> <dbaron> flackr: We'll have the problem that the first dashed-ident after the slash is the timeline name, and the next thing that needs a name will be the second one.<br> <TabAtkins> this is true, yeah<br> <dbaron> SebastianZ: I think there was another longhand discussed to add to the shorthand as well... I think we're already in that situation.<br> <TabAtkins> we could *also* use the "keyword prefix" approach for the timeline name<br> <Rossen_> q?<br> <dbaron> ... for 'animation'. I think animation-composition.<br> <TabAtkins> so you'd say `timeline <name>` in the shorthand<br> <TabAtkins> then that's extendable for the future<br> <dbaron> TabAtkins: If we want to future proof against adding more names, we could use a keyword prefix rather than a function wrapper. I think we have used this before. `timeline <name>`. That extends into the future.<br> <dbaron> TabAtkins: that extends into the future. We could add more names in the future with similar prefixes.<br> <dbaron> TabAtkins: We still have to solve the animation-name thing separately.<br> <fremy> q+<br> <dbaron> flackr: I wasn't specific that it should be functions, keyword prefixes are great too.<br> <SebastianZ> q+<br> <dbaron> astearns: timeline <name> without the slash means you could put the animation-name anywhere you wanted<br> <fantasai> dbaron: unless the animation-name is timeline<br> <dbaron> TabAtkins: The current prefix tagging is inside functional syntaxes, not in a toplevel property value.<br> <fantasai> fantasai: The current keyword tagging is only in function syntaxes, haven't used in property values so far<br> <astearns> ack fremy<br> <dbaron> fremy: I'm still reading the timeline thing ... the timeline property already accepts scroll() and view() functions.<br> <dbaron> fremy: Can we not fixed that one? animation-timeline takes a timeline() function and then you don't nee a timeline prefix because the animation-timeline property takes a function all the time.<br> <dbaron> fremy: not sure if this is already shipped<br> <dbaron> flackr: would be hard to change existing animation-timeline property to requre that, but could make it always show up that way in the shorthand<br> <dbaron> fantasai: But do you then put timeline(scroll(...)) in the shorthand?<br> <dbaron> flackr: I don't think so.<br> <dbaron> fantasai: It seems like the logical conclusion but it's really awful.<br> <dbaron> flackr: The idea that if you specify a name in the animation-timeline, it's implicitly timeline(<name>), the other values are just scroll() and view() functions.<br> <dbaron> astearns: You could put a name in the longhand, but if you want to specify it in the shorthand you'd need to wrap in a function -- that discontinuity is not great.<br> <astearns> ack SebastianZ<br> <dbaron> SebastianZ: I agree with fantasai that this would be something new.<br> <dbaron> ... we do have the scroll() and view() function but they just refer to something.<br> <dbaron> ... we still have the timeline name they are referring to.<br> <fantasai> note that the functional keyword disambiguator pattern tends to use prepositions so it'd be something like "on <timeline>" if we follow that pattern<br> <dbaron> ... Introducing a function that directly reflects the property would be something new to CSS.<br> <dbaron> SebastianZ: On the other hand, regarding / syntax, we are already saying this could lead to issues. I was just thinking about that again.<br> <dbaron> ... what if you want to set one of these longhand properties but not the other ones?<br> <dbaron> ... that would be a bit hard with the slashes<br> <dbaron> fantasai: what?<br> <dbaron> SebastianZ: the animation-composition is the other issue we have<br> <dbaron> SebastianZ: If you want to set animation-composition but not the animation-timeline<br> <dbaron> [some confusion]<br> <flackr> animation: foo / add; would be valid<br> <dbaron> fantasai: Going forward the new syntax would require the animation name first, and have to follow it with a slash, and then after that there's no animation-name so there's no name clashes.<br> <dbaron> fantasai: We just need to avoid conflicts between the keywords going forward.<br> <dbaron> fantasai: We try to minimize positional-ness within a shorthand.<br> <dbaron> fantasai: positional relationships are hard to remember<br> <dbaron> fantasai: going forward, put an effort into choosing kewyords that don't clash, then we don't run into ambiguity.<br> <dbaron> SebastianZ: animation-timeline only allows dashed idents?<br> <dbaron> fantasai: dashed idets and none?<br> <dbaron> fremy: and auto<br> <dbaron> SebastianZ: there could still be clashes between new keywords that get added?<br> <fantasai> TabAtkins: but that's the initial value<br> <dbaron> SebastianZ: so if we have a new animation-timleine keyword, and have animation-composition as well.<br> <fremy> `auto` is going to be very popular...<br> <dbaron> fantasai: We can try to avoid clashes. Making everyhing positional all the time, or wrapping everything in functions, is not friendly to authors.<br> <dbaron> astearns: I think we need to wrap up.<br> <dbaron> astearns: can we resolve on: allow animation-timeline into the shorthand by adding a / after the animation-name<br> <flackr> q+<br> <dbaron> astearns: if people aren't happy with that today, we could hash out more in the issues<br> <dbaron> SebastianZ: animation-timeline plus animation-composition<br> <dbaron> fantasai: yeah, all the new stuff<br> <dbaron> flackr: animation-timeline takes an auto value, conflicts with duration<br> <dbaron> flackr: It's already the case that we have some overlapping values and we choose them positionally.<br> <dbaron> flackr: auto is going to be ambiguous with duration<br> <astearns> ack dbaron<br> <dbaron> fantasai: Could say you can't specify auto in the shorthand, and if you ??/ drop it<br> <flackr> ack flackr<br> <fantasai> dbaron: other thing we do, but it's slightly more complicated in parsing<br> <fantasai> dbaron: you can buffer having an auto value<br> <fantasai> dbaron: see an auto value, say it can be a value for either of these two properties and keep looking<br> <fantasai> dbaron: assign auto for the one that isn't assigned<br> <fantasai> dbaron: by another keyword<br> <fantasai> dbaron: it's done in other places<br> <TabAtkins> list-style is the example we do today<br> <fantasai> dbaron: a little bit of a pain for implementers, but not too hard<br> <fantasai> dbaron: and is friendly to authors<br> <dbaron> (ntim asked about list style)<br> <dbaron> astearns: Can we add / to shorthand to accomodate new longhands ,and then hammer out details for things we discovered today?<br> <fantasai> sgtm<br> <dbaron> flackr: sounds good to me<br> <dbaron> RESOLVED: Add a new syntax for the animation shorthand where the animation-name comes first, followed by a slash, so that the new syntax (but not the old one) can accept animation-timeline and animation-composition in the shorthand. Work out further details in issue.<br> <myles> ScribeNick: myles<br> <fantasai> also +1 to dbaron's solution to 'auto'<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6946#issuecomment-1646065211 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 21 July 2023 18:04:47 UTC