- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 1 Sep 2022 13:03:32 -0400
- To: W3C style mailing list <www-style@w3.org>
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Animations
----------
- RESOLVED: Go with option 2 (object/Typed OM value to specify
the phase+offset), details TBD by editors for
https://github.com/w3c/csswg-drafts/issues/7589
“Specifying Timeline Phases in Web Animations API”
- RESOLVED: Use same object as in 7589 to specify keyframe
offsets as well for
https://github.com/w3c/csswg-drafts/issues/7637
“API for Phase-linked Offsets in Keyframes”
- RESOLVED: Name UA-defined @keyframes rules with a -ua- prefix
(and presumably use this pattern elsewhere as needed)
https://github.com/w3c/csswg-drafts/issues/7560
“Scoping keyframe names in UA stylesheet”
- RESOLVED: The -ua- names *are* usable in author/user stylesheets.
https://github.com/w3c/csswg-drafts/issues/7560
“Scoping keyframe names in UA stylesheet”
- 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.
Nesting Syntax
--------------
- RESOLVED: Revert the previous resolutions from Nov 2021 that
adopt the bracket-nesting syntax
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Aug/0015.html
Chair: Rossen Atanassov
Present:
Rossen Atanassov
Tab Atkins
David Baron
Oriol Brufau
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Mason Freed
Megan Gardner
David Grogan
Chris Harrelson
Brad Kemper
Vladimir Levin
Daniel Libby
Peter Linss
Alison Maher
Khushal Sagar
Miriam Suzanne
Bramus Van Damme
<RRSAgent> logging to https://www.w3.org/2022/08/31-css-irc
Animations
==========
Scribe: TabAtkins
Specifying Timeline Phases in Web Animations API
------------------------------------------------
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
flackr: (1) extend .delay and .endDelay properties, which map to equivalent
css properties
flackr: These accept doubles currently, would need to be able to take
something expressing a phase+proportion
flackr: Advantage of option 1 is it's easy to understand
flackr: Option 2 is more in line with the desire to use typed properties
in these JS bindings
flackr: so we don't have 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 through 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?
RESOLVED: 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
<TabAtkins> +1
flackr: So representing a keyframe position as phase+offset
Rossen: objections?
<bramus> +1
<Sebo> +1
flackr: Summary: support passing a phase+offset object in the keyframe offsets
RESOLVED: 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: Tab has several proposals. One is a function, another is a
single-dash prefix, which isn't generally used, or specifically
a `-ua-` prefix.
ua(name-of-animation)
-name-of-animation
-ua-name-of-animation
fantasai: Just wanted to point out there were 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?
[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 properties 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, though
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 animation
to authors in some way
emilio: We have other at-rules in the UA sheet that we don't expose though,
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
TabAtkins: When you don't expose the name in scripting APIs, the name is
still exposed in properties?
TabAtkins: If the author defines something of the same name, it would
take precedence, right?
emilio: We chose -moz- prefixed things, since supposed to be internal
implementation detail
emilio: naming convention, especially if we use -ua-, would allow user
to override internal if they wanted
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 in other places where we might
run into similar problems also.
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 will
easily fit into any syntaxes where we might 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?
RESOLVED: 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?
<TabAtkins> No opinion here
RESOLVED: The -ua- names *are* usable in author/user stylesheets.
<bradk> Hopefully auto prefixers will not start adding-ua- to everything.
Nesting Syntax
==============
github: https://github.com/w3c/csswg-drafts/issues/4748
Scribe: fantasai
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
if it starts with an &, or using @nest to disambiguate otherwise
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 won
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
fantasai: The problem I noticed reading through 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
fantasai: So I don't think it's true that it was fairly written
TabAtkins: I didn't take that as part of the syntax at all, still needed
the & to be the nesting selector
fantasai: The point was that it was mostly never needed, so I think the
poll wasn't valid
miriam: I reviewed the article and helped come up with the syntax, so...
miriam: I didn't think of removing the & as the main advantage of the brackets
miriam: As I was writing it I found the brackets more confusing than expected,
and I actually *added* ampersands for clarity
miriam: After writing the demos I actually changed my mind away from bracketing
fantasai: I'm not going to block, if y'all *like* this syntax better that's
fine. I don't like having an inconsistent syntax, where a
disambiguation '@nest' is required but only sometimes.
fantasai: But I don't think it's fair to say the poll was overwhelmingingly
in one direction given a fair comparison.
Rossen: So it sounds like we have a pretty strong response. Possibly biased,
but Mia makes an argument for it not being so.
Rossen: So proposed resolution is to undo the resolutions from november
and leave the spec as it currently is
Rossen: Any additional comments or feedback?
fantasai: I'm not gonna object because everyone seems to like the current
proposal, but I really don't like that authors have to know when
to use @nest, it's not a consistent syntax
fantasai: And I wish we had something else besides an inconsistent syntax
fantasai: I don't like @nest everywhere since it's verbose, but...
miriam: I agree on the problem and it's why I liked bracket before. I agree
it's an issue and it's weird
miriam: But once I started writing examples, it almost all basic use-cases
you just use the & and it works and looks cleaner.
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
miriam: So that's why I changed my mind even tho I agree it's inconsistent
<bradk> +1 to miriam
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.
<fantasai> I'm not so opposed to the & , just that some rules require @nest
and others don't
plinss: I'm okay with undoing the previous resolution, just not sure we
should resolve affirmatively on the current syntax
Rossen: Right, so let's just resolve on undoing the previous resolution.
Rossen: Objections?
RESOLVED: Revert the previous resolution from Nov 2021 that adopts the
bracket-nesting syntax
Rossen: And for the record, want to strongly encourage continued improvement
of the design.
Animations (continued)
======================
Make Animation Shorthand Syntax Future-Proof
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6946
seb: We have an issue with new animation-* properties, that animation-name
makes problems in the shorthand
seb: You can't distinguish animation names from the keywords from the
other properties
seb: So how do we make it so that new properties, like animation-composition,
can make it into the shorthand?
seb: One way would be to create a new optional syntax that separates
the name from the rest with a slash, or something
seb: This would be optional, we couldn't enforce it on current property values
seb: This would hopefully be a gradual replacement, like with the color
function syntaxes.
flackr: I think another possibility is that, for new properties, they
will only be used if they are unambiguously not the animation
name (you've specified another property before them)
seb: So making the order more fixed?
flackr: Until an animation-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 keywords
TabAtkins: [gives example]
flackr: Correct
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]
flackr: One complication - with animation-timeline we've added another
arbitrary name to the shorthand, potentially
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
dbaron: Stricter alternative of what flackr suggested
dbaron: Maybe easier to explain
dbaron: We only extend the shorthand if animation-name is first
dbaron: So rather than having "these have to be after the name, these don't"
dbaron: Maybe the stricter rule of animation-name is first, and then you
can use the new stuff
<flackr> +1 sgtm
astearns: Does the current shorthand have position restrictions?
TabAtkins: No
dbaron: I think Tab's explanation isn't quite what it is, but my memory
is pretty old now
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
fantasai: The canonical order puts the name last, so there's probably
author sheets doing that today, and also script-generated values
fantasai: I think we'll have to fork the syntax in some way
fantasai: But it needs more brainstorming
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> Right, the non-name properties get first dibs on keywords,
and animation-name takes the first unclaimed one
fantasai: For now, we can treat animation-composition as a reset-only
property, so it's reset by the 'animation' but can't be set
in there
fantasai: That'll work to unblock while we solve the issue.
<TabAtkins> +1
seb: So I heard two suggestions - a slash, or putting the name first
and other keywords afterward
astearns: Possibly `name foo` instead of slash too
fantasai: I think we need to explore the syntax space, but not on the call
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 property by doing a
keyword prefix, actually
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
fantasai: All longhands not in Animations 1 treated as reset-only for now
<Sebo> +1
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.
TPAC
====
astearns: Please register your timeslots in the wiki for TPAC
astearns: And do the ArriveCan stuff if you're not Canadian,
it needs to be done ahead of time
Received on Thursday, 1 September 2022 17:04:12 UTC