- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Dec 2021 16:46:53 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Shared Element Transitions`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Shared Element Transitions<br> <khush> For the upcoming press.<br> <chris> https://docs.google.com/presentation/d/15y60zFddT859VHKNeH6bjJyrZ1wIr8W7VUfRfr-icIk/edit#slide=id.p<br> <fantasai> khush: Going to use a very simple example<br> <dbaron> (khush explained that he sent it to www-archive but it's waiting for approval)<br> <fantasai> [slide 2]<br> <fantasai> khush: ...<br> <fantasai> khush: Core design in both states<br> <fantasai> khush: what to highlight new CSS attribute callled page transitions tag<br> <fantasai> khush: During transition we create alternate representation of DOM after snapshotting<br> <fantasai> khush: Page tells us which parts to shapshot as independent pieces<br> <fantasai> khush: This is saying root element should also be captured<br> <fantasai> khush: Other apect is properties that are changing<br> <fantasai> [slide 3]<br> <fantasai> khush: This slide shows box tree during transition<br> <fantasai> khush: have root stacking context, author dom underneath<br> <fantasai> khush: during transition we create tree of pseudo-elements that is sibling of root stacking context<br> <dbaron> github: https://github.com/w3c/csswg-drafts/issues/6464<br> <fantasai> khush: highlight fact that this transition stacking context, it paints as a sibling of the root context<br> <fantasai> khush: reason is, these content elements are displaying images from author dom<br> <fantasai> khush: it's displaying root stacking context<br> <fantasai> khush: inintially tried to place n top layer, but ran into circular dependencies<br> <fantasai> khush: wanted to capture other elements in top layer<br> <fantasai> khush: so put it in an independent stacking context as sibling of root<br> <fantasai> [slide 4]<br> <fantasai> khush: on the left dom structure, on the right stylesheet from UA<br> <fantasai> khush: focus on container element<br> <fantasai> khush: we have layout computed properties for each element with a page-transition tag<br> <fantasai> khush: and we have transform that maps into ?? space<br> <fantasai> khush: UA that generates, box renders at same spot that renders in author DOM<br> <fantasai> khush: Last is z-index for paint ordering<br> <fantasai> khush: we compute that anduse z-index to paint in same order in peudo tree<br> <fantasai> khush: container get us box that maps to actual element's box<br> <fantasai> khush: content fo element comes from ??? proeprties<br> <fantasai> khush: Using element in CSS to get a painted representation of the DOM element's contents<br> <vmpstr> s/???/old-content and new-content/<br> <fantasai> khush: this is a snapshot of element in the new dom<br> <fantasai> khush: the old one is snapshot of old content with cacehed element<br> <fantasai> khush: we cache a static paint to retain the content of the old dom<br> <fantasai> khush: then DOM changed to new state<br> <fantasai> [slide 5]<br> <fantasai> khush: Previous slide showed transition pseudo element tree and how to make it look like author dom<br> <fantasai> khush: this shows the animations shoing change from old to new state<br> <fantasai> khush: first animates box from old size andposition to new size and position<br> <fantasai> khush: for the content just do a swap, old content fadesin / new content fades out<br> <fantasai> khush: because of all the pseudo elements exposed to developer, can customize any way they want<br> <vmpstr> [slide 6]<br> <fantasai> khush: this slide meant to highlight the ...<br> <fantasai> khush: want to approximate the rendering as much as possible<br> <fantasai> khush: issue with inherited properties<br> <fantasai> khush: won't retain inherited from ancestors, but will ...<br> <fantasai> khush: When generating snapshot, doesn't include any effects from ancestors<br> <fantasai> khush: Everything with a page-transition tag paitns in ame orderin pseudo-element treee<br> <fantasai> khush: but if element ?? wasn't tagged, then its content is in the root element image<br> <astearns> s/.../retain positioning and screen space transforms/<br> <fantasai> khush: and this will cause a paint order change<br> <fantasai> khush: Last is the liveness of DOM, old DOM is static, but new dom is live-updated<br> <fantasai> khush: By design; that's how element() function works today<br> <smfr> next silde<br> <fantasai> [slide 7]<br> <fantasai> khush: list of spec changes<br> <fantasai> khush: First is to update the element() spec<br> <fantasai> khush: right now element() generates an element that is size of element's bounding box<br> <fantasai> khush: ink overflow is getting lcipped<br> <fantasai> fantasai: don't think you can include the ink overflow<br> <fantasai> fantasai: because then size of image is unpredictable<br> <fantasai> fantasai: and ink overflow is potentially infinite, and where it gets clipped will vary by implementation<br> <TabAtkins> scribe+ TabAtkins<br> <fantasai> s/unpredictable/unpredictable, and can't be accurately positioned by the author/<br> <fantasai> khush: Next is stnadardizing the pseudo-element tree<br> <fantasai> khush: so need to spec that<br> <fantasai> khush: then need to define new stacking context for transitions<br> <fantasai> khush: and because of ink overflow, need to define that replaced element can overflow its box<br> <fantasai> khush: blending pixels, have a proposal to allow that<br> <fantasai> khush: Right now actively implementing this<br> <fantasai> khush: want to get feedback in WICG on issues like fantasai raised<br> <fantasai> khush: as implementation matures will discuss issues<br> <fantasai> astearns: Suggest participating in repo, would like to get this feature right<br> <fantasai> astearns: On the call want to discuss if any serious concerns with the direction being proposed<br> <fantasai> smfr: Various limitations in escaping ancestor effects like opacity and filters<br> <fantasai> smfr: makes me think people will write pages ...<br> <fantasai> smfr: pop out of ancestor opacity and then nmove<br> <fantasai> smfr: seems limitation of implementation, only snapshotting things and not the whole tree?<br> <fantasai> khush: 2 additions<br> <fantasai> khush: right now snapshotting the whole element<br> <fantasai> khush: but added a mode where only snapshottong ?? and keep decorations and other things<br> <fantasai> khush: the other mode also snapshots highlighting etc. (????)<br> <fantasai> khush: Want to get there, but incrementally<br> <fantasai> khush: can point to explainer<br> <fantasai> khush: don't have issue of ancestor effects not being preserved<br> <fantasai> smfr: Showed pseudo-element hierarchy<br> <fantasai> smfr: you're snapshotting old content<br> <fantasai> smfr: using speudo-elements to define animations<br> <fantasai> smfr: but no DOM node behind that<br> <fantasai> khush: Once cached the state, need to be able to represent<br> <fantasai> khush: to get the rendering to look like author DOM, we made a tree of pseudo-elements<br> <fantasai> smfr: There are some similarities with things like animation-worklet<br> <fantasai> smfr: where you have a little JS world where you are limited in what you can do, but this is a little different<br> <fantasai> khush: Because pseudo-elements, limits in what you can do<br> <fantasai> khush: e.g. introducing own notes in tree or changing structure of tree<br> <fantasai> khush: getting to work with those requests is difficult<br> <fantasai> khush: limitations are defined here by what you can do with pseudo-elements<br> <fantasai> khush: so you can change their style, but not their structure<br> <fantasai> khush: can animate using CSS animations<br> <fantasai> smfr: can you apply arbitrary properties?<br> <fantasai> khush: yes<br> <fantasai> smfr: so you are running layout on the tree<br> <fantasai> khush: WE had cases where box aspect ratio was changing, wanted not to stretch but to clip, so set 'object-fit' and it just work<br> <fantasai> smfr: when p-e tree is showing, is it sitting on top and cans ee document underneath?<br> <fantasai> khush: in UA stylesheet we set 'visibility: hidden' on elements with page-transition tag<br> <fantasai> khush: don't actually show the page content, but still there<br> <fantasai> khush: if changing small part of page, don't put page-transition tag on the root<br> <fantasai> khush: so that keeps showing new DOM<br> <fantasai> khush: but see the transitions on top of it<br> <fantasai> smfr: ?????<br> <fantasai> khush: ....<br> <fantasai> khush: and then we save the hierarchy as well<br> <astearns> s/?????/is the old page content a snapshot?/<br> <astearns> s/..../yes/<br> <smfr> is the old page content a snapshot<br> <fantasai> smfr: so if page content has animation, that will freeze<br> <fantasai> khush: yes<br> <fantasai> khush: new DOM is live, but old DOM is frozen<br> <fantasai> astearns: Suggest putting links to the specific parts of explainer/issue that respond to the things discussed here<br> <fremy> just in general, I think this is a very interesting proposal<br> <fantasai> jensimmons: Also helpful to have resources to explain author experience<br> <fantasai> khush: The explainer takes an example of one page, and has the author CSS that you need to get the transition working. I'll link to that section also<br> <fantasai> astearns: Fine to put Agenda+ either on this meta-issue or adding a new issue, to discuss particular parts of this proposal<br> <fantasai> astearns: would rather do that than doing general discussion again<br> <fantasai> astearns: Thanks very much for presentation, very cool stuff.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6464#issuecomment-988985028 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 8 December 2021 16:46:56 UTC