– DRAFT –
Cascading Style Sheets (CSS) Working Group Teleconference

Request: the nesting syntax issue (4748) has been sitting for several weeks

<khush> +present

<bradk> Didn’t realize my speaker was off earlier😝

<astearns> 2,1,3,4,x,y,7,5,6

specifying timeline phases in WAAPI

github: https://github.com/w3c/csswg-drafts/issues/7589

flackr: We've resolved on a CSS syntax for timeline phases, where you can tie an animation to a phase

flackr: But we didn't talk about how this would work in waapi

flackr: So, how do you make a WEb Animation that animates in a particular timeline phase?

flackr: Main two proposals are (1) extend .delay and .endDelay properties, which map to equivalent css properties

flackr: These accept doubles currenty, would need to bea ble to take something expressing a phase+proportion

flackr: Advantage of option 1 is it's easy to udnerstand

flackr: Option 2 is more in line with the desire to use typed properties in these JS bindings

flackr: so we don't ahve to parse strings all the time

flackr: I think Brian is on board with either

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

TabAtkins: I'm fine with option 2, with details tbd by editors

Rossen_: reading thru comments, Brian seems to supportive as well

flackr: yeah, he doesn't seem worried about the string complexity, but had no objections to option 2

Rossen_: so current proposal is option 2

Rossen_: Not hearing much other opinions

Rossen_: so suggest resolving on the direction

<bramus> SGTM

Rossen_: complaints, objections?

RESOLUTION: Go with option 2 (object/Typed OM value to specify the phase+offset), details tbd by editors

API for phase-linked offsets in keyframes

github: https://github.com/w3c/csswg-drafts/issues/7637

flackr: Related to previous, we also resolved in CSS that you could link keyframes to timeline phases

flackr: But again we didn't have a JS way to do it

flackr: So the issue suggests that we reuse the previous resolution's format for specifying keyframe offsets

+1

flackr: So represetning a keyframe position as phase+offset

Rossen_: objections?

<bramus> +1

<Sebo> +1

flackr: Summarized: support passing a phase+offset object in the keyframe offsets

RESOLUTION: Use same object as in 7589 to specify keyframe offsets as well

Scoping keyframe names in UA stylesheet

github: https://github.com/w3c/csswg-drafts/issues/7560

khush: Came up in impl for Shared Element Transitions, where the browser is making keyframes and using in the UA stylesheet

khush: Per spec right now, those @keyframes names can collide with author keyframes

khush: Issue has two proposals

khush: First is implicitly carrying source information around, so a UA 'animation-name' rule will look in the UA sheet first for keyframes

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

khush: Alternate is making a syntax for keyframes names that can only be used in the UA stylesheet

khush: Tab's suggestion was `@keyframes ua(foo) {...}`

khush: Could be implicit or explicit, but would be `animation-name: ua(foo)`

khush: Also an issue if author stylesheets are allowed to explicitly use the value. Prefer not, it gives us more flexibility to change.

khush: I suggest we take TAb's suggestion of a ua() function

<fantasai> ua(name-of-animation)

<fantasai> -name-of-animation

<fantasai> -ua-name-of-animation

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.

fantasai: Just wanted to point out several options in the issue.

khush: I think single-dash can be used in an author stylesheet, so there's some compat risk.

flackr: The author stylesheets might refer to these for SET, right?

<fantasai> SET=Shared Element Transitions

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

khush: This can be done without overriding animation-name, by setting the longhang properties specifically.

khush: Just not a fan of allowing using it in a different context from where it's intended

flackr: That does prevent author from using the shorthand, tho

khush: yeah

flackr: So I have a slight preference for just using a naming convention, not putting a usage restriction

emilio: I don't know if SET - it seems we want to expose the animatino to authors in some way

emilio: We have other at-rules in the UA sheet that we don't expose tho, like a @font-face

emilio: We just don't expose that in scripting APIs

emilio: Is that an option?

emilio: Otherwise I tend to lean to just using a naming convention.

emilio: There are use-cases for overriding animation names in user stylesheets, for example

<fantasai> TabAtkins: When you don't expose the name in scripting APIs, the name is still exposed in properties?

<fantasai> TabAtkins: If the author defines something of the same name, it would take precedence, right?

<fantasai> emilio: We chose -moz- prefixed things, since supposed to be internal implementation detail

<fantasai> emilio: naming convention, especially if we use -ua-, would allow user to override internal if they wanted

<fantasai> emilio: so that's what I meant, there may be a use case for users to adjust animations

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.

khush: So is there a preference for one of the naming conventions?

fantasai: If it's author-exposed, I think -ua-foo is clear and fits into the syntaxes we might use it pretty easily anywhere we need such a thing.

emilio: Agreed. No new syntax and it's reusable for other features.

<bradk> +1 for -ua- for reasons already mentioned

Rossen_: So sounds like a -ua- prefix is getting the most likes

Rossen_: Can we resolve?

khush: So consensus on -ua- prefix for UA-defined keyframes rules.

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.

Rossen_: So let's take those separately.

Rossen_: First, the prefix naming. Any objections to -ua- prefix?

RESOLUTION: Name UA-defined @keyframes rules with a -ua- prefix (and presumably use this pattern elsewhere as needed)

Rossen_: Second, expose them to be usable in author stylesheets?

No opinion here

RESOLUTION: The -ua- names *are* usable in author/user stylesheets.

<bradk> Hopefully auto prefixers will not start adding-ua- to everything.

Make animation shorthand syntax future-proof

github: https://github.com/w3c/csswg-drafts/issues/6946

Nesting syntax

github: https://github.com/w3c/csswg-drafts/issues/4748

TabAtkins: Some time ago we had a discussion about what style of nesting syntax should use

TabAtkins: major options are what I drafted, nesting selector directly with an &

TabAtkins: or use @nest if needed

TabAtkins: option 2 is @nest always

TabAtkins: and option 3 is using brackets to wrap nested rules, never use @nest

TabAtkins: At the time we did a straw poll, and WG resolved on using brackets

TabAtkins: I was unhappy with this and we resolved to take it back for more data collection or arguments

TabAtkins: Adam Argyle ran a poll with significant response numbers about this

<TabAtkins> https://developer.chrome.com/blog/help-css-nesting/

<TabAtkins> https://github.com/w3c/csswg-drafts/issues/4748#issuecomment-1211280306

TabAtkins: Linked article, I think was written fairly

TabAtkins: It seems responses are incredibly one-sided

TabAtkins: Using & or @nest directly

TabAtkins: This is what's in the current spec and what I prefer

TabAtkins: This was an overwhelming response in favor of one option

TabAtkins: So suggestion is to revert previous resolution and keep syntax in current spec

<astearns> option 1 also allows you to write as if @nest is always required

<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

<TabAtkins> fantasai: So I dont' think that's true that it was fairly written

<TabAtkins> TabAtkins: I didn't take that as part of the syntax at all, still needed the & to be the nesting selector

<TabAtkins> fantasai: The point was that it was mostly never needed, so I think the poll wasn't valid

<TabAtkins> miriam: I reviewed the article and helped come up with the syntax, so...

<TabAtkins> miriam: I didn't think of removing the & as the main advantage of the brackets

<TabAtkins> miriam: As I was writing it I foudn the brackets more confusing than expected, and I actually *added* ampersands for clarity

<TabAtkins> miriam: AFter writing the demos I actually changed my mind away from bracketing

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

<TabAtkins> fantasai: I just don't think it's fair to say it was overwhelmingingly in one direction

<TabAtkins> Rossen_: So it sounds like we have a pretty strong response. Possibly biased, but Mia makes an argument for it not being so.

I really don't like the inconsistency, where you have to know when to use @nest

<TabAtkins> Rossen_: So proposed resolution is to undo the resolutions from november and leave the spec as it currentyl is

<TabAtkins> Rossen_: Any additional comments or feedback?

<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

<TabAtkins> fantasai: And I wish we had something else besides an inconsistent syntax

<TabAtkins> fantasai: I don't like @nest everywhere since it's verbose, but...

<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

<TabAtkins> miriam: But once I started writing examples, it almost all basic use-cases you just use the & and it works and looks cleaner.

<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

<TabAtkins> miriam: So that's why I changed my mind even tho I agree it's inconsistent

<bradk> +1 to miriam

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

I'm not so opposed to the & , just that some rules require @nest and others dont'

<TabAtkins> plinss: I'm okay with undoing the previous resolution, just not sure we shoudl resolve affirmatively on the current syntax

<TabAtkins> Rossen_: Right, so let's just resolve on undoing the previous resolution.

<TabAtkins> Rossen_: Objections?

RESOLUTION: Revert the previous resolution from Nov 2021 mandating bracket-nesting syntax, and the WG preference for a single nesting syntax.

<TabAtkins> Rossen_: And for the record, want to strongy encourage continued improvement of the design.

Make aniamtion shorthand syntax future-proof

<TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6946

<TabAtkins> seb: We have an issue with new animation-* properties, that animation-name makes problems in the shorthand

<TabAtkins> seb: You can't distinguish animation names from the keywords from the other properties

<TabAtkins> seb: So how do we make it so that new properties, like animation-composition, can make it into the shorthand?

<TabAtkins> seb: One way would be to create a new optional syntax that separates the name from the rest with a slash, or something

<TabAtkins> seb: This would be optional, we couldn't enforce it on current property values

<TabAtkins> seb: This would hopefully be a gradual replacement, like with the color function syntaxes.

<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)

<TabAtkins> seb: So making the order more fixed?

<TabAtkins> flackr: Until an animatino-name is specified, assume that all keywords are from the current set, not the new set

TabAtkins: So we take the current set of keywords allowed in animation shorthand right now

TabAtkins: and until you see any keyword other than those, we only parse those as keywords

TabAtkins: anything else, including keywords from additional properties, assumed to be an animation name

TabAtkins: and as soon as we see an animation name, we start parsing the rest as other properties

TabAtkins: [gives example]

flackr: Correct

<TabAtkins> seb: Dunno if websites are already using animation names with the current keywords

Sebo: If authors are using these keywords now what happens?

TabAtkins: [missed]

<TabAtkins> flackr: ONe complication - with animation-timeline we've added another arbitrary name to the shorthand, potentially

<TabAtkins> flackr: So we might want a way to future-proof these other properties with arbitrary names

TabAtkins: for future arbitrary-name ones, we might need to add them with a prefix like "phase"

TabAtkins: but still have to handle animation-name today

TabAtkins: My suggestion was that I do actually like the slash syntax, assuming address future things in a specific ways

TabAtkins: I like animation-name being able to specify with a slash so unambiguous where it is

<TabAtkins> dbaron: Stricter alternative of what flackr suggested

<TabAtkins> dbaron: Maybe easier to explain

<TabAtkins> dbaron: We only extend the shorthand if animation-name is first

<TabAtkins> dbaron: So rather than having "these have to be after the name, these dont'"

<TabAtkins> dbaron: Maybe the stricter rule of animation-name is first, and then you can use the new stuff

<flackr> +1 sgtm

<TabAtkins> astearns: Does the current shorthand have position restrictions?

<TabAtkins> TabAtkins: No

<TabAtkins> dbaron: I think Tab's explanation isn't quite what it is, but my memory is pretty old now

<TabAtkins> astearns: So if someone today is using animation-composition as the animation name, and it's put last, would this change make that declaration invalid?

<Sebo> Just for reference, here's the syntax: https://drafts.csswg.org/css-animations/#typedef-single-animation

<TabAtkins> fantasai: The canonical order puts the name last, so there's probably author sheets doing that today, and also script-generated values

<TabAtkins> fantasai: I think we'll have to fork the syntax in some way

<TabAtkins> fantasai: Need more brainstorming

<TabAtkins> fantasai: And we'll need to accommodate more custom idents too, as flackr mentioned

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

<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

<TabAtkins> fantasai: That'll work to unblock while we solve the issue.

<TabAtkins> +1

<TabAtkins> Right, the non-name proeprties get first dibs on keywords, and animation-name takes the first unclaimed one

<TabAtkins> seb: So I heard two suggestions - a slash, or putting the name first and other keywords afterward

<TabAtkins> astearns: Possibly `name foo` instead of slash too

<TabAtkins> fantasai: I think we need to explore the syntax space, but not on the call

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

<TabAtkins> I'm currently future-proofing a toggle proeprty by doing a keyword prefix, actually

<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

<TabAtkins> fantasai: All longhands not in Animations 1 treated as reset-only for now

<Sebo> +1

RESOLUTION: 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.

end

<TabAtkins> astearns: Please register your timeslots for tpac

<TabAtkins> astearns: And do the ArriveCan stuff if you're not canadian, it needs to be done ahead of time