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

iank_: Is there a reason why the baseline was dropped from the agenda?

astearns: I remember removing one and there's a bunch labeled TPAC that needs to get retagged

<iank_> https://github.com/w3c/csswg-drafts/issues/7775#issuecomment-1267250581

astearns: I do not recall

astearns: fantasai said it wasn't super high priority

fantasai: Compared to others

iank_: It effects a lot of WPT tests

astearns: Let's take that after shared element transitions issues?

fantasai: I think it should be straight-forward to resolve. Unless other opinions can go with behavior in issue

astearns: Any other updates to the agenda?

astearns: Housekeeping. Lot of chatter around Nesting with a new proposal. Everyone with an opinion please give a look

astearns: Also getting impl feedback

astearns: Next week we should have a couple of Nesting issues on the agenda

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

astearns: That info is in the issues so please take a look.

[css-backgrounds] Are the rules for interactions of transforms and backgrounds on the root element what we want?

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

mattwoodrow: Looks like discussed last year, resolved to wait for filter spec

mattwoodrow: I would like to continue discussion and make a decision. No strong opinions

astearns: Can you get us up to speed with what has been discussed?

mattwoodrow: Current state is inconsistent between impl and spec is unclear which path. Pretty open. Slight diff in if background is fixed.

astearns: Anyone with opinions?

smfr: Any websites where this matters?

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

smfr: I would argue to easiest to implement

astearns: Naive guess is that's never transform?

smfr: I think ignoring transform is easiest

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.

fantasai: If you want bg to transform with page you attach it to the page and get the behavior

smfr: Makes sense to me. I think only bg that prop to canvas?

fantasai: Yeah

smfr: I would say they never transform. If they want transform but bg on the body

<TabAtkins> This seems confusing in general, but I think the proposal makes sense

astearns: Anyone want to argue for paying attention to transforms on root element background?

astearns: Prop: Always ignore transforms on backgrounds of the root element

astearns: Is that sufficient resolution?

mattwoodrow: That's sufficient

smfr: That's both bg attachment fixed and scroll I think. But what you said should be sufficient

astearns: Objections?

RESOLUTION: Always ignore transforms on backgrounds of the root element

florian: Question - do we mean bg on the root or bg that prop to the canvas? Do we mean those two?

fantasai: Yes. Anything prop to the canvas doesn't get impacted

fantasai: There's no transforms on canvas

astearns: Always ignore transforms on bg that get propagated to canvas

smfr: Transforms applied to elements. If it's prop to canvas bg not effected

fantasai: once prop to the canvas it's not impacted by any transforms

astearns: BG that are propagated to canvas have any transforms taken away

smfr: Render as if originating element had no transform

florian: We're clear enough. Let editors write

astearns: Current resolution + discussion or ammend the resolution?

florian: Another.

<florian> +1

astearns: Always ignore transforms on backgrounds that propage to canvas

RESOLUTION: Always ignore transforms on backgrounds that propagate to canvas

[css-shared-element-transitions-1] Renaming and brevity

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

vmpstr: I can intro. We want to rename structure to something more meaningful

vmpstr: I would hope can resolve on feature name so can move to FPWD with a URL that's fixed

vmpstr: JakeA proposed view-transition prefix to most things.

vmpstr: Has been activity today discussing details

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.

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?

<khush> +1 for css-view-transitions

florian: Seems reasonable. might want ot change later, but not clear we will.

astearns: Anyone argue against view-transitions?

astearns: Could resolve on css-view-transitions as the short spec name. Can also resolve to change all draft syntax.

<TabAtkins> Find with the shortname. Still not particularly happy with the syntax options, yeah

fantasai: Can we do shortname first before we dive to everything else?

astearns: Prop: Use css-view-transitions as the shortname

astearns: Obj?

RESOLUTION: Prop: Use css-view-transitions as the shortname

khush: Limit discussion to spec name or also touch on names for pseudo elements? Got a good bunch of options there

astearns: Are you looking to have the discussion on call or continue on issue when there has been a little more async discussion?

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

astearns: Let's spend 10 min

<vmpstr> https://github.com/w3c/csswg-drafts/issues/7788#issuecomment-1266772511

vmpstr: In Jake's prop ^

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.

<TabAtkins> I prefer -images fwiw. The "set" doesn't mean anything afaict

vmpstr: fantasai prop view-transition-set whic makes sense. Also prop to drop root from view-transition-root but that got pushback

astearns: images vs set. Let's discuss

astearns: fantasai can you say why good to change to set?

<khush> i'm ok with set. it's smaller. :)

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

astearns: If this is just [missed]. If you can duplicate on old and new and get same result why set?

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

vmpstr: It's (image) also singular which makes it weird so set is good

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

<vmpstr> we also discussed -image-group

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

fantasai: Feels different than an image that is a replaced element

TabAtkins: The fact that it's an image in browser is important

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

astearns: Agree set is vague and images isn't great since it's a plural. Can someone describe what this is used for?

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.

astearns: What are you going to use this pseudo element for?

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

fantasai: I think astearns is asking how an author is likely to use this pseudo element

<iank_> its similar to various cross-fade effects

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.

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

<iank_> effect-group?

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.

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

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

<TabAtkins> (it is really an image)

<fantasai> sorry, I meant conceptually

<fantasai> it is implemented as an image

<TabAtkins> I mean conceptually too

khush: one of the earlier sugegstions was view-transition-group. Is that a good compromise? Maybe view is better than set.

astearns: TabAtkins bjeciton to group?

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.

TabAtkins: Where we expect style have shorter names like old new

astearns: I suggest we take this back to the issue. Let's continue with this open and come back after a bit more discussion.

astearns: I was going to suggest breaking it out, but there's good discussion so continue there

[css-shared-element-transitions-1] Define "active animation" used to signal end of transition

<fantasai> khush, I think wrt group, since in e.g. SVG and vector editing, groups are a hierarchical concept

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

<fantasai> khush, I think it's better not to use it for the image-pair-wrapper

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

<fantasai> khush, seems more appropriate for the higher-level construct that you can nest other things inside

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

khush: Wanted precise def for what state animations are in for active

<TabAtkins> Actually kind of a point of order for this

khush: Issue leaned to rely on animation state. Go through all pseudo elements and check for idle, running, paused

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.

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

TabAtkins: Possibly. I don't recall writing that but okay

<TabAtkins> Okay yes, I was misreading

<TabAtkins> Ignore me. 😅

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

khush: I see IRC. Glad on same page

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

khush: Hoping to resolve on that

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.

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

vmpstr: Even with doc timeline you can set up animation that loops so can get same situation

khush: True, but in that case it is easier to tell. With scroll timeline it's ambig since user gesture might never happen

astearns: Sounded like 2 things to resolve. Timeline first?

khush: Sure. Prop: Only consider animations using the document timeline in the active animation set

astearns: Opinions? Questions?

astearns: as I understand, only consider animations using doc timeline for determining when the end of a view transition has come

astearns: Concerns?

astearns: Obj?

RESOLUTION: only consider animations using document timeline for determining when the end of a view transition has come

<ydaniv> only paused and running too, right?

astearns: Second

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

astearns: Can be animations on things other than view transform pseudos

khush: right.

khush: No animations on the pending event queue that correspond to these pseudos

<ydaniv> that's cool

astearns: Prop: View animations are still active if there are running or paused animations in the pending event queue associated with these pseudos

astearns: I imagine I may have something wrong

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

<ydaniv> * View transition animations

<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

astearns: More discussion on this?

astearns: Objections?

astearns: One ammendment. View animations are still acitve if there are running or paused animations

astearns: One ammendment. View animations are still acitve if there are running or paused view transistion animations

khush: View animations means animations on any of thses pseudo elements

astearns: Obj?

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

astearns: I see a comment in github while we discussed. He's asking about timelines to current document.

astearns: Is the comment something we can decide on or should we go back to the issue?

<astearns> https://github.com/w3c/csswg-drafts/issues/7785#issuecomment-1269109950

astearns: Comment ^

khush: I need to read on this more. Okay coming back for this

[css-shared-element-transitions-1] Define how rendering is suppressed between DOM changes

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

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.

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

khush: Question on how to suppress. One is render blocking that draws on HTML. BRowser suppresses rendering opportunities

khush: When you call script API to start, we snapshot and then suppress rendering opportunities

khush: Other is we keep running lifecycle but browser doesn't present them. Tha could be confusing so prop blocking

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

khush: Would cause a difference between transition types

khush: Prop is go with render blocking behavior for same document and cross document cases

smfr: Would render blocking, is all JS paused?

khush: No, not at all. Just the update rendering lop is paused

smfr: Would set timeout fire?

khush: Yes. Request animation won't

smfr: Seems weird to turn off some callbacks but not others

khush: Steps that are part of update rendering loop are paused. Similar to if document is not visible

<TabAtkins> +1, this seems reasonable to me

smfr: If you did call request animation frame you'd get the callback after render blocking is off

khush: Correct. Similar to render blocking for a new page doc. Whole loop doesn't run until resources fetched

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

khush: Best would be render blocking in the HTML spec. Poitns to rendering opptys and says browser pauses

<vmpstr> update the rendering, for reference: https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering

khush: clear definition of what is meant to be fired in render loop so gives precise definition

smfr: Remind me what triggers unblocking?

khush: script api you call a function with a callback. async callback where dev does all dom mutations. Promise from that unblocks

smfr: Are tehre other transitions/animations that can run?

khush: All animations pause

smfr: Completion doesn't require an animation to render

khush: Aim of this callback is for you to do min network work you have to do

<ydaniv> will that freeze video playback as well?

khush: There is no risk of deadlock b/c dev callback should be waiting on anything dispatched during this

khush: video playback will freeze

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

smfr: Pausing video might be tricky for WK

khush: I think we impl by the parts of stack running animations not giving them resync

smfr: We offload some to OS. You're in the middle of a transform...what happens to timeline of animations for render blocking?

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

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

astearns: Sounds like you have concerns smfr. You okay resolving to use render blocking and then open issues as you impl?

smfr: Yeah, I think so

astearns: Other opinions on using render blocking?

astearns: ydaniv is the freezing video what you were looking for?

ydaniv: Just look weird, same as animations stopping. I guess it will be necessary

khush: Prop: Rendering suppression uses render blocking to pause update the rendering loop during a view transition

astearns: Objections?

RESOLUTION: Rendering suppression uses render blocking to pause update the rendering loop during a view transition

Fallback alignment groups with orthogonal items.

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

iank_: basically, when inside a flexbox or grid. Column flexbox and align by baseline need an orthogonal WM. Vertical rl go in one group, vertical lr go in another.

iakSpec places orthoganal in verital lr. fantasai prop to switch based on direction. if dir rtl go in vrl group

fantasai: That's the prop

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

fantasai: Switching based on direction makes logical sense. Somewhat symmetric.

astearns: Prop: left to left and right to right?

iank_: Left groups always on left and right groups always on right

astearns: Concerns?

astearns: Obj?

RESOLUTION: Left to left and right to right

astearns: iank_ are you updating tests?

iank_: Yes, I have a patch in the issue

end

astearns: Out of time. Please look at nesting discussion in several issues. If I can convince Rossen we'll start there next week

<TabAtkins> Most relevant issue to read for Nesting: https://github.com/w3c/csswg-drafts/issues/7834#issuecomment-1268979633

<plinss> fantasai: I presume css-shared-element-transitions-1 needs to be renamed in the repo to css-view-element-transitions-1, right?