- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 21 Aug 2025 09:37:44 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor-position][other] Handling popover default styles`, and agreed to the following:
* `RESOLVED: Add 'dialog' value for align/justify-self, behaving as normal or center as appropriate, and rewrite [popover] UA styles per https://github.com/w3c/csswg-drafts/issues/10258#issuecomment-3099281092`
<details><summary>The full IRC log of that discussion</summary>
<ydaniv> TabAtkins: quick intro, popovers and dialogs in general have some default styling that centers them<br>
<ydaniv> ... in both they're positioned elements and uses auto margins to do the centering<br>
<ydaniv> ... this is not consistent when you need to have anchor pos<br>
<ydaniv> ... and you should be able to easily use anchor positioning<br>
<ydaniv> ... it trips authors up<br>
<ydaniv> ... so fantasai and I tried to find a solution<br>
<ydaniv> ... we think we have it, adding a new alignment value called dialog, which either centers or acts as "normal"<br>
<ydaniv> ... this lets you overide default stuff from UA<br>
<ydaniv> ... only thing is that you have to use a special keyword which is strange<br>
<fantasai> Tab is summarizing https://github.com/w3c/csswg-drafts/issues/10258#issuecomment-3099281092<br>
<ydaniv> ... use case for it is that it's generic enough for exposing<br>
<ydaniv> ... had a few objections about this, lea had some<br>
<ydaniv> ... we discussed this previously<br>
<ydaniv> ... yesterday iank_ said we could auto coarse margins to 0 if popover uses anchor pos<br>
<ydaniv> ... I really disagree because it's purely magical and canot be done other way<br>
<ydaniv> ... it pevernts authors from setting their own margins<br>
<ydaniv> ... also note that iank_ expresed some concern about compat for changing this<br>
<ydaniv> ... talked about this internally, there's stuff we could do, perhaps ignore compat for now<br>
<ydaniv> ... opening for discussion, hoping we can add the alignment value, this is my preference<br>
<astearns> ack fantasai<br>
<ydaniv> fantasai: one thing about the margin 0-ing, with alignment don't need to fir content if it's auto<br>
<ydaniv> ... but with the margin 0-ing won't work<br>
<ydaniv> s/fir/fit/<br>
<ydaniv> astearns: other comments?<br>
<ydaniv> fantasai: a 3rd option would be to recast the way anchor position area works<br>
<lea> q?<br>
<ydaniv> ... instead of setting the alignment value to something magical, to make margin auto to be something magical<br>
<fantasai> s/margin/inset<br>
<ydaniv> TabAtkins: would prefere to minimize magic as much as possible<br>
<ydaniv> lea: agree<br>
<ydaniv> TabAtkins: we already have some behavior switching, but we already have precedence<br>
<lea> q+<br>
<fantasai> Proposed changes to the UA default stylesheet<br>
<fantasai> [popover] { position: fixed; place-self: dialog; /* new */ /* deleted X inset: 0; X width: fit-content; X height: fit-content; X margin: auto; */ border: solid; padding: 0.25em; overflow: auto; color: CanvasText; background-color: Canvas;<br>
<astearns> ack lea<br>
<fantasai> }<br>
<ydaniv> lea: been a while, we have this conditional branching if you're using anchor pos you have normal, otherwise center<br>
<fantasai> -> https://github.com/w3c/csswg-drafts/issues/10258#issuecomment-3099281092<br>
<ydaniv> ... it's still a black box<br>
<ydaniv> ... could we break out some of the magic? allow in separate properties? maybe special case just for margins?<br>
<ydaniv> TabAtkins: I argued against a general form of that<br>
<lea> s/allow in separate properties? maybe special case just for margins?/e.g. a conditional around whether an element is anchored? Possibly only allowed in margin for now? At least then there is a path for making it more general later, whereas a keyword that encapsulates all the magic has no such path/<br>
<ydaniv> ... just using anchor pos for that is interwoven with other features<br>
<lea> q?<br>
<lea> q+<br>
<ydaniv> ... doing something so core to layout would be a large distinction on how we do it<br>
<ydaniv> ... having a specific keyword for specific case it ok here<br>
<ydaniv> ... a more generic for would make it so complex to where it's possible to use, so may not be worth doing<br>
<astearns> ack fantasai<br>
<ydaniv> fantasai: there's too many things that are affected<br>
<ydaniv> ... don't think there are more use cases<br>
<astearns> ack lea<br>
<ydaniv> ... mostly trying to fix the badly designed defaults, if authors were doing it they wouldn't write this badly<br>
<ydaniv> lea: not suggesting we add new deps. there are solutions that involve different synrtax<br>
<ydaniv> ... this is part of the UA stylesheets, so ergonomics is part of the concern<br>
<TabAtkins> s/is part/is not part/<br>
<ydaniv> ... special casing a syntax that could be come more general<br>
<lea> scribe+<br>
<lea> lea: means we don't have to maintain this magic keyword forever, we have a path to a more general feature for down the line<br>
<emilio> scribe+<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to say we should avoid designing something overcomplicated and overgeneral for a very specific problem<br>
<lea> lea: it's conceivable that authors or the UA stylesheet will want to branch depending on whether an element is anchored<br>
<emilio> fantasai: trying to spend the time effort to define a generic syntax<br>
<emilio> ... is not worth doing<br>
<lea> q+<br>
<emilio> ... not worth doing now that we need this for compat now<br>
<emilio> ... I don't see us generalizing this<br>
<emilio> ... we have one thing for a very niche problem<br>
<lea> lea: in that case, is it possible to restrict this value to the UA stylesheet so we don't have to maintain it forever? It seems of very limited utility to authors<br>
<astearns> ack lea<br>
<emilio> lea: that way later we can swap it in without having to worry about webcompat<br>
<emilio> fantasai: it's a keyword, if we want it to make it compute to something else later we can<br>
<emilio> astearns: might be on lea's side here, is there any problem with restricting it to UA sheet<br>
<lea> q+<br>
<emilio> ... it's a bit harder to implement but seems it'd be better for authors<br>
<emilio> fantasai: I think the easiest way is to compute to normal or center depending on whether you're author positioned?<br>
<emilio> ... not sure how easy to implement would that be<br>
<emilio> ... it's not a complicated behavior tho<br>
<emilio> ... its be centered if you're not anchor positioned otherwise normal<br>
<lea> lea: there are other cases where we want to not expose certain values to authors and only allow them in the UA stylesheet, e.g. allowing authors to set `overlay: none` without setting overlay in general, so having a way to do this seems useful beyond this<br>
<astearns> ack lea<br>
<emilio> ... which itself behaves differently when anchor positioned<br>
<emilio> q+<br>
<astearns> ack emilio<br>
<fantasai> emilio: Lea that's different, because they can set it, it just won't have an effect because it gets by a declaration in the UA !important origin<br>
<TabAtkins> emilio: that's different. authors can set it, it's just overriden by the UA !important rule<br>
<fantasai> emilio: You can set 'overlay: auto', and it'll create a declaration, it just won't have an effect<br>
<emilio> fantasai: I really think we're spending a lot of time trying to overgeneralize here<br>
<emilio> ... this is just trying to fix a very specific problem<br>
<lea> q?<br>
<emilio> ... we're certainly not going to move forward on anchor pos if we can't solve this and we don't get to the other issues<br>
<emilio> TabAtkins: yeah it might also be useful for authors<br>
<emilio> astearns: what's the current proposal<br>
<emilio> TabAtkins: dialog, open to other names<br>
<emilio> astearns: so proposal is to add a dialog value to alignment properties that computes to normal or center<br>
<emilio> emilio: computes or behaves as?<br>
<emilio> astearns: computes does more hiding<br>
<lea> perhaps a better name could improve on how weird and overfit this feels<br>
<fantasai> emilio: How many properties are we talking about here?<br>
<lea> +1 astearns<br>
<emilio> fantasai: align/justify-self and it'd depend on position / position-anchor, and maybe the inset properties<br>
<emilio> TabAtkins: right we have a breakout on what "using anchor positioning" really means<br>
<fantasai> emilio: I think it would be easier to make it behaves as<br>
<fantasai> emilio: that doesn't add lots of inter-property dependencies that we may have trouble with<br>
<fantasai> emilio: If depends on just one property is easy, six can get tangled<br>
<fantasai> astearns: OK, can we resolve to add a 'dialog' value, name tb bikeshed, behaves as 'normal' or 'center' depending on layout mode<br>
<fantasai> astearns: details TBD<br>
<fantasai> fantasai: and use it for [popover] as described in https://github.com/w3c/csswg-drafts/issues/10258#issuecomment-3099281092<br>
<fantasai> RESOLVED: Add 'dialog' value for align/justify-self, behaving as normal or center as appropriate, and rewrite [popover] UA styles per https://github.com/w3c/csswg-drafts/issues/10258#issuecomment-3099281092<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-3209763279 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 21 August 2025 09:37:45 UTC