- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 18 Jul 2023 15:47:12 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-1] top/left vs block-start/inline-start`, and agreed to the following: * `RESOLVED: close no change` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> vmpstr: This is similar to the last<br> <TabAtkins> vmpstr: We're using top/left to position the v-t pseudo. Q is if we shoudl use block/inline-start<br> <TabAtkins> vmpstr: This is, I feel a little more strongly we should use top/left. We're using a transform here and it uses phsyical coordinates, we dont' want to recompute based on writing mode.<br> <TabAtkins> vmpstr: So I again propose closing no change.<br> <TabAtkins> astearns: fantasai was the one arguing against you but she's getting the door for someone<br> <TabAtkins> noamr: I'd say the pseudos are not "really" laid out.<br> <TabAtkins> noamr: In general using margins/etc isn't really common, they don't interact in that way.<br> <TabAtkins> noamr: They're just in the scene graph and positioned with transform, so I think logical props make less sense.<br> <TabAtkins> vmpstr: It's also unclear to me what it means to lay out using one anchor point and then transform using another.<br> <federicobucchi> Federico Bucchi, Apple<br> <TabAtkins> vmpstr: So like suppose you anchor to one of the corners. If you use block/inline insets the corner changes based on writing mode, but then the transform has to change to use that corner as well. That's what we want to avoid.<br> <TabAtkins> fantasai: I'm just trying to think thru the ipmlications if, like, the element is larger...<br> <fantasai> TabAtkins: Since this is positioning, it'll overflow badly anyway<br> <TabAtkins> vmpstr: This is for the group element specifically, too. The replaced elements that actually have an image use logical coordinates, they'll overflow correctly for the writing mode. But the group is just transformed into place, so I'm not sure what it would be overflowing<br> <TabAtkins> khush: I guess the real awkwardness is that transforms are only physical, if we had logical transforms we could use logical position too.<br> <TabAtkins> khush: But for now having one half be logical and the other physical is awkward.<br> <TabAtkins> fantasai: i guess it's probably fine since the box we're positioning is visible, it' snot overflowing. so if we're laying out wrt that it works<br> <TabAtkins> khush: The reference box is the snapshot containing block, basically the viewport.<br> <fantasai> s/positioning/positioning into/<br> <TabAtkins> fantasai: I think it's fine for now, we can fix it in the future if we need.<br> <TabAtkins> astearns: So proposed resolution is to close no change<br> <TabAtkins> RESOLVED: close no change<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8886#issuecomment-1640487455 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 18 July 2023 15:47:14 UTC