- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 16 Sep 2022 00:47:38 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Pseudo-element Selectors for shared element transitions`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Subtopic: Pseudo-element Selectors for shared element transitions<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7743<br> <fantasai> JakeA: what you see here is the default cross-fade<br> <fantasai> ... DOM change underneath is just one change<br> <fantasai> ... illusion of both bits of content on the screen at the same time is done through this pseudo-element<br> <fantasai> ... tree<br> <fantasai> ... These represent the two visual states<br> <fantasai> ... there's a wrapper around them, which applies isolation<br> <fantasai> ... and container there is what changes size and position<br> <fantasai> ... (not seen for root, but for sub-elements will see it)<br> <fantasai> JakeA: Developers can use these pseudo-elements to customize their stuff<br> <fantasai> ... e.g. change from cross-fade to sliding images from left to right<br> <fantasai> ... also have this page-transition-tag property<br> <fantasai> s/... also/JakeA: also<br> <fantasai> ... allows to capture page in separate parts, animate separately<br> <fantasai> ... so page slides and heading text cross-fades<br> <fantasai> JakeA: This creates a bigger pseudo-tree<br> <fantasai> ... each piece gets its own ::page-transition-container<br> <fantasai> ... and underneath it a wrapper around the two incoming/outgoing images<br> <fantasai> JakeA: Although it's a pseudo-tree, currently attached to root element<br> <fantasai> ... feels like cheating, because it doesn't really represent the structure of the pseudo-tree<br> <fantasai> ... but alternative would be [writes out a chain of pseudo-elements]<br> <fantasai> ... It's uncomfortable even with shortened names<br> <fantasai> JakeA: Tab came up with idea of using a pseudo-descendant combinator<br> <fantasai> JakeA: one question to group is, would it be appropriate to do something with function-liek syntax can be used on each piece of it<br> <fantasai> ... html :>> outgoing-image(header-text)<br> <fantasai> JakeA: I like this because it makes use of nesting<br> <fantasai> ... makes syntax simpler and nicer<br> <fantasai> JakeA: one alternative suggested to structure is what if we used shadow DOM instead<br> <fantasai> ... here we've got a shadow-root<br> <fantasai> ... and it's got basically same structure, using parts attribute for access into the tree<br> <fantasai> emilio: Bigger pro is, you avoid all this nested pseudo-elements for a particular feature<br> <fantasai> ... also a lot of new features are using shadow parts<br> <fantasai> ... I don't think of a use case that, well, shadow DOM is already restricted on root eleent<br> <fantasai> ... so can use it for UA features<br> <fantasai> ... if you replae with script the HTML element with something else, some of it wouldn't work<br> <fantasai> ... but all in all, it seems a bit better to re-use what the platform already has<br> <fantasai> ... I don't think there's anything that you can't do with pseudo-elements that you can't do with parts<br> <fantasai> JakeA: syntax of using parts, haven't seen for shipped feature yet<br> <fantasai> ... but we're happy with it?<br> <fantasai> emilio: THat's where all the new OpenUI stuff is going<br> <fantasai> ... I think it's reasonable<br> <fantasai> ... I'd rather do that than having 4 nested pseudo-elements<br> <fantasai> JakeA: I'd seen that in their proposal, unsure about feelings in this group<br> <fantasai> emilio: Tab designed parts so that authors and UA could have common mechanism to expose this kind of thing<br> <heycam> q+<br> <fantasai> TabAtkins: wasn't designed with intent of UA using it, but it was left open as a possibility<br> <khush> q+<br> <chrishtr> q+<br> <fantasai> JakeA: One of the things missing right now is ability drive animations with JS<br> <fantasai> ... or call things like getBoundingClientRect() on these things<br> <fantasai> ... and so our plan was, there was a stub bit of spec in the CSS Pseudo-element Spec to say maybe we'll expose these to JS at some point<br> <fantasai> ... but if we had a shadow root, we could just give devs access to the elements<br> <fantasai> ... and not do all that<br> <fantasai> emilio: That seems a bit trickier, in the sense that some of these elements, if I understand correctly, need some magic attached to them<br> <fantasai> ... rendering a texture that [missed]<br> <fantasai> ... not supposed to be moved around<br> <fantasai> ... so seems a bit tricky, fact that you can shuffle them around etc.<br> <heycam> s/[missed]/the compositor has taken a snapshot of/<br> <fantasai> JakeA: definitely don't want devs to take the elements out of the shadow root and have them continue to work<br> <fantasai> ... but can explain that if extracted the element, no longer...<br> <fantasai> emilio: nice thing about shadow parts, is also used elsewhere<br> <emilio> q+<br> <Rossen_> ack heycam<br> <fantasai> heycam: One thought about shadow root, gievn HTML element can't have one currently<br> <fantasai> ... could mechanism be that some new element is created which has this shadow tree structure, and placed in top layer<br> <fantasai> ... not attached to the root element<br> <fantasai> ... don't know where it would live in the document<br> <fantasai> JakeA: I floated a similar idea earlier<br> <fantasai> ... but your idea is simpler<br> <Rossen_> ack khush<br> <fantasai> khush: I had a thought, curious to get a bit more understanding about heycam was proposing<br> <fantasai> ... were you proposing a new tag that lives somewhere in the DOM that only exists to host a shadow root?<br> <fantasai> heycam: thinking that when the element transition is triggered, that would cause a new element to be inserted into the document<br> <fantasai> ... which has this structure behind it<br> <fantasai> ... its only purpose is to render the transition image, and it lives in the DOM<br> <fantasai> khush: idk what computations would run into... would be a shared-element-transition tag?<br> <fantasai> ... generally does UA create elements that have a temporary lifetime, and is node inserted by browser<br> <fantasai> ... was trying that we create pseudo-element, but ran into multiple issues because don't expect real DOM elements to have pseudo-elements as their ancestors<br> <fantasai> heycam: it just feels like it's not really part of the root HTML element either<br> <fantasai> JakeA: it's a "topper layer"<br> <fantasai> khush: One reason it has lin kto document is so that it has a way to do style resolution and layout<br> <fantasai> ... it needs a document to be associated with<br> <miriam> q+<br> <fantasai> ... otherwise it's using output of actual document to generate content<br> <fantasai> khush: Wanted to add, might be a weak arguemnt because need to be more clear<br> <fantasai> ... but one use case is multiple independent transitions on the page<br> <fantasai> ... currently it's global, works for the whole document, captures the entire page<br> <fantasai> ... but some cases where a developer can have 2 widgets on their page<br> <fantasai> ... 2 different DOM subtrees, would be nice to transitions on those subtrees independently<br> <fantasai> ... if shadow tree, can scope to each subtree<br> <fantasai> ... attach to root of that subtree<br> <fantasai> ... so using shadow DOM on the root for this<br> <fantasai> ... would not be able to do that on subtrees<br> <Rossen_> ack chrishtr<br> <fantasai> ... because only HTML can have this work<br> <fantasai> s/HTML/HTML element/<br> <fantasai> ... but using pseudo-elements, can expand in that direction<br> <fantasai> chrishtr: Question is what can authors use to style these elements<br> <fantasai> ... one is using pseudo-element syntax<br> <fantasai> ... or use shadow DOM syntax<br> <fantasai> ... not necessary to ???<br> <fantasai> chrishtr: so that's the choice: is there a pseudo-element or not, and if not it's implementation detail<br> <fantasai> ... maybe something exposed to devs in the future<br> <fantasai> ... need to think about what choice we make, how it impacts that<br> <fantasai> ... but it's really choice of syntax A or B<br> <fantasai> ... and 2 dimensions to weigh are, which has better ergonomics for devs<br> <fantasai> ... and which is easier to implement for implementers<br> <fantasai> emilio: My concern was not so much about difficult, but pseudo-elements, there are a lot of them<br> <fantasai> ... new names specific to this feature<br> <fantasai> ... to me feels we should avoid it<br> <fantasai> chrishtr: by analogy, components in OpenUI have a parts syntax on them, but doesn't mean can access the elements. Closed shadow DOM<br> <fantasai> ... web-components-like syntax<br> <heycam> q+<br> <fantasai> ... afaict, some devs are used to pseudo-elements<br> <fantasai> ... find the one they need and put it in their stylesheet<br> <fantasai> ... others that know about components might think ::parts one makes more sense<br> <fantasai> ... Further down can explain with conceptual shadow DOM<br> <fantasai> ... but to me it's really about that tradeoff<br> <fantasai> ... even if we expose shadow DOM<br> <JakeA> q+<br> <fantasai> ... there are UA features that are [missed]<br> <fantasai> ... I think you mentioned <input> as an example<br> <Rossen_> ack emilio<br> <fantasai> emilio: To that regard, my point for using parts is<br> <fantasai> ... if you need to learn one of these things<br> <fantasai> ... shadow parts is something you'll learn once, and it'll be useful every time you use it<br> <fantasai> ... whether as an author or something else<br> <fantasai> chrishtr: The concept of parts yes, but still have to memorize the names of the parts<br> <fantasai> chrishtr: I personally don't have a strong opinion<br> <fantasai> ... I feel like the tradeoff should be more about which is easiest for developers<br> <fantasai> khush: Part which has not been clear to me, whether syntax implies shadow DOM or not<br> <fantasai> ... if we go with part syntax, is it still pseudo-elements?<br> <fantasai> ... wasn't clear if this syntax forces us to use a particular approach<br> <Rossen_> ack miriam<br> <fantasai> miriam: As an author, I've interacted with pseudo-elements more<br> <fantasai> ... but when I read the syntax here, the part syntax reads much simpler to me<br> <fantasai> ... it is a pseudo-element, and doesn't require special combinator syntax<br> <fantasai> ... looks cleaner to me, makes sense, I like it<br> <astearns> +1 to miriam<br> <TabAtkins> q+<br> <fantasai> ... I am also one of the ppl who will feel strongly about having multiple sub<br> <fantasai> ... don't want to take an approach that makes that impossible<br> <fantasai> s/sub/subtree<br> <emilio> q+<br> <fantasai> chrishtr: important your point that we don't need additoinal syntax for pseudo-element trees<br> <fantasai> JakeA: if we use the part syntax, you will not get nesting<br> <fantasai> miriam: will I need it?<br> <fantasai> fantasai: You had that proposal about nesting<br> <fantasai> JakeA: could maybe put more classes in the part<br> <fantasai> ... but you lose the strucutre this gets you<br> <Rossen_> ack heycam<br> <vmpstr> would the part syntax also prevent attaching this structure to an element that has a shadow dom (since part would select the shadow dom?)<br> <fantasai> heycam: proposal is for transitions in the document, but idea is to go later to entire document transitions?<br> <fantasai> JakeA: other way around, right now it's one transition that covers the whole document<br> <fantasai> ... but it's same document transition<br> <fantasai> ... but intention is to go to cross-document transitions in the near future<br> <fantasai> heycam: for cross-document, seems like the shadow DOM mechanism wouldn't be appropraite<br> <fantasai> ... because they would go away when you switch documents<br> <fantasai> ... so can't describe the state across the transition<br> <fantasai> JakeA: it would be the same tree that we would use with pseudo-elements<br> <fantasai> ... screenshots from previous page would be in the shadow DOM of the new document<br> <fantasai> chrishtr: would certainly require special code<br> <fantasai> JakeA: would only be same-origin, btw<br> <fantasai> heycam: all the pseudo-elements, need to live in both old and new document<br> <fantasai> JakeA: only new one<br> <fantasai> fremy: you take a photo of old document, and then swithc to new one<br> <fantasai> ... only one document active<br> <fantasai> heycam: so in old document, no pseudos get created<br> <fantasai> fremy: right<br> <fantasai> chrishtr: but during animation, new document is inert<br> <Rossen_> ack JakeA<br> <fantasai> JakeA: One thing I'm worried about is, we want devs to have references to things they can call getBoundingClientREct, to control inline styles<br> <fantasai> ... to increase the proposal for a reference to a pseudo-element and put these on them<br> <fantasai> ... add .animate, .style<br> <fantasai> ... I'm slightly worried we get trouble if using parts, because getting pseudo-eelemnt reference for something that is an element<br> <fantasai> heycam: animations?<br> <fantasai> JakeA: .style.whatever<br> <fantasai> ... if we create pseudo-element object, will it make sense if the underlying thing is an actual element?<br> <fantasai> heycam: internally, this kind of thing will be ....<br> <fantasai> ... more a matter of making sure API exposes the right things<br> <Rossen_> ack TabAtkins<br> <fantasai> TabAtkins: A little bit ago, Miriam said she preferred look of the parts API, more simple naming<br> <fantasai> ... I'll note that if that's what we care about, we can do that with pseudo-elements, too<br> <fantasai> ... if that's a significant plus, we can make the tarnsition API work like that with pseudo-element sor with parts<br> <fantasai> ... we don't ahve to bring one or the other based on that specific issue<br> <fantasai> JakeA: current API in canary is simlilar, everything hangs off root eleent<br> <fantasai> ... change something like this to ::part() with same text inside<br> <fantasai> ... here we've put page-transition to separate from other features<br> <fantasai> ... would need to do same with aprt syntax<br> <fantasai> ... to crate a namespace for our feature<br> <fantasai> s/crate/create/<br> <TabAtkins> ahhhh<br> <fantasai> emilio: regarding .style etc.<br> <Rossen_> ack emilio<br> <fantasai> ... right now I don't think we expose either parts or pseudo-elements as things you can change style of<br> <fantasai> ... but if we did, I thin you'd get more chances for that with parts than pseudo-elements<br> <fantasai> ... because pseudos don't have attributes<br> <fantasai> ... not all speudos can have attributes<br> <heycam> fantasai: trying to think through how much of this is feeling awkward because it's really long, or how much because of the structure of it<br> <heycam> ... if there's way to use pseudo element syntax that's more compact, maybe then it would feel more comfortable<br> <emilio> q+<br> <fantasai> fantasai: also wrt khush's point about subtrees, I think leaving that possibility open is important<br> <heycam> khush: I think the conclusion I'm hearing is to go with part for now, which leaves it open for each engine to decide, whether it's backed with pseudos or shadow DOM, and when we hit implementation, we decide at that point<br> <vmpstr> q+<br> <fantasai> JakeA: I tihnk we need to write up both proposals possible<br> <emeyer> A question: Will it be possible for cross-document transitions to also animate shared elements? (Similar to Magic Move in Keynote, where an element can scale and move and change opacity as part of the slide transition.) If not, should we design syntax such that it could be possible in the future?<br> <fantasai> ... used shorter syntax for parts examples, but in reality would need to be longer<br> <fantasai> emeyer, yes<br> <Rossen_> ack emilio<br> <fantasai> emeyer: I think maybe ??? is a non-issue with parts<br> <fantasai> s/emeyer/emilio/<br> <fantasai> ... because doesn't interact with rest of page<br> <fantasai> emilio: if we go with parts, most realistic way to implement is using shadow DOM<br> <Rossen_> ack vmpstr<br> <fantasai> vmpstr: if we go with the part syntax, wouldn't that still run into issue of backed by pseudo-element but scoped to an element that has a shadow DOM attached by developer<br> <emilio> s/???/animations in ua sheets<br> <fantasai> ... wouldn't part syntax then be ambiguous?<br> <fantasai> JakeA: are you talking about a scoped transition?<br> <fantasai> vmpstr: yes<br> <fantasai> JakeA: yeah that's a big issue<br> <emilio> q+<br> <fantasai> vmpstr: unclear whether to look in shadow DOM or pseudo-tree<br> <fantasai> emilio: it's true<br> <Rossen_> ack emilio<br> <fantasai> ... but to be honest, this scoped transition thing raises more questions than answers<br> <fantasai> ... be good to have a concrete proposal of how that would look like<br> <fantasai> ... before deciding to use or not use one approach<br> <fantasai> ... at the point where root of transition can mutate<br> <fantasai> ... right now proposla is only for docuemnt transition. You know document is not going away<br> <fantasai> ... various things not changing<br> <fantasai> ... if you scope the transition to the element, need to define what happens when authors hide or move the element<br> <fantasai> ... or whatnot<br> <fantasai> ... raises a lot more complications than I'm comfortable with<br> <fantasai> Rossen_: I want to see if we can close the discussion<br> <fantasai> Rossen_: quite a bit of feedback here, what should we do next?<br> <fantasai> JakeA: I think our action items are to draw up pros and cons of each approach, and maybe also mid-approach where implemented with shadow DOM but use pseudo-elements to access it<br> <fantasai> ... and sketch out scoped transitoins to figure out how it works<br> <fantasai> TabAtkins: coming up with half-reasonable short names with each would also be helpful<br> <fantasai> ACTION: JakeA and khush to draw up pros and cons for shadow DOM vs pseudo-elements vs mixed approaches<br> <astearns> so I am dreading s/transition-container/trainer/<br> <fantasai> ACTION: JakeA and khush to sketch out scoped transitions to see how they work<br> <fantasai> ACTIOn: JakeA and khush to find shorter names for things<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7743#issuecomment-1248794015 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 16 September 2022 00:47:40 UTC