IRC log of css on 2022-10-05

Timestamps are in UTC.

23:00:29 [RRSAgent]
RRSAgent has joined #css
23:00:29 [RRSAgent]
logging to https://www.w3.org/2022/10/05-css-irc
23:00:30 [vmpstr]
present+
23:00:31 [Zakim]
RRSAgent, make logs Public
23:00:32 [Zakim]
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
23:00:45 [dael]
ScribeNick: dael
23:01:09 [plinss]
present+
23:01:33 [lea]
lea has joined #css
23:02:05 [ydaniv]
ydaniv has joined #css
23:02:16 [heycam]
heycam has joined #css
23:02:24 [dael]
iank_: Is there a reason why the baseline was dropped from the agenda?
23:02:29 [dandclark]
present+
23:02:34 [heycam]
present+
23:02:39 [ydaniv]
present+
23:02:40 [dael]
astearns: I remember removing one and there's a bunch labeled TPAC that needs to get retagged
23:02:46 [lea]
present+
23:02:59 [iank_]
https://github.com/w3c/csswg-drafts/issues/7775#issuecomment-1267250581
23:03:07 [dholbert]
dholbert has joined #css
23:03:20 [gtalbot]
gtalbot has left #css
23:03:21 [dael]
astearns: I do not recall
23:03:47 [dael]
astearns: fantasai said it wasn't super high priority
23:03:52 [dael]
fantasai: Compared to others
23:03:59 [dael]
iank_: It effects a lot of WPT tests
23:04:12 [dael]
astearns: Let's take that after shared element transitions issues?
23:04:30 [dael]
fantasai: I think it should be straight-forward to resolve. Unless other opinions can go with behavior in issue
23:04:38 [dael]
astearns: Any other updates to the agenda?
23:05:06 [dael]
astearns: Housekeeping. Lot of chatter around Nesting with a new proposal. Everyone with an opinion please give a look
23:05:09 [dholbert]
present+
23:05:10 [smfr]
smfr has joined #css
23:05:11 [dael]
astearns: Also getting impl feedback
23:05:23 [dael]
astearns: Next week we should have a couple of Nesting issues on the agenda
23:06:01 [dael]
lea: To offer background had a breakout today to discuss how to resolve Nesting issues. That's where the proposal and related issues came from. Current syntax is being implemented right now
23:06:11 [dael]
astearns: That info is in the issues so please take a look.
23:06:24 [dael]
Topic: [css-backgrounds] Are the rules for interactions of transforms and backgrounds on the root element what we want?
23:06:32 [dael]
github: https://github.com/w3c/csswg-drafts/issues/6683
23:06:50 [dael]
mattwoodrow: Looks like discussed last year, resolved to wait for filter spec
23:07:04 [dael]
mattwoodrow: I would like to continue discussion and make a decision. No strong opinions
23:07:16 [dael]
astearns: Can you get us up to speed with what has been discussed?
23:07:42 [dael]
mattwoodrow: Current state is inconsistent between impl and spec is unclear which path. Pretty open. Slight diff in if background is fixed.
23:07:48 [dael]
astearns: Anyone with opinions?
23:07:50 [jondavis]
jondavis has joined #css
23:07:54 [dael]
smaug: Any websites where this matters?
23:08:11 [smfr]
s/smaug/smfr/
23:08:20 [dael]
mattwoodrow: No one has found any. Poss because it's so different between browsers. I think Gecko never transforms, WebKit always, Chrome for scrolled but not fixed. No interop
23:08:32 [dael]
smfr: I would argue to easiest to implement
23:08:42 [gtalbot]
gtalbot has joined #css
23:08:50 [dael]
astearns: Naive guess is that's never transform?
23:09:01 [dael]
smfr: I think ignoring transform is easiest
23:09:28 [dael]
fantasai: Could make sense b/c if you're transforming the whole root you could want a bg behind it and don't want that to transform with the page. Should be something behind it.
23:09:41 [dael]
fantasai: If you want bg to transform with page you attach it to the page and get the behavior
23:09:57 [dael]
smfr: Makes sense to me. I think only bg that prop to canvas?
23:09:59 [dael]
fantasai: Yeah
23:10:15 [dael]
smfr: I would say they never transform. If they want transform but bg on the body
23:10:26 [TabAtkins]
This seems confusing in general, but I think the proposal makes sense
23:10:29 [dael]
astearns: Anyone want to argue for paying attention to transforms on root element background?
23:10:47 [dael]
astearns: Prop: Always ignore transforms on backgrounds of the root element
23:10:54 [dael]
astearns: Is that sufficient resolution?
23:10:57 [dael]
mattwoodrow: That's sufficient
23:11:17 [dael]
smfr: That's both bg attachment fixed and scroll I think. But what you said should be sufficient
23:11:27 [dael]
astearns: Objections?
23:11:35 [dael]
RESOLVED: Always ignore transforms on backgrounds of the root element
23:11:39 [karlcow]
karlcow has joined #css
23:11:56 [dael]
florian: Question - do we mean bg on the root or bg that prop to the canvas? Do we mean those two?
23:12:11 [dael]
fantasai: Yes. Anything prop to the canvas doesn't get impacted
23:12:19 [dael]
fantasai: There's no transforms on canvas
23:12:31 [dael]
astearns: Always ignore transforms on bg that get propagated to canvas
23:12:45 [dael]
smfr: Transforms applied to elements. If it's prop to canvas bg not effected
23:12:54 [dael]
fantasai: once prop to the canvas it's not impacted by any transforms
23:13:07 [dael]
astearns: BG that are propagated to canvas have any transforms taken away
23:13:18 [dael]
smfr: Render as if originating element had no transform
23:13:27 [dael]
florian: We're clear enough. Let editors write
23:13:37 [dael]
astearns: Current resolution + discussion or ammend the resolution?
23:13:51 [dael]
florian: Another.
23:13:59 [florian]
+1
23:14:02 [dael]
astearns: Always ignore transforms on backgrounds that propage to canvas
23:14:15 [dael]
RESOLVED: Always ignore transforms on backgrounds that propagate to canvas
23:14:25 [dael]
Topic: [css-shared-element-transitions-1] Renaming and brevity
23:14:32 [dael]
github: https://github.com/w3c/csswg-drafts/issues/7788
23:14:55 [dael]
vmpstr: I can intro. We want to rename structure to something more meaningful
23:15:13 [dael]
vmpstr: I would hope can resolve on feature name so can move to FPWD with a URL that's fixed
23:15:32 [dael]
vmpstr: JakeA proposed view-transition prefix to most things.
23:15:43 [dael]
vmpstr: Has been activity today discussing details
23:15:46 [ericwilligers]
ericwilligers has joined #css
23:16:17 [dael]
astearns: Note we can pick a fixed URL and then change syntax. We've done it before. Shouldn't look at shurt URL as unchangable thing.
23:16:42 [dael]
fantasai: But shared-element-transitions is not the name we want. Do we use view-transitions or css-view-transitions as the URL short name?
23:16:50 [khush]
+1 for css-view-transitions
23:16:56 [dael]
florian: Seems reasonable. might want ot change later, but not clear we will.
23:17:04 [dael]
astearns: Anyone argue against view-transitions?
23:17:35 [dael]
astearns: Could resolve on css-view-transitions as the short spec name. Can also resolve to change all draft syntax.
23:17:42 [TabAtkins]
Find with the shortname. Still not particularly happy with the syntax options, yeah
23:17:44 [dael]
fantasai: Can we do shortname first before we dive to everything else?
23:17:54 [dael]
astearns: Prop: Use css-view-transitions as the shortname
23:17:56 [dael]
astearns: Obj?
23:18:05 [dael]
RESOLVED: Prop: Use css-view-transitions as the shortname
23:18:29 [dael]
khush: Limit discussion to spec name or also touch on names for pseudo elements? Got a good bunch of options there
23:18:48 [dael]
astearns: Are you looking to have the discussion on call or continue on issue when there has been a little more async discussion?
23:19:12 [dael]
vmpstr: If we can timebox discussion? Want a sense of uncertainty. I think JakeA prop names are pretty reasonable. I feel like close to resolution
23:19:18 [dael]
astearns: Let's spend 10 min
23:19:30 [vmpstr]
https://github.com/w3c/csswg-drafts/issues/7788#issuecomment-1266772511
23:19:33 [dael]
vmpstr: In Jake's prop ^
23:20:08 [dael]
vmpstr: All the pseudo elements have view-transition prefix. The property to tag elements with an id is view-transition-name. Pseudos are view-transition-root. Images old and new are subpseudo elements.
23:20:31 [TabAtkins]
I prefer -images fwiw. The "set" doesn't mean anything afaict
23:20:41 [dael]
vmpstr: fantasai prop view-transition-set whic makes sense. Also prop to drop root from view-transition-root but that got pushback
23:20:48 [dael]
astearns: images vs set. Let's discuss
23:20:56 [dael]
astearns: fantasai can you say why good to change to set?
23:21:25 [khush]
i'm ok with set. it's smaller. :)
23:21:25 [dael]
fantasai: It's kind represent 2 images that correspond. It's not a selector that represents each image but represents the set that correspond. Captures it's a container
23:21:32 [TabAtkins]
q+
23:21:50 [dael]
astearns: If this is just [missed]. If you can duplicate on old and new and get same result why set?
23:22:27 [dael]
fantasai: Theres a wrapper for ar eason. If we were being really verbose with image-wrapper we could, but I think I prefer succinct. I like using transition-set on the wraper for 2 images
23:22:41 [astearns]
ack TabAtkins
23:22:50 [dael]
vmpstr: It's (image) also singular which makes it weird so set is good
23:23:28 [dael]
TabAtkins: I like images, the plural makes it clear that it's a set. I find set ot be so content-less I have no clue what it means. This structure can be various levels. Don't know why call one a set. I vote images
23:23:29 [vmpstr]
we also discussed -image-group
23:23:58 [dael]
fantasai: Other thing about images is we're getting into, I don't know, the fact that it is an image we should knwo that but what we're representing is a snapshot of older and newer version
23:24:15 [dael]
fantasai: Feels different than an image that is a replaced element
23:24:24 [dael]
TabAtkins: The fact that it's an image in browser is important
23:24:51 [dael]
fantasai: Images pseudo-element is not an image, it's a wrapper around 2. Since old and new doesn't have work 'image' having 'image' in wrapper is confusing
23:25:11 [dael]
astearns: Agree set is vague and images isn't great since it's a plural. Can someone describe what this is used for?
23:25:41 [dael]
vmpstr: It's a wrapper that sets up isolation for blending of 2 images. Not a replaced element, but container of 2 images being blended together.
23:25:52 [dael]
astearns: What are you going to use this pseudo element for?
23:26:14 [dael]
vmpstr: Not sure I understand. The opacity and blend modes of images will interact in it without effecting other things b/c it's isolated
23:26:25 [dael]
fantasai: I think astearns is asking how an author is likely to use this pseudo element
23:26:55 [iank_]
its similar to various cross-fade effects
23:26:56 [dael]
vmpstr: I see. I don't think there's a particularly good guidance on how to use. Typically dev wants to customize container above this, the parent of wrapper, or the opacity blend of images.
23:27:21 [dael]
vmpstr: Are some use cases where dev would want to shift container up or down. It moves left to right and container rises from below
23:27:51 [iank_]
effect-group?
23:27:58 [dael]
khush: Saw a demo where someone added a small animation to give a pop effect. Not what we anticipated for usage. We did it for cross fade, but that's a way we've seen devs using it.
23:28:36 [dael]
astearns: Given this is something that we don't have explicit use cases but we know people will use it. not crucial, though. Could go a longer name like view-transition-effect-group or -image-set
23:29:05 [dael]
fantasai: If you're going for long view-transition-old-new-set. I think it's good to not use image b/c not really an image
23:29:06 [TabAtkins]
(it is really an image)
23:29:14 [fantasai]
sorry, I meant conceptually
23:29:18 [fantasai]
it is implemented as an image
23:29:21 [TabAtkins]
I mean conceptually too
23:29:38 [dael]
khush: one of the earlier sugegstions was view-transition-group. Is that a good compromise? Maybe view is better than set.
23:29:44 [dael]
astearns: TabAtkins bjeciton to group?
23:30:08 [dael]
TabAtkins: It's jsut as generic and non-meaninful. If it's not high use I would say make it longer with a name for its purpose.
23:30:23 [dael]
TabAtkins: Where we expect style have shorter names like old new
23:30:44 [dael]
astearns: I suggest we take this back to the issue. Let's continue with this open and come back after a bit more discussion.
23:30:59 [dael]
astearns: I was going to suggest breaking it out, but there's good discussion so continue there
23:31:10 [dael]
Topic: [css-shared-element-transitions-1] Define "active animation" used to signal end of transition
23:31:14 [fantasai]
khush, I think wrt group, since in e.g. SVG and vector editing, groups are a hierarchical concept
23:31:19 [dael]
github: https://github.com/w3c/csswg-drafts/issues/7785
23:31:30 [fantasai]
khush, I think it's better not to use it for the image-pair-wrapper
23:31:53 [dael]
khush: The bg for this issue is that the pseudo elements we just discussed generated for a transition are meant to be temporary. need to decide when it's torn down
23:31:54 [fantasai]
khush, seems more appropriate for the higher-level construct that you can nest other things inside
23:32:26 [TabAtkins]
q+
23:32:29 [dael]
khush: We use declarative elments to decide. web animations, animations, transitions. raff -based are excluded b/c browser doesn't know when we're done. For these want to auto-detect done
23:32:44 [dael]
khush: Wanted precise def for what state animations are in for active
23:32:49 [TabAtkins]
Actually kind of a point of order for this
23:33:13 [dael]
khush: Issue leaned to rely on animation state. Go through all pseudo elements and check for idle, running, paused
23:33:58 [dael]
TabAtkins: The entire point of the issue I wrote is it's supposed to abort if any other shared element transition are running, not any other animation. I never intended for web or css animations to be part of it. When I wrote spec I presumed only 1 running shared element transition at a time and need to check.
23:34:31 [dael]
khush: I think might be confusing different part of feature. This is have a single transistion going and need to know when it ends. That relies on the pseudo elements generated for the transition
23:34:39 [dael]
TabAtkins: Possibly. I don't recall writing that but okay
23:35:17 [TabAtkins]
Okay yes, I was misreading
23:35:22 [TabAtkins]
Ignore me. 😅
23:35:27 [astearns]
ack TabAtkins
23:35:32 [dael]
khush: Clarify exact point. Started a transtion and have detected shared elements. Constructed full pseudo element tree. UA animations applied. Nw want to detect when tree can be torn down. We keep checking animastions on all pseudo elements. Need to define when animation is active for this transition
23:35:43 [dael]
khush: I see IRC. Glad on same page
23:36:29 [dael]
khush: On issue, concultion is check for any aniamation in running or paused. If yes, it's still acitve. Then check pending animation event queue. If there's something in there the's a pending event. Use case for that is chaining and we want to make sure all events chained
23:36:33 [dael]
khush: Hoping to resolve on that
23:37:11 [dael]
khush: Second is animation timeline. Animation uses doc timeline and we know timeline will progress. If you aheva scroll timeline the timeline progress dpends on if there's a scroll gesture.
23:37:14 [vmpstr]
q+
23:37:43 [astearns]
ack vmpstr
23:37:46 [dael]
khush: Prop is ignore those for now b/c couldn't narrow down. When we decide a solution for raff we can handle similar or decide when have more idea of use
23:38:02 [dael]
vmpstr: Even with doc timeline you can set up animation that loops so can get same situation
23:38:23 [dael]
khush: True, but in that case it is easier to tell. With scroll timeline it's ambig since user gesture might never happen
23:38:41 [dael]
astearns: Sounded like 2 things to resolve. Timeline first?
23:38:55 [dael]
khush: Sure. Prop: Only consider animations using the document timeline in the active animation set
23:39:02 [gtalbot]
gtalbot has joined #css
23:39:04 [dael]
astearns: Opinions? Questions?
23:39:37 [dael]
astearns: as I understand, only consider animations using doc timeline for determining when the end of a view transition has come
23:39:47 [dael]
astearns: Concerns?
23:39:56 [dael]
astearns: Obj?
23:40:06 [dael]
RESOLVED: only consider animations using document timeline for determining when the end of a view transition has come
23:40:11 [ydaniv]
only paused and running too, right?
23:40:14 [dael]
astearns: Second
23:40:48 [dael]
khush: Second For the animations we consider we consider them active if there's in running or paused and when there are not animations in the pending event queue
23:40:58 [dael]
astearns: Can be animations on things other than view transform pseudos
23:41:03 [dael]
khush: right.
23:41:20 [dael]
khush: No animations on the pending event queue that correspond to these pseudos
23:41:41 [ydaniv]
that's cool
23:41:42 [dbaron]
Present+
23:42:14 [dael]
astearns: Prop: View animations are still active if there are running or paused animations in the pending event queue associated with these pseudos
23:42:23 [dael]
astearns: I imagine I may have something wrong
23:42:48 [miriam]
present+
23:42:49 [dael]
khush: View animations are still acitve if they are in runing or paused state and if there are any events in the pending event queue associated with them
23:42:53 [ydaniv]
* View transition animations
23:43:14 [khush]
View animations are still active if there are running or paused animations or any events in the pending event queue associated with animations on these pseudos
23:43:32 [dael]
astearns: More discussion on this?
23:43:40 [dael]
astearns: Objections?
23:44:08 [dael]
astearns: One ammendment. View animations are still acitve if there are running or paused animations
23:44:21 [dael]
astearns: One ammendment. View animations are still acitve if there are running or paused view transistion animations
23:44:37 [dael]
khush: View animations means animations on any of thses pseudo elements
23:44:41 [dael]
astearns: Obj?
23:44:57 [dael]
RESOLVED: View animations are still active if there are running or paused view transition animations or any events in the pending event queue associated with animations on these pseudos
23:45:33 [dael]
astearns: I see a comment in github while we discussed. He's asking about timelines to current document.
23:45:50 [dael]
astearns: Is the comment something we can decide on or should we go back to the issue?
23:45:52 [astearns]
https://github.com/w3c/csswg-drafts/issues/7785#issuecomment-1269109950
23:45:58 [dael]
astearns: Comment ^
23:46:26 [dael]
khush: I need to read on this more. Okay coming back for this
23:46:33 [dael]
Topic: [css-shared-element-transitions-1] Define how rendering is suppressed between DOM changes
23:46:47 [dael]
github: https://github.com/w3c/csswg-drafts/issues/7784
23:47:16 [dael]
khush: This issue was about one aspect of feature where when switching doc state a to b we allow dev to async update dom w/o presenting to user.
23:47:40 [dael]
khush: We had these use cases in wild where you have a frame that you render and flips back to snapshot state. You get intermediate frames before animation
23:48:19 [dael]
khush: Question on how to suppress. One is render blocking that draws on HTML. BRowser suppresses rendering opportunities
23:48:32 [dael]
khush: When you call script API to start, we snapshot and then suppress rendering opportunities
23:49:00 [dael]
khush: Other is we keep running lifecycle but browser doesn't present them. Tha could be confusing so prop blocking
23:49:53 [dael]
khush: We are planning scoped transitions where it runs on a dom subtree and then we can't do render blocking. I've linked to a prop there for how we want to manage the rendering with scoped transitions. It's using a cached snapshot but keep running the process and retuning the cach
23:50:06 [dael]
khush: Would cause a difference between transition types
23:50:16 [smfr]
q+
23:50:21 [dael]
khush: Prop is go with render blocking behavior for same document and cross document cases
23:50:28 [astearns]
ack smfr
23:50:31 [dael]
smfr: Would render blocking, is all JS paused?
23:50:48 [dael]
khush: No, not at all. Just the update rendering lop is paused
23:50:53 [dael]
smfr: Would set timeout fire?
23:51:03 [dael]
khush: Yes. Request animation won't
23:51:11 [dael]
smfr: Seems weird to turn off some callbacks but not others
23:51:27 [dael]
khush: Steps that are part of update rendering loop are paused. Similar to if document is not visible
23:51:34 [TabAtkins]
+1, this seems reasonable to me
23:51:50 [dael]
smfr: If you did call request animation frame you'd get the callback after render blocking is off
23:52:08 [dael]
khush: Correct. Similar to render blocking for a new page doc. Whole loop doesn't run until resources fetched
23:52:26 [dael]
astearns: Is there a definition of what does and does not work when document is not visible? I'm wondering if it's similar or exactly like
23:52:41 [gtalbot]
gtalbot has left #css
23:52:44 [dael]
khush: Best would be render blocking in the HTML spec. Poitns to rendering opptys and says browser pauses
23:53:01 [vmpstr]
update the rendering, for reference: https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering
23:53:09 [dael]
khush: clear definition of what is meant to be fired in render loop so gives precise definition
23:53:17 [dael]
smfr: Remind me what triggers unblocking?
23:53:37 [dael]
khush: script api you call a function with a callback. async callback where dev does all dom mutations. Promise from that unblocks
23:53:45 [dael]
smfr: Are tehre other transitions/animations that can run?
23:53:50 [dael]
khush: All animations pause
23:54:05 [dael]
smfr: Completion doesn't require an animation to render
23:54:18 [dael]
khush: Aim of this callback is for you to do min network work you have to do
23:54:39 [ydaniv]
will that freeze video playback as well?
23:54:48 [dael]
khush: There is no risk of deadlock b/c dev callback should be waiting on anything dispatched during this
23:55:01 [dael]
khush: video playback will freeze
23:55:36 [dael]
khush: One of the main reasons is the one frame that runs if you don't pause you get a weird flick where you draw more frames but then anything animated flips back to cahced state
23:55:45 [dael]
smfr: Pausing video might be tricky for WK
23:55:58 [dael]
khush: I think we impl by the parts of stack running animations not giving them resync
23:56:18 [dael]
smfr: We oofload some to OS. You're in the middle of a transform...what happens to timeline of animations for render blocking?
23:56:31 [gtalbot]
gtalbot has joined #css
23:56:49 [dael]
khush: Time proceeds. Timeline will progress forward. Similar to visiblity where itab is backgrounded you don't draw but when you come back animation draws at current time
23:57:16 [dael]
khush: I can see impl tough. Motivating factor is this weird flick where you go forward a bit and then back in time when you move to cached snapshots
23:57:36 [dael]
astearns: Sounds like you have concerns smfr. You okay resolving to use render blocking and then open issues as you impl?
23:57:41 [dael]
smfr: Yeah, I think so
23:57:48 [dael]
astearns: Other opinions on using render blocking?
23:58:01 [dael]
astearns: ydaniv is the freezing video what you were looking for?
23:58:17 [dael]
ydaniv: Just look weird, same as animations stopping. I guess it will be necessary
23:58:23 [dbaron]
s/oofload/offload/
23:58:41 [dael]
khush: Prop: Rendering suppression uses render blocking to pause update the rendering loop during a view transition
23:58:49 [dael]
astearns: Objections?
23:58:56 [dael]
RESOLVED: Rendering suppression uses render blocking to pause update the rendering loop during a view transition
23:59:12 [dael]
Topic: Fallback alignment groups with orthogonal items.
23:59:18 [dael]
github: https://github.com/w3c/csswg-drafts/issues/7775
23:59:59 [dael]
iank_: basically, when inside a flexbox or grid. Column flexbox and align by baseline need an orthogonal WM. Veritical lr go in one group, vertical lr go in another.
00:00:26 [dael]
iakSpec places orthoganal in verital lr. fantasai prop to switch based on direction. if dir rtl go in vrl group
00:00:36 [dael]
fantasai: That's the prop
00:00:41 [astearns]
s/Veritical lr/Vertical rl/
00:01:06 [dael]
iank_: This is an edge case. Need to pick a group. Fine with prop. 5 or 6 WPT to change. vlr always has 20 changes. Tests are inconsistent here
00:01:25 [dael]
fantasai: Switching based on direction makes logical sense. Somewhat symmetric.
00:01:33 [dael]
astearns: Prop: left to left and right to right?
00:01:46 [dael]
iank_: Left groups always on left and right groups always on right
00:01:48 [dael]
astearns: Concerns?
00:01:52 [dael]
astearns: Obj?
00:02:01 [dael]
RESOLVED: Left to left and right to right
00:02:10 [dael]
astearns: iank_ are you updating tests?
00:02:15 [dael]
iank_: Yes, I have a patch in the issue
00:02:17 [dael]
Topic: end
00:02:36 [dael]
astearns: Out of time. Please look at nesting discussion in several issues. If I can convince Rossen we'll start there next week
00:03:17 [TabAtkins]
Most relevant issue to read for Nesting: https://github.com/w3c/csswg-drafts/issues/7834#issuecomment-1268979633
00:06:03 [gtalbot]
gtalbot has left #css
00:10:24 [plinss]
fantasai: I presume css-shared-element-transitions-1 needs to be renamed in the repo to css-view-element-transitions-1, right?
00:12:15 [astearns]
zakim, end meeting
00:12:15 [Zakim]
As of this point the attendees have been khush, dael, GameMaker, mattwoodrow, vmpstr, plinss, dandclark, heycam, ydaniv, lea, dholbert, dbaron, miriam
00:12:17 [Zakim]
RRSAgent, please draft minutes v2
00:12:17 [RRSAgent]
I have made the request to generate https://www.w3.org/2022/10/05-css-minutes.html Zakim
00:12:20 [Zakim]
I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye
00:12:24 [Zakim]
Zakim has left #css
00:18:41 [dbaron]
plinss, the new name doesn't have "element-" in it
01:02:52 [vmpstr]
vmpstr has joined #css
01:02:54 [CSSWG_LogBot_]
CSSWG_LogBot_ has joined #css