- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Mar 2023 16:03:32 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-1] UA CSS should size ::view-transition to 0x0`, and agreed to the following: * `RESOLVED: The view transition fills the viewport and captures clicks` <details><summary>The full IRC log of that discussion</summary> <fantasai> s/Topic/Subtopic/<br> <JakeA> https://github.com/w3c/csswg-drafts/issues/8278#issuecomment-1460153943<br> <emeyer> JakeA: Trying to decide default styles for the main pseudo-element<br> <emeyer> …It currently fills the snapshot root<br> <emeyer> …Use case one: rootless transitions<br> <emeyer> …By default we giive a name of root, but authors could change it to none<br> <emeyer> …Now when the transition runs, only components will be involved, but you can see the document beneath<br> <emeyer> …This is like a scoped transition, but it’s not quite a scoped transition<br> <emeyer> …I feel like this is rare and it will be more rare when we ship scoped transitions<br> <emeyer> Use case two: animating a view transition container and expecting it to move everything inside<br> <emeyer> Use case three: If you move your root view away, you might want to create a background for the rest of the area<br> <emeyer> Use case four: transitioning relative to the viewport<br> <emeyer> …We always go from top left, but in custom cases you might do something different<br> <emeyer> …I’ve done transitions to the center or bottom of the viewport<br> <emeyer> …So, the question is, what styles to give this by default.<br> <emeyer> …Option 1. It fills the viewport, which is great in all but the rootless use case<br> <emeyer> …Option 2. we do pointer-event: none to the transition and p-e: auto to the parts of the transition, so you can click the real DOM<br> <emeyer> …This is great except in cases where you fill in an opaque background; clicks will go through it<br> <emeyer> …Option 3: Make the transition element 0x0 in the top left, which breaks the ability to fill in the background<br> <emeyer> …Also break cases where you’re trying to position relative to places other than top left<br> <emeyer> …This feels like making the common things hard<br> <TabAtkins> q+<br> <emeyer> …I think we’re in favor of option 1<br> <flackr> q+<br> <astearns> ack TabAtkins<br> <emeyer> TabAtkins: I agree, I think option 1 is the right idea and is least restrictive, also fails in a way that’s safer than the other options<br> <astearns> ack fantasai<br> <astearns> ack flackr<br> <astearns> q+ fantasai<br> <emeyer> flackr: I’m good with 1 or 3; 2 could override authors setting pointer-event on child elements<br> <emeyer> …We should add as few enforced UA styles as possible<br> <astearns> ack fantasai<br> <emeyer> fantasai: Conclusion seems fine; have slight concern that positioning default is top left, rather than being writing-mode dependent<br> <emeyer> khush: That’s correct, spec says to place but doesn’t say how to compute<br> <emeyer> JakeA: I understand the writing mode concerns, but this should result in the same effect in the default case<br> <emeyer> fantasai: Should look into whether there are things that compete differently<br> <emeyer> astearns: We should have a separate issue about writing mode being considered<br> <emeyer> khush: We did have that, but then made it relative to the center of the containing block<br> <emeyer> …I’ll reopen that issue so we can get things into the spec<br> <emeyer> astearns: Sounds like we’re converging on option 1<br> <khush> +1 to this proposal<br> <fantasai> s/compete/compute/<br> <emeyer> RESOLVED: The view transition fills the viewport and captures clicks<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8278#issuecomment-1470313885 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 March 2023 16:03:34 UTC