- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 13 Feb 2024 19:48:49 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor-position-1] Allow more properties in position fallbacks`, and agreed to the following: * `RESOLVED: Remove border/padding.` <details><summary>The full IRC log of that discussion</summary> <emilio> TabAtkins: we have some spec for properties allowed to be set in @position-try / auto-flipped by the automatic keywords<br> <emilio> ... previous resolution we added margin/border/padding<br> <emilio> ... the internal properties are more problematic than expected<br> <florian> q?<br> <florian> q+<br> <emilio> ... current proposal reflected in the ED is to only accept insets (including inset-area) / margin / sizing and self-alignment properties<br> <astearns> ack florian<br> <emilio> florian: the removal of border-padding makes sense if we can solve it through some other system<br> <emilio> ... such as something like container queries<br> <emilio> ... seems plausible that this should work<br> <emilio> TabAtkins: we're only removing it through implementation difficulty issues<br> <astearns> ack fantasai<br> <emilio> ... so we can revise<br> <emilio> fantasai: any property in the position fallbacks are risky because they don't play with the cascade properly<br> <emilio> ... the anchor positioning styling will override everything<br> <emilio> ... including in the more important layer<br> <emilio> ... it's important to limit the properties that fit in the position try blocks<br> <emilio> ... any other kind of styling needs to happen in some conditional styling system needs to play well with origin / specificity / etc<br> <miriam> q+<br> <emilio> ... I'm fine with these but we should not do the conditional styling<br> <astearns> ack miriam<br> <emilio> ... the more you can shift into that the better because it cascade properly<br> <emilio> s/cascade/cascades/<br> <emilio> miriam: these properties don't change the result you get<br> <emilio> ... when you choose what try block to use is not based on what layout to use right?<br> <emilio> TabAtkins: it is, it is based on whether you overflow with those<br> <emilio> miriam: ah, so you can't just put them in queries<br> <emilio> darn<br> <emilio> florian: anchor-default is not in this list, why?<br> <emilio> TabAtkins: I think it should be into the list<br> <emilio> astearns: separate issue?<br> <emilio> TabAtkins: that's fine<br> <emilio> dholbert: following up, @position-try order evaluation is independent<br> <emilio> ... to the sizing properties etc<br> <emilio> TabAtkins: you don't need to layout the elements but you need to know the inset properties<br> <dholbert> s/@position-try order/position-try-order: [...]/<br> <emilio> RESOLVED: Remove border/padding.<br> <dholbert> s/inset properties/inset properties in order to determine the inset-modified containing block/ (in what Tab said)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9195#issuecomment-1942297101 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 13 February 2024 19:48:52 UTC