- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 30 Oct 2024 18:43:35 -0400
- To: 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.
=========================================
View Transitions
----------------
- The below resolutions will be confirmed with the rest of the
working group asynchronously due to light attendance.
- RESOLVED: `auto` will match elements using their ID attributes,
falling back to element identity; `match-element` will
only use element identity (Issue #10995: Allow an
auto-generated `view-transition-name` that doesn't
default to ID)
- RESOLVED: We will use `match-element` in the Animations API when
element identity is used (Issue #10978: How are
auto-generated `view-transition-name`s exposed in JS APIs)
- noamr created an explainer (
https://github.com/WICG/view-transitions/blob/main/nested-explainer.md#layered-capture
)
for issue #10585 (Optionally capture some properties (e.g. opacity
/border) as style instead of snapshot). There were some initial
questions on if both modes should exist. Folks will read the
explainer and discuss further.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Oct/0013.html
Present:
Emilio Cobos Álvarez
Elika Etemad
Florian Rivoal
Cassondra Roberts
Noam Rosenthal
Khushal Sagar
Alan Stearns
Bramus Van Damme
Scribe: bramus
Scribe's scribe: fantasai
View Transitions
================
Allow an auto-generated `view-transition-name` that doesn't default
to ID
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10995
bramus: This issue is about allowing an auto view-transition-name to
be generated by specifying a keyword
bramus: a number of keywords suggested, from-element, per-element,
self, auto, auto-id
bramus: I asked authors "which keyword conveys using ID and falling
back to auto-generated" and "which keyword conveys
automatically generated"
bramus: when I asked which is "automatically generated", they picked
"auto"
bramus: when I asked about the ID and fallback, the responses ...
bramus: We were thinking 'from-element' but authors expected 'auto'
for "automatically generated".
bramus: We could meet developers by reverting previous resolution
about auto reading ID and falling back
bramus: and come up with a better keyword
bramus: or push authors towards using attr() function which is suited
for this, can use attr(id, auto) for fallback behavior
bramus: or keep previous resolution of using auto for fallback
behavior, but then we need to come up with a very good
keyword for the autogeneration
bramus: Authors prefer auto-id for autogenerated, and some suggested
generated
bramus: and some others said, don't we have attr() for this?
fantasai: We can conclude from the poll that there is confusion over
keywords
fantasai: Wording of poll most likely prompted some of the responses
fantasai: using “automatically generated id” pushed authors towards
`auto`
fantasai: Internally we are generating one, but that is just the
mechanism
fantasai: it is an internal detail
fantasai: they will never see it...we might not even generate one and
use pointer identity
fantasai: It's not about automatically generating ids, it's about the
identify of the element object
fantasai: Poll is probably a bit confused on that point
fantasai: Could try to come up with good keywords but maybe need some
more ideas
fantasai: but doesn't mean that we should revert decision on `auto`
fantasai: In terms of possible keywords: `match-element` is an option
as we use match in a few other places
fantasai: but open to ideas
fantasai: At webkit we think `auto` is the right way to define it
fantasai: and maybe need other keyword for the other thing
<noamr> I like match-element
astearns: The currently specced behavior for auto is to use the id
attr and fall back to auto generated one?
fantasai: It's to use the identity of the element
fantasai: If there is no id, we look at the element being the same
object or not
fantasai: In that case, the object hasn't been destroyed - it's a
singular one that you can map between tree versions
khush: Spec might say to generate one, but conceptually get the point
that that is one way to implement it. You don't need strings
to establish identity
khush: Of all options maybe self is nice as it doesn't hit at
generating something
khush: your identity is the nodes identity
khush: auto is confusing. Kind of a grab value in css to figure out
automatically what to do which is what we doing here as well
<fantasai> match-element? same-element?
florian: Explanation fantasai just gave: if that can be used. key
point is stability … so maybe a keyword like stable?
florian: If the element is still around it will be the same
florian: don't describe what we do but the why
noamr: I like match-element. we match not just the id, but the actual
elements
noamr: matching two state of the same element
<khush> I'm ok with match-node or match-element
bramus: I like all these suggestions just now, `stable` and
`match-element`.
bramus: Doesn't seem confusing
bramus: `from-element` implies reading from the element, but matching
is matching so seems like a good suggestion
bramus: wrt `auto` part, as DevRel we can hammer on this point, means
"try to get a name" not "automatically generate one"
astearns: Which method do we expect authors to use most?
noamr: It depends
noamr: Likely use explicit names. Otherwise likely to use auto, it
will just work.
noamr: But if they want to specifically say that id attrs don't
participate, then use match-element
noamr: I think auto would be more common, it will usually just work.
noamr: Element identity, not observable if generated string
astearns: We have a way of using the ID attribute, specifically, by
using attr() function
astearns: we have defined `auto` to match the element by ID if there
is one, or using other methods if not
astearns: Is there really a use case for "throw out the IDs and only
use the opaque element-matching algorithm" ?
khush: Point came up last time, if these are only two (auto and
attr(id)), then there's no way to say "I want to match based
on element identity even though I put an ID on it"
noamr: You wouldn't be able to match if element has an ID in only one
of the state
khush: or if ID is used for a different reason, and not used in view
transitions
astearns: I can see the case, but not expecting authors to run into
it much
noamr: Cleaner solution to have specific keywords for each behavior
astearns: Understand, but that's a theoretical purity argument
khush: We heard from one; AirBnB where teams use ids for entirely
different things
fantasai: In terms of the name clashing we might want to consider
namespacing ids taken from the element vs names that we put
directly into css
fantasai: That would avoid name clashing
fantasai: Already have pseudo selecting syntax but are not using the
# sign for keywords. Could say that if you pull the id from
the attr, then it gets prefixed with the # sign in the
matching.
fantasai: That would namespace it and avoid clashes
astearns: This would be an additional thing
fantasai: Would mean for auto and I guess attr() that we are
generating the name then you would use v-t-g(#id) to
select and style it
khush: Not sure about this, but maybe could do it for auto-generated
ones. Not for those read from attr.
khush: will be a pain to keep track of where it came from
fantasai: Fair
noamr: Against namespacing because of flexibility of VTs.
noamr: Take cross-doc VT with #hero id on one side and one with hero
v-t-name on other side
noamr: Would want to transition between those
khush: Can open issue separately from this
bramus: Just realized, we could not tackle this problem as part of
view transitions, keep auto as it is, and look at the ident()
function and allow it to take a keyword
bramus: So if you want to auto-generate an ident you use it
fantasai: So ident() should take what?
bramus: `view-transition-name: ident(auto)` to auto-generate an ident
bramus: So we don't have to come up with a keyword for this
fantasai: But that returns an actual observable identifier
fantasai: which we don't think we want to do
fantasai: should still have keyword for it
fantasai: Can consider is distinguishing between auto keyword
actually creating a reference-able v-t-n or just an
internal matching
fantasai: Can you select against the generated identifier is an open
question
fantasai: would we do that or just use the id attr to match elements
but not to select against it
fantasai: like `::v-t-g(id)`
khush: Would be nice if you could do it for for the `[id]` case
khush: pretty convenient
fantasai: Only downside is that we might have namespace clashes and
stuff that you are using for identity in the document
noamr: Right, mixing things
fantasai: Can agree on keeping `auto` as it is
fantasai: and for now add a keyword `match-element` for only looking
at element id
fantasai: and open issue about mixing the namespaces
astearns: Gonna need async resolution as we are low on people
attending
PROPOSED RESOLUTION: Add `match-element` keyword that will only use
element identity and not use id attributes.
astearns: will be submitted as an async resolution
RESOLVED: [Pending async confirmation] `auto` will match elements
using their ID attributes, falling back to element
identity; `match-element` will only use element identity.
ACTION: Open new issue about whether `auto` exposes the ID from the
ID attribute as a view-transition-name for pseudo-element
matching
<RRSAgent> records action 1
How are auto-generated `view-transition-name`s exposed in JS APIs
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10978
noamr: How do autogenerated appear in things like getAnimations?
noamr: What would these auto-generated ones look like? Available as
strings? Or give them a name of `match-element` or `*` or not
show them at all?
bramus: And devtools?
noamr: No, not included
khush: Two options:
khush: If we decided that id based names are hidden from css then it
makes sense to hide everything from auto
khush: or if name came from id attribute then do expose it but don't
expose the identity ones (and expose those as `match-element`)
astearns: The ids that auto uses could be made opaque but if the
author uses the attr() fn then they would be exposed?
khush: That's the complication with hiding ids
khush: If you use attr() then you have all those complications of
where you get the strings from
khush: Can punt on this until we decide how to namespace ids
bramus: If value derived from ID attribute and expose it, if you have
an element with an ID on one page and a different one on a
different page with a view-transition-name of hero, then one
transitions to the other
bramus: Would be useful to expose that name
bramus: If we fall back to match-element strategy, then show that as
match-element
bramus: because authors can't target those elements directly
bramus: by having match-element there, clearly can't target
fantasai: Question about whether id on one page would match a v-t-n
on other is part of the namespacing discussion
fantasai: don't have an opinion on direction
fantasai: If that worked, then we should make pseudos match that
fantasai: but q is then should that work in the first place?
fantasai: Do we want to expose the name derived from an id in the
first place? no opinion right now.
fantasai: Obviously should not expose autogenerated names
noamr: Strong opinion about keeping things simple… if generated by id
it's just that name
noamr: already doing complicated things that look different
noamr: If the v-t-name comes from an id, then that should be the v-t-n
noamr: if author don't want that, they should do other things
noamr: Let's keep things flat
noamr: regardless we can resolve to use the name `match-element` in
`getAnimations`
khush: Since we are going here … my alignment is with noam on this.
Keep it simple and treat them as names
khush: don't have author feedback on this though
khush: not a super strong opinion
khush: If this pattern is adopted like anchor-name and there is no
matching concept, do we want to have this namespacing concept
across css props then?
khush: Then VT won't have this own special thing
khush: concept would make sense across CSS
fantasai: None of the others have a way of pulling element id
khush: But can imagine anchor-pos doing the same over time
<noamr> I like that auto === id ? attr(id) : match-element
bramus: [missed]
astearns: But flatness isn't part of the issue
noamr: let's think about that a bit more
noamr: let's resolve on exposing them as `match-element`
astearns: Is there a conflict there?
noamr: It's just in getAnimations
astearns: Which is wrapped in a pseudo
khush: Compat risk for users that have used `match-element`
bramus: Don't think anyone has used that yet
khush: So if you use auto and we use the id attr then we expose the
id attr as string, and if we use identity then we expose
match-element
noamr: And tbd if these id-based names are namespaced or not
astearns: Should open an issue that
khush: Can do that
PROPOSED RESOLUTION: we will use `match-element` in the Animations
API when element identity is used
astearns: objections?
(silence)
RESOLVED: [Pending async confirmation] we will use `match-element` in
the Animations API when element identity is used
Optionally capture some properties (e.g. opacity/border) as style
instead of snapshot
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10585
noamr: Talked about capturing snapshots not flat but to also capture
borders, shadows, opacity, etc.
noamr: Had homework to figure out the exact way of how this would
work and do some compat analysis
noamr: Have done both to an extent
noamr: Wrote an explainer for this
<noamr> https://github.com/WICG/view-transitions/blob/main/nested-explainer.md#layered-capture
noamr: main question is if this is a net improvement to capturing
elements layered or not?
noamr: only works when elements are superimposed on each other in a
way, like cross-fade morphs the animation
noamr: many people use slide animations, like a header sliding
offscreen
noamr: when authors do that, capturing the borders separately creates
a different effect
noamr: backwards compat it wouldn't affect hat many people right now,
but those that are affected are affected in a big way
noamr: want to get attention to the explainer
noamr: there are a few options:
noamr: make it an opt-in
noamr: or create an extra pseudo for the geometry animation
noamr: it does create more things to think about it, but nice thing
about that it is that it does what it does today
noamr: you need to only style it if you want to
noamr: third option is to have no opt-in and have authors opt-out by
containment through adding an extra container element
noamr: not looking for a resolution now
khush: +1 to what noam said
khush: I am pretty convinced that original capture way might have
been a mistake.
khush: noam dug up styles that authors used to customize animations
and have found slight animations that were set up
khush: If you have two things
khush: where the whole bg changes you don't want those to fade but
just want the slide effect
khush: Don't want to break those
khush: especially on the root level
khush: Also don't want authors to have to create a wrapper around the
content in root to fix that
khush: Could maybe resolve that both these modes should exist
khush: How to select one or the other can be decided later
bramus: +1 on both modes being valuable
astearns: Need to read explainer a bit more. Wrapper made sense until
khushal's argument
noamr: Should generally avoid people to change their dom for style
purposes
bramus: +1
bramus: Can the extra pseudo give a perf benefit?
noamr: Not really. Think of border animating
noamr: I encourage people to look at the explainer
noamr: Especially the geometry part, because we copy over the
box model
noamr: Also scrollbars and stuff
noamr: Food for a next meeting
astearns: Thanks for the summary and explainer. It's great to have
astearns: Will summarize the breakout to the www-style list and set
up async resolutions and point people to the explainer
astearns: Gonna wrap up
Received on Wednesday, 30 October 2024 22:44:07 UTC