16:00:34 <RRSAgent> RRSAgent has joined #css
16:00:34 <RRSAgent> logging to https://www.w3.org/2022/08/31-css-irc
16:00:36 <Zakim> RRSAgent, make logs Public
16:00:39 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:00:48 <TabAtkins> Request: the nesting syntax issue (4748) has been sitting for several weeks
16:01:13 <oriol> present+
16:01:35 <bramus> present+
16:02:04 <khush> khush has joined #css
16:02:11 <khush> +present
16:02:17 <GameMaker> present+
16:02:24 <dgrogan> dgrogan has joined #css
16:02:26 <flackr> flackr has joined #css
16:02:40 <bradk> bradk has joined #css
16:02:42 <emilio> present+
16:02:45 <plinss> present+
16:02:47 <Rossen_> present+
16:02:49 <flackr> present+
16:02:53 <dgrogan> present+
16:02:53 <bradk> present+
16:03:16 <vmpstr> vmpstr has joined #css
16:03:30 <TabAtkins> ScribeNick: TabAtkins
16:03:36 <dlibby> dlibby has joined #css
16:03:38 <fantasai> present+
16:03:50 <vmpstr> present+
16:04:06 <dlibby> present+
16:04:23 <miriam> present+
16:04:51 <masonf> masonf has joined #css
16:04:56 <masonf> present+
16:06:22 <alisonmaher> alisonmaher has joined #css
16:06:22 <bradk> Didn’t realize my speaker was off earlier😝
16:06:28 <alisonmaher> present+
16:06:35 <astearns> 2,1,3,4,x,y,7,5,6
16:07:05 <dbaron> Present+
16:07:11 <TabAtkins> Topic: specifying timeline phases in WAAPI
16:07:13 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7589
16:07:32 <TabAtkins> flackr: We've resolved on a CSS syntax for timeline phases, where you can tie an animation to a phase
16:07:41 <TabAtkins> flackr: But we didn't talk about how this would work in waapi
16:07:53 <TabAtkins> flackr: So, how do you make a WEb Animation that animates in a particular timeline phase?
16:08:11 <TabAtkins> flackr: Main two proposals are (1) extend .delay and .endDelay properties, which map to equivalent css properties
16:08:26 <TabAtkins> flackr: These accept doubles currenty, would need to bea ble to take something expressing a phase+proportion
16:08:35 <TabAtkins> flackr: Advantage of option 1 is it's easy to udnerstand
16:08:48 <TabAtkins> flackr: Option 2 is more in line with the desire to use typed properties in these JS bindings
16:08:56 <TabAtkins> flackr: so we don't ahve to parse strings all the time
16:09:01 <TabAtkins> flackr: I think Brian is on board with either
16:09:03 <Rossen_> q?
16:09:53 <Sebo> Sebo has joined #css
16:10:06 <TabAtkins> flackr: I have a slight preference for option 2, as it's more future-proof. Requires some wrapper around the fields, and there's a naming question
16:10:36 <TabAtkins> TabAtkins: I'm fine with option 2, with details tbd by editors
16:10:51 <TabAtkins> Rossen_: reading thru comments, Brian seems to supportive as well
16:11:01 <TabAtkins> flackr: yeah, he doesn't seem worried about the string complexity, but had no objections to option 2
16:11:10 <chrishtr> present+
16:11:12 <TabAtkins> Rossen_: so current proposal is option 2
16:11:30 <TabAtkins> Rossen_: Not hearing much other opinions
16:11:35 <TabAtkins> Rossen_: so suggest resolving on the direction
16:11:47 <bramus> SGTM
16:11:53 <TabAtkins> Rossen_: complaints, objections?
16:12:12 <TabAtkins> RESOLVED: Go with option 2 (object/Typed OM value to specify the phase+offset), details tbd by editors
16:12:25 <TabAtkins> Topic: API for phase-linked offsets in keyframes
16:12:27 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7637
16:12:47 <TabAtkins> flackr: Related to previous, we also resolved in CSS that you could link keyframes to timeline phases
16:12:52 <TabAtkins> flackr: But again we didn't have a JS way to do it
16:13:10 <TabAtkins> flackr: So the issue suggests that we reuse the previous resolution's format for specifying keyframe offsets
16:13:13 <TabAtkins> +1
16:13:51 <TabAtkins> flackr: So represetning a keyframe position as phase+offset
16:14:19 <TabAtkins> Rossen_: objections?
16:14:29 <bramus> +1
16:14:40 <Sebo> +1
16:14:55 <TabAtkins> flackr: Summarized: support passing a phase+offset object in the keyframe offsets
16:15:18 <TabAtkins> RESOLVED: Use same object as in 7589 to specify keyframe offsets as well
16:15:37 <TabAtkins> Topic: Scoping keyframe names in UA stylesheet
16:15:38 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7560
16:15:59 <smfr> smfr has joined #css
16:16:26 <TabAtkins> khush: Came up in impl for Shared Element Transitions, where the browser is making keyframes and using in the UA stylesheet
16:16:38 <TabAtkins> khush: Per spec right now, those @keyframes names can collide with author keyframes
16:16:42 <TabAtkins> khush: Issue has two proposals
16:17:11 <TabAtkins> khush: First is implicitly carrying source information around, so a UA 'animation-name' rule will look in the UA sheet first for keyframes
16:17:32 <TabAtkins> khush: Main issue with this is there's a bunch of script APIs which provide the keyframe name, and it becomes difficult for authors to tell which @keyframes is being referred to
16:17:48 <TabAtkins> khush: Alternate is making a syntax for keyframes names that can only be used in the UA stylesheet
16:18:00 <TabAtkins> khush: Tab's suggestion was `@keyframes ua(foo) {...}`
16:18:10 <flackr> q+
16:18:19 <TabAtkins> khush: Could be implicit or explicit, but would be `animation-name: ua(foo)`
16:18:24 <emilio> q+
16:18:36 <TabAtkins> khush: Also an issue if author stylesheets are allowed to explicitly use the value. Prefer not, it gives us more flexibility to change.
16:18:45 <TabAtkins> khush: I suggest we take TAb's suggestion of a ua() function
16:18:53 <Rossen_> q?
16:18:57 <Rossen_> ack fantasai
16:19:04 <fantasai> ua(name-of-animation)
16:19:10 <fantasai> -name-of-animation
16:19:20 <fantasai> -ua-name-of-animation
16:19:26 <TabAtkins> fantasai: Tab has several proposals. One is a function, another is a single-dash prefix, which isn't generally used, or specifically a `-ua-` prefix.
16:19:31 <TabAtkins> fantasai: Just wanted to point out several options.
16:19:39 <fantasai> s/options/options in the issue/
16:19:48 <TabAtkins> khush: I think single-dash can be used in an author stylesheet, so there's some compat risk.
16:20:06 <TabAtkins> flackr: The author stylesheets might refer to these for SET, right?
16:20:20 <fantasai> SET=Shared Element Transitions
16:20:32 <TabAtkins> flackr: My issue with scoping to the stylesheet (not allowing usage in author stylesheets) is authors might want to specify overrides for the proeprties that still use SET animation names
16:20:34 <Rossen_> ack flackr
16:20:37 <tantek> tantek has joined #css
16:20:46 <TabAtkins> khush: This can be done without overriding animation-name, by setting the longhang properties specifically.
16:21:06 <TabAtkins> khush: Just not a fan of allowing using it in a different context from where it's intended
16:21:17 <TabAtkins> flackr: That does prevent author from using the shorthand, tho
16:21:19 <TabAtkins> khush: yeah
16:21:30 <TabAtkins> flackr: So I have a slight preference for just using a naming convention, not putting a usage restriction
16:21:34 <Rossen_> ack emilio
16:21:48 <TabAtkins> emilio: I don't know if SET - it seems we want to expose the animatino to authors in some way
16:21:55 <tantek> present+
16:22:00 <TabAtkins> emilio: We have other at-rules in the UA sheet that we don't expose tho, like a @font-face
16:22:06 <TabAtkins> emilio: We just don't expose that in scripting APIs
16:22:21 <TabAtkins> emilio: Is that an option?
16:22:31 <bradk> bradk has joined #css
16:22:36 <TabAtkins> emilio: Otherwise I tend to lean to just using a naming convention.
16:22:45 <Rossen_> q?
16:22:46 <TabAtkins> emilio: There are use-cases for overriding animation names in user stylesheets, for example
16:23:20 <fantasai> TabAtkins: When you don't expose the name in scripting APIs, the name is still exposed in properties?
16:23:31 <fantasai> TabAtkins: If the author defines something of the same name, it would take precedence, right?
16:23:41 <fantasai> emilio: We chose -moz- prefixed things, since supposed to be internal implementation detail
16:23:54 <fantasai> emilio: naming convention, especially if we use -ua-, would allow user to override internal if they wanted
16:24:06 <fantasai> emilio: so that's what I meant, there may be a use case for users to adjust animations
16:25:01 <TabAtkins> fantasai: I think a naming convention is nice. Can decide if we want it to expose to the author or not for tweaking, but it allows that possibility. Seems usable/used in other places where we've run into similar problems.
16:25:12 <TabAtkins> khush: So is there a preference for one of the naming conventions?
16:25:33 <TabAtkins> fantasai: If it's author-exposed, I think -ua-foo is clear and fits into the syntaxes we might use it pretty easily.
16:25:45 <fantasai> s/easily/easily anywhere we need such a thing/
16:25:47 <TabAtkins> emilio: Agreed. No new syntax and it's reusable for other features.
16:25:50 <bradk> +1 for -ua- for reasons already mentioned
16:26:11 <TabAtkins> Rossen_: So sounds like a -ua- prefix is getting the most likes
16:26:21 <TabAtkins> Rossen_: Can we resolve?
16:26:57 <TabAtkins> khush: So consensus on -ua- prefix for UA-defined keyframes rules.
16:27:14 <TabAtkins> khush: And a second question about whether this can be used in author stylesheets or not, I'm not clear if there's objections on that yet.
16:27:23 <TabAtkins> Rossen_: So let's take those separately.
16:27:31 <TabAtkins> Rossen_: First, the prefix naming. Any objections to -ua- prefix?
16:27:52 <TabAtkins> RESOLVED: Name UA-defined @keyframes rules with a -ua- prefix (and presumably use this pattern elsewhere as needed)
16:28:08 <TabAtkins> Rossen_: Second, expose them to be usable in author stylesheets?
16:28:15 <TabAtkins> No opinion here
16:28:34 <TabAtkins> RESOLVED: The -ua- names *are* usable in author/user stylesheets.
16:28:42 <bradk> Hopefully auto prefixers will not start adding-ua- to everything.
16:28:59 <TabAtkins> Topic: Make animation shorthand syntax future-proof
16:29:04 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6946
16:30:06 <TabAtkins> Topic: Nesting syntax
16:30:08 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/4748
16:30:08 <fantasai> ScribeNick: fantasai
16:30:10 <dholbert> dholbert has joined #css
16:30:32 <fantasai> TabAtkins: Some time ago we had a discussion about what style of nesting syntax should use
16:31:08 <fantasai> TabAtkins: major options are what I drafted, nesting selector directly with an &
16:31:17 <fantasai> TabAtkins: or use @nest if needed
16:31:23 <fantasai> TabAtkins: option 2 is @nest always
16:31:32 <fantasai> TabAtkins: and option 3 is using brackets to wrap nested rules, never use @nest
16:31:49 <fantasai> TabAtkins: At the time we did a straw poll, and WG resolved on using brackets
16:31:59 <fantasai> TabAtkins: I was unhappy with this and we resolved to take it back for more data collection or arguments
16:32:10 <fantasai> TabAtkins: Adam Argyle ran a poll with significant response numbers about this
16:32:14 <TabAtkins> https://developer.chrome.com/blog/help-css-nesting/
16:32:27 <TabAtkins> https://github.com/w3c/csswg-drafts/issues/4748#issuecomment-1211280306
16:32:28 <fantasai> TabAtkins: Linked article, I think was written fairly
16:32:41 <fantasai> TabAtkins: It seems responses are incredibly one-sided
16:32:51 <fantasai> TabAtkins: Using & or @nest directly
16:32:57 <fantasai> TabAtkins: This is what's in the current spec and what I prefer
16:33:03 <fantasai> TabAtkins: This was an overwhelming response in favor of one option
16:33:12 <fantasai> TabAtkins: So suggestion is to revert previous resolution and keep syntax in current spec
16:33:13 <astearns> option 1 also allows you to write as if @nest is always required
16:33:25 <Rossen_> ack fantasai
16:33:32 <miriam> q+
16:33:58 <TabAtkins> fantasai: The problem I noticed reading thru the thread is the bracketed syntax was represented as always putting in the ampersand, while the point of bracketed syntax was to avoid needing it
16:34:06 <TabAtkins> fantasai: So I dont' think that's true that it was fairly written
16:34:38 <TabAtkins> TabAtkins: I didn't take that as part of the syntax at all, still needed the & to be the nesting selector
16:34:58 <TabAtkins> fantasai: The point was that it was mostly never needed, so I think the poll wasn't valid
16:35:13 <TabAtkins> miriam: I reviewed the article and helped come up with the syntax, so...
16:35:19 <Rossen_> ack miriam
16:35:24 <TabAtkins> miriam: I didn't think of removing the & as the main advantage of the brackets
16:35:40 <TabAtkins> miriam: As I was writing it I foudn the brackets more confusing than expected, and I actually *added* ampersands for clarity
16:35:50 <TabAtkins> miriam: AFter writing the demos I actually changed my mind away from bracketing
16:36:15 <TabAtkins> fantasai: I'm not going to block, if y'all liek this syntax better that's fine. I just don't like having an inconsistent syntax.
16:36:26 <TabAtkins> fantasai: I just don't think it's fair to say it was overwhelmingingly in one direction
16:37:08 <TabAtkins> Rossen_: So it sounds like we have a pretty strong response. Possibly biased, but Mia makes an argument for it not being so.
16:37:15 <fantasai> I really don't like the inconsistency, where you have to know when to use @nest
16:37:24 <Rossen_> q?
16:37:27 <TabAtkins> Rossen_: So proposed resolution is to undo the resolutions from november and leave the spec as it currentyl is
16:37:32 <TabAtkins> Rossen_: Any additional comments or feedback?
16:38:02 <TabAtkins> fantasai: I'm not gonna object because everyone seems to like it, but I really don't like that authors have to know when to use @nest, it's not a consistent syntax
16:38:11 <TabAtkins> fantasai: And I wish we had something else besides an inconsistent syntax
16:38:28 <TabAtkins> fantasai: I don't like @nest everywhere since it's verbose, but...
16:38:38 <TabAtkins> miriam: I agree on the problem and it's why I liked bracket before. I agree it's an issue and it's weird
16:38:54 <TabAtkins> miriam: But once I started writing examples, it almost all basic use-cases you just use the & and it works and looks cleaner.
16:39:08 <TabAtkins> miriam: and there are only rare cases where you need to use @nest and it's not as hard as I initially thought to know the difference
16:39:16 <TabAtkins> miriam: So that's why I changed my mind even tho I agree it's inconsistent
16:39:22 <bradk> +1 to miriam
16:39:56 <TabAtkins> plinss: I think elika has a valid point and before we decide on this we could make another design phase to try to come up with another route.
16:40:05 <fantasai> I'm not so opposed to the & , just that some rules require @nest and others dont'
16:40:12 <TabAtkins> plinss: I'm okay with undoing the previous resolution, just not sure we shoudl resolve affirmatively on the current syntax
16:40:37 <TabAtkins> Rossen_: Right, so let's just resolve on undoing the previous resolution.
16:40:59 <TabAtkins> Rossen_: Objections?
16:42:22 <TabAtkins> RESOLVED: Revert the previous resolution from Nov 2021 mandating bracket-nesting syntax, and the WG preference for a single nesting syntax.
16:42:46 <TabAtkins> Rossen_: And for the record, want to strongy encourage continued improvement of the design.
16:43:23 <TabAtkins> Topic: Make aniamtion shorthand syntax future-proof
16:43:33 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6946
16:43:59 <TabAtkins> seb: We have an issue with new animation-* properties, that animation-name makes problems in the shorthand
16:44:13 <TabAtkins> seb: You can't distinguish animation names from the keywords from the other properties
16:44:40 <TabAtkins> seb: So how do we make it so that new properties, like animation-composition, can make it into the shorthand?
16:45:29 <TabAtkins> seb: One way would be to create a new optional syntax that separates the name from the rest with a slash, or something
16:45:39 <flackr> q+
16:45:44 <TabAtkins> seb: This would be optional, we couldn't enforce it on current property values
16:46:07 <TabAtkins> seb: This would hopefully be a gradual replacement, like with the color function syntaxes.
16:46:16 <TabAtkins> q+
16:46:21 <astearns> ack flackr
16:46:55 <TabAtkins> flackr: I think another possibility is that, for new properties, they will only be used if they are unambiguously not the animation name (youv'e specified another property before them)
16:47:10 <TabAtkins> seb: So making the order more fixed?
16:47:26 <TabAtkins> flackr: Until an animatino-name is specified, assume that all keywords are from the current set, not the new set
16:47:32 <astearns> ack TabAtkins
16:47:46 <fantasai> TabAtkins: So we take the current set of keywords allowed in animation shorthand right now
16:47:53 <fantasai> TabAtkins: and until you see any keyword other than those, we only parse those as keywords
16:48:05 <fantasai> TabAtkins: anything else, including keywords from additional properties, assumed to be an animation name
16:48:16 <fantasai> TabAtkins: and as soon as we see an animation name, we start parsing the rest as other properties
16:48:27 <fantasai> TabAtkins: [gives example]
16:48:31 <fantasai> flackr: Correct
16:48:38 <dlibby_> dlibby_ has joined #css
16:48:50 <TabAtkins> seb: Dunno if websites are already using animation names with the current keywords
16:49:04 <fantasai> Sebo: If authors are using these keywords now what happens?
16:49:20 <fantasai> TabAtkins: [missed]
16:49:23 <TabAtkins> flackr: ONe complication - with animation-timeline we've added another arbitrary name to the shorthand, potentially
16:49:33 <TabAtkins> flackr: So we might want a way to future-proof these other properties with arbitrary names
16:49:50 <fantasai> TabAtkins: for future arbitrary-name ones, we might need to add them with a prefix like "phase"
16:50:00 <fantasai> TabAtkins: but still have to handle animation-name today
16:50:26 <fantasai> TabAtkins: My suggestion was that I do actually like the slash syntax, assuming address future things in a specific ways
16:50:38 <fantasai> TabAtkins: I like animation-name being able to specify with a slash so unambiguous where it is
16:50:42 <astearns> ack dbaron
16:50:52 <TabAtkins> dbaron: Stricter alternative of what flackr suggested
16:50:56 <TabAtkins> dbaron: Maybe easier to explain
16:51:09 <TabAtkins> dbaron: We only extend the shorthand if animation-name is first
16:51:18 <TabAtkins> dbaron: So rather than having "these have to be after the name, these dont'"
16:51:28 <TabAtkins> dbaron: Maybe the stricter rule of animation-name is first, and then you can use the new stuff
16:51:29 <flackr> +1 sgtm
16:51:49 <TabAtkins> astearns: Does the current shorthand have position restrictions?
16:51:51 <TabAtkins> TabAtkins: No
16:52:05 <TabAtkins> dbaron: I think Tab's explanation isn't quite what it is, but my memory is pretty old now
16:52:38 <TabAtkins> astearns: So if someone today is using a composition shorthand as the animation name, and it's put last, would this change make that declaration invalid?
16:52:42 <Sebo> Just for reference, here's the syntax: https://drafts.csswg.org/css-animations/#typedef-single-animation
16:53:29 <TabAtkins> fantasai: The canonical order puts the name last, so there's probably author sheets doing that today, and also script-generated values
16:53:35 <TabAtkins> fantasai: I think we'll have to fork the syntax in some way
16:53:40 <TabAtkins> fantasai: Need more brainstorming
16:54:03 <astearns> s/using a composition shorthand/using animation-composition/
16:54:03 <TabAtkins> fantasai: And we'll need to accommodate more custom idents too, as flackr mentioned
16:54:29 <astearns> ack fantasai
16:54:36 <dbaron> Just one example of how things work today: `animation: ease-in ease-out` is an animation where ease-in is the timing function and ease-out is the animation-name.
16:55:02 <TabAtkins> fantasai: For now, we can treat animatino-composition as a reset-only property, so it's reset by the 'animation' but can't be set in there
16:55:11 <TabAtkins> fantasai: That'll work to unblock while we solve the issue.
16:55:13 <TabAtkins> +1
16:55:44 <TabAtkins> Right, the non-name proeprties get first dibs on keywords, and animation-name takes the first unclaimed one
16:56:02 <TabAtkins> seb: So I heard two suggestions - a slash, or putting the name first and other keywords afterward
16:56:15 <TabAtkins> astearns: Possibly `name foo` instead of slash too
16:56:23 <TabAtkins> fantasai: I think we need to explore the syntax space, but not on the call
16:56:42 <TabAtkins> fantasai: We haven't yet used these kind of keyword indicators in property syntax, only in functions, so this'll be a first time.
16:56:56 <TabAtkins> I'm currently future-proofing a toggle proeprty by doing a keyword prefix, actually
16:57:21 <TabAtkins> astearns: So suggestion is we mark animation-composition as a reset-only sub-property for now, and work on a syntax allowing it to be set
16:57:34 <TabAtkins> fantasai: All longhands not in Animations 1 treated as reset-only for now
16:57:42 <Sebo> +1
16:58:17 <TabAtkins> RESOLVED: All animation longhands not defined in Animations 1 are defined as reset-only sub-properties, while we work on how to make them specifiable without ambiguity.
16:58:21 <TabAtkins> Topic: end
16:58:35 <TabAtkins> astearns: Please register your timeslots for tpac
16:58:48 <TabAtkins> astearns: And do the ArriveCan stuff if you're not canadian, it needs to be done ahead of time
17:02:45 <Rossen_> Zakim, end meeting
17:02:45 <Zakim> As of this point the attendees have been oriol, bramus, present, GameMaker, emilio, plinss, Rossen_, flackr, dgrogan, bradk, fantasai, vmpstr, dlibby, miriam, masonf, alisonmaher,
17:02:48 <Zakim> ... dbaron, chrishtr, tantek
17:02:48 <Zakim> RRSAgent, please draft minutes v2
17:02:48 <RRSAgent> I have made the request to generate https://www.w3.org/2022/08/31-css-minutes.html Zakim
17:02:50 <Zakim> I am happy to have been of service, Rossen_; please remember to excuse RRSAgent.  Goodbye
17:02:54 <Zakim> Zakim has left #css
17:17:11 <GameMaker> GameMaker has joined #css
17:35:03 <dholbert> dholbert has joined #css