- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 30 Jul 2025 17:00:47 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor-position][other] Handling popover default styles`. <details><summary>The full IRC log of that discussion</summary> <Rossen2> https://github.com/w3c/csswg-drafts/issues/10258#issuecomment-3099281092<br> <ydaniv> TabAtkins: dialogs and popovers in default UA stylesheet are positioned in screen-centered ways<br> <ydaniv> ... this is done by using auto margins to cause centering, it's reasonable<br> <ydaniv> ... we want popovers to be usable with anchor positioning<br> <ydaniv> ... so ideally you should be able to set position-area and it works<br> <ydaniv> ... but default UA styles with non AP doesn't allow it<br> <ydaniv> ... has some interfernse here<br> <ydaniv> ... confuses everyone<br> <ydaniv> ... fantasai and I worked on a solution here, a new KW for this case, based on whether you're using anchor positioning or not<br> <lea> q+<br> <fantasai> To clarify: new keyword for the alignment properties<br> <fantasai> see https://github.com/w3c/csswg-drafts/issues/10258#issuecomment-3099281092<br> <ydaniv> ... if you're not centers you, and if you are using AP it acts like normal, which acts like a proper direction<br> <ydaniv> ... AFAWCT it should reproduce anchor positioning behavior correctly, and you just need to set poition-area<br> <iank_> q+<br> <ydaniv> ... masonf said it SGTM<br> <kizu> q+<br> <masonf> +1 the defaults are a footgun<br> <ydaniv> ... ntim had a concern with naming<br> <ydaniv> ... I think it's probably ok, but open to suggestions<br> <lea> lea: A margin keyword seems very overfit to me. Lots of use cases for branching styling based on whether the element is anchored or not, that cannot be done via the anchor() fallback. What about a new boolean `<condition>` that can be used in `if()` and `@container`?<br> <Rossen2> ack lea<br> <ydaniv> lea: new margin KW sounds wierd to me<br> <fantasai> It's not a margin keyword<br> <ydaniv> ... we current have the function fallback but can do everything via that<br> <ydaniv> ... maybe a new bool condition in there, to tell you whether element is anchored or not<br> <ydaniv> TabAtkins: won't work, we can't rely on outside info here<br> <ydaniv> ... it's about whether if you're using AP or not<br> <ydaniv> fantasai: it's not a margin KW it's a KW on the alignment properties<br> <Rossen2> q<br> <ydaniv> lea: it says why it's not a good idea, but still have concerns with overfitting<br> <ydaniv> TabAtkins: agree, let's make it work somehow, this trips everybody<br> <ydaniv> ... also think that this isn't an unreasonable for things that aren't dialog in general<br> <chrishtr> +1 to strong evidence that it's confusing a lot of people. I've heard this confusion many times now<br> <ydaniv> lea: I completely agree we need to solve this<br> <ydaniv> ... just about direction<br> <Rossen2> ack iank_<br> <miriam> q+<br> <ydaniv> iank_: I'm a little bit worried about compat here<br> <ydaniv> ... even when we first changed it to center, when we didn't have alignment KW, we ran into compat problems<br> <lea> q+<br> <ydaniv> ... it's a gut feeling this will be problematic, maybe introduce a new property?<br> <ydaniv> ... or another syntax to ignore margins?<br> <miriam> q-<br> <ydaniv> TabAtkins: trying to avoid a simple behavior switch, those are not great design<br> <ydaniv> ... I think it might be not web compat<br> <ydaniv> ... that's the best design we've come by so far<br> <ydaniv> ... if you're not screwing with margin behavior too much this will work and preserve right behavior<br> <ydaniv> iank_: don't know<br> <ydaniv> TabAtkins: there are good and bad paths based on what you're doing<br> <ydaniv> iank_: people use dialogs in all sorts of ways<br> <ydaniv> ... worried...<br> <ydaniv> ... ppl set alignment properties, would like to try another solution<br> <ydaniv> TabAtkins: I suspect some of directions you suggest would be just as bad<br> <ydaniv> iank_: maybe<br> <ydaniv> ... a lot of devs feel like the align properties should feel like auto margins<br> <Rossen2> ack kizu<br> <ydaniv> kizu: a few things about naming, for popover it would be better, when you anchor it starts doing what it should<br> <ydaniv> ... q is how do we determine it? is it when there something in the insets?<br> <ydaniv> ... also think there's a second problem with try options<br> <ydaniv> ... very often you position something, you click on it and it's not there<br> <ydaniv> ... right now to replicate common libraries you need to do a lot<br> <ydaniv> ... so we should have a solution for ppl to not care about it<br> <ydaniv> TabAtkins: so naming for popover over dialog, you need to set <missed><br> <ydaniv> ... you also have to reset margin auto to 0<br> <ydaniv> ... second, when you use position area<br> <ydaniv> ... we probably want to expand the definion to different things, will expand on separate issue<br> <lea> lea: I think my main issue is that this is a conditional value which hardcodes the condition and the value so they can neither be customized, nor repurposed to branch off other styles/properties. E.g. a library may want to apply different container styles for anchorless "floating" popovers vs anchored ones. If later we or authors want to vary different styles we have to pile more API surface on. Even if the condition is not around anchored vs<br> <lea> non-anchored I wonder if there might be _some_ type of `<condition>` we can use. Even if the condition itself is overfit to this problem, at least that decouples it from the property and value that is being branched.<br> <ydaniv> ... also third issue, separate<br> <ydaniv> lea: if down the line we want to branch off in a different way we'll need to introduce new stuff<br> <ydaniv> ... so wonder id my proposed condition won't work, <missed><br> <ydaniv> TabAtkins: the condition we're worrying about is not whether you're using it or not<br> <iank_> (because position-area is high priority we could coerce margins to zero at that stage)<br> <ydaniv> ... we can't style based on other styles<br> <ydaniv> lea: both features work around it by IACVT<br> <fantasai> iank_, that could maybe work... I wonder if it would be better to do that to a new margin keyword so 'auto' behaves as expected otherwise? But maybe it's not worth it.<br> <ydaniv> TabAtkins: can we move back to issue?<br> <ydaniv> Rossen2: we are at time<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10258#issuecomment-3137154104 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 30 July 2025 17:00:47 UTC