16:16:39 <RRSAgent> RRSAgent has joined #css
16:16:43 <RRSAgent> logging to https://www.w3.org/2025/07/30-css-irc
16:16:43 <Zakim> RRSAgent, make logs Public
16:16:44 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:16:46 <Rossen2> q?
16:16:53 <ydaniv> ... it's a bit incossitent for length and not color
16:17:04 <ydaniv> ... not super concerned, but a bit wierd
16:17:14 <Rossen2> present+
16:17:19 <ydaniv> fantasai: emilio do you have an example?
16:17:51 <ydaniv> emilio: like computedStyle.inset from shorthand, you get the computed and serialize
16:17:56 <oriol> I think emilio is talking about https://github.com/w3c/csswg-drafts/issues/11382
16:18:02 <ydaniv> ...  and in text-decoration it's not the inital value
16:18:31 <ydaniv> fantasai:  2 things here: 1. when there are multiple possibilites, then we <missed>
16:19:24 <ydaniv> ... then we keep the first grammar term and skip the others
16:19:52 <ydaniv> ... 2. there are some cases where the initial value, ommitable, is not the resolved value because it's further computed than the actual one
16:20:07 <ydaniv> ...  so do we still omit it? is it still omittable?
16:20:41 <lea> q?
16:20:43 <ydaniv> ... I think for colors it's nicer to omit them, when it's an initial value
16:21:03 <ydaniv> ... I think it makes sense to follow the example oriol mentioned
16:21:13 <ydaniv> ... I think to adopt it as a principle
16:21:32 <ydaniv> ... I think we want to audit it, to make sure we don't make special exceptions
16:21:49 <ydaniv> ... I don't know if following this rule will get us into backward compat issue
16:22:10 <ydaniv> ... for text-decoration we should resolve that, to omit text-decoration-color
16:22:28 <ydaniv> Rossen2: last sentence was clear (:
16:22:34 <fantasai> s/compat issue/compat issue for older shorthands, e.g. background/
16:22:49 <ydaniv> lea: so what is the proposal?
16:23:23 <ntim> ntim has joined #css
16:23:23 <diekus> diekus has joined #css
16:23:24 <ydaniv> fantasai: when text-decoration-color is currentColor it's omitted in favour of text-decoration-line
16:23:30 <florian> +1
16:23:32 <ntim> p+
16:23:34 <lea> +1
16:23:59 <ydaniv> lea: assuming it's entirely about the shorthand, and longhand would yield computed?
16:24:02 <ydaniv> fantasai: yes
16:24:12 <ydaniv> lea: would it roundtrip correctly?
16:24:18 <ydaniv> fantasai: <missed>
16:24:33 <ydaniv> lea: there are some wierdness around :visited, right?
16:24:41 <ydaniv> fantasai: won't talk about that
16:24:51 <lea> yeah, strong +1
16:24:52 <ydaniv> Rossen2: seeing +1's starting to add up
16:24:55 <fantasai> s/<missed>/it'll round-trip better than with the behavior of serializing out the resolved color/
16:25:12 <oriol> q+
16:25:20 <masonf> present+
16:25:22 <Rossen2> ack oriol
16:25:24 <fantasai> The case where the behavior differs is if you tweak 'color' in the middle of the round trip
16:25:34 <ntim> present+
16:25:40 <ntim> (not sure if p+ is right)
16:26:04 <ydaniv> oriol: small point, proposed text, that if t-d-line is set to initial value, but t-d-style is set to value other than initial then it could be -style, right?
16:26:08 <ydaniv> fantasai: correct
16:26:17 <fantasai> This is a good clarification
16:26:22 <ydaniv> Rossen2: can we get a resolution?
16:26:41 <ydaniv> florian: more about the generalization stuff
16:26:47 <ydaniv> ... we should resolve
16:26:51 <ydaniv> Rossen2: any objections?
16:27:45 <ydaniv> florian: there is text, but the generalized one is awkward
16:28:02 <ydaniv> ... in this case it's in grammar order, but do we want to be specific? or generalize?
16:28:12 <ydaniv> fantasai: to make t-d we need to generalize
16:28:41 <ydaniv> ... we need to make sure that it's backwards compat, when there are multiple ones, we pick the first one in the specified order
16:28:58 <ntim> (web compat is relevant here since Safari doesn't ship the proper shorthand so far)
16:29:09 <ydaniv> ...  a computed value of currentColor that is the initial value <missed>
16:29:38 <fantasai> PROPOSED: If multiple values are omittable in serialization, but at least one is required, choose the first one in grammar order unless constrained by compat.
16:30:18 <ydaniv> Rossen2: any objections?
16:30:31 <ydaniv> ... hearing non
16:30:40 <ydaniv> s/non/none/
16:30:43 <fantasai> PROPOSED: If a <color> value is omittable when computed to currentColor, then it is omittable even though the resolved value is not the 'currentColor' keyword (because colors are absolutized), unless constrained by compat.
16:30:53 <fantasai> RESOLVED: If multiple values are omittable in serialization, but at least one is required, choose the first one in grammar order unless constrained by compat.
16:31:13 <florian> +1
16:31:28 <ydaniv> Rossen2: anything else on this one?
16:31:36 <ydaniv> ... moving on
16:31:37 <fantasai> RESOLVED: If a <color> value is omittable when computed to currentColor, then it is omittable even though the resolved value is not the 'currentColor' keyword (because colors are absolutized), unless constrained by compat.
16:32:09 <ydaniv> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12512
16:32:09 <github-bot> Topic: [css-anchor-position-1] More intuitive alignment defaults when using one-sided insets
16:32:09 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12512.
16:32:39 <ydaniv> TabAtkins: we know old absolute positioning works
16:33:17 <ydaniv> ... single length made it act as if your specified you're hanged, and added some magic
16:33:25 <ydaniv> ... we no longer resolve auto's
16:33:32 <ydaniv> ...  with anchor positioning
16:33:41 <fantasai> They resolve to zero, rather than to remaining space
16:33:47 <ydaniv> ... if you were using that old magic, it's now broken
16:34:00 <ydaniv> ... you'll get shrunk
16:34:22 <javierct> javierct has joined #css
16:34:48 <ydaniv> ... fantasai suggested we restore that using the normal alignment keyword, so if you're doing normal alignment
16:34:54 <ydaniv> ...  it will restore the old behavior
16:35:09 <iank_> q+
16:35:21 <ydaniv> ... my opinion, don't care much, only that it works physical and logical
16:35:46 <ydaniv> ... so having normal handle this is fine, iank_ is also fine with this, happy to accept
16:35:50 <miriam> +1
16:35:58 <Rossen2> ack iank_
16:36:34 <ydaniv> iank_: had one thought, that alternate solution is to only coarce, if insets are 0, so if you set one inset it will stick to the ege
16:36:39 <ydaniv> s/ege/edge/
16:36:49 <ydaniv> TabAtkins: that would be directly restoring the old behavior
16:37:09 <ydaniv> ...  that means that everything anchor related won't work, would like to retain 0's behavior
16:37:30 <ydaniv> ... because your contain block fits inside you can't rely on containing block calcs
16:37:37 <ydaniv> iank_: fair enough
16:38:29 <ydaniv> TabAtkins: this is related to other topic, we would like to preserve  the ability to override things
16:38:48 <ydaniv> iank_: I don't like the difference between 1 and 2 values specified
16:39:11 <ydaniv> ...  I don't like the fact that if you don't specify position-area you get one behavior, and otherwise a different one
16:39:17 <ydaniv> ... but maybe that's fine
16:39:47 <ydaniv> fantasai: we could consider making the alignment work similar to inset, resovle to 0
16:40:12 <ydaniv> iank_: we had compat concerns here
16:40:25 <ydaniv> Rossen2: sounds like we have a proposal, anything else?
16:40:30 <TabAtkins> Tho this restores the *visible behavior* to be similar between position-area:none and not-none
16:40:38 <TabAtkins> it just changes the way some keywords resolve
16:41:06 <fantasai> PROPOSED: When only one auto inset, 'normal' alignment with position-area resolves to the alignment that attaches to the non-auto edge.
16:41:18 <ydaniv> TabAtkins: yes, correct
16:41:26 <ydaniv> Rossen2: objections?
16:41:31 <fantasai> RESOLVED: When only one auto inset, 'normal' alignment with position-area resolves to the alignment that attaches to the non-auto edge.
16:41:49 <ydaniv> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10258
16:41:49 <github-bot> Topic: [css-anchor-position][other] Handling popover default styles
16:41:49 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10258.
16:42:04 <Rossen2> https://github.com/w3c/csswg-drafts/issues/10258#issuecomment-3099281092
16:42:15 <ydaniv> TabAtkins: dialogs and popovers in default UA stylesheet are positioned in screen-centered ways
16:42:38 <ydaniv> ... this is done by using auto margins to cause centering, it's reasonable
16:42:49 <ydaniv> ... we want popovers to be usable with anchor positioning
16:42:59 <ydaniv> ...  so ideally you should be able to set position-area and it works
16:43:15 <ydaniv> ... but default UA styles with non AP doesn't allow it
16:43:26 <ydaniv> ... has some interfernse here
16:43:35 <ydaniv> ... confuses everyone
16:44:06 <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
16:44:24 <lea> q+
16:44:32 <fantasai> To clarify: new keyword for the alignment properties
16:44:35 <fantasai> see https://github.com/w3c/csswg-drafts/issues/10258#issuecomment-3099281092
16:44:46 <ydaniv> ... if you're not centers you, and if you are using AP it acts like normal, which acts like a proper direction
16:45:15 <ydaniv> ... AFAWCT it should reproduce anchor positioning behavior correctly, and you just need to set poition-area
16:45:19 <iank_> q+
16:45:24 <ydaniv> ... masonf said it SGTM
16:45:28 <kizu> q+
16:45:29 <masonf> +1 the defaults are a footgun
16:45:36 <ydaniv> ... ntim had a concern with naming
16:45:51 <ydaniv> ... I think it's probably ok, but open to suggestions
16:45:57 <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`?
16:46:00 <Rossen2> ack lea
16:46:11 <ydaniv> lea: new margin KW sounds wierd to me
16:46:15 <fantasai> It's not a margin keyword
16:46:26 <ydaniv> ... we current have the function fallback but can do everything via that
16:46:42 <ydaniv> ... maybe a new bool condition in there, to tell you whether element is anchored or not
16:46:53 <ydaniv> TabAtkins:  won't work, we can't rely on outside info here
16:47:05 <ydaniv> ...  it's about whether if you're using AP or not
16:47:29 <ydaniv> fantasai: it's not a margin KW it's a KW on the alignment properties
16:47:44 <Rossen2> q
16:48:01 <ydaniv> lea: it  says why it's not a good idea, but still have concerns with overfitting
16:48:14 <ydaniv> TabAtkins: agree, let's make it work somehow, this trips everybody
16:48:31 <ydaniv> ... also think that this isn't an unreasonable for things that aren't dialog in general
16:48:36 <chrishtr> +1 to strong evidence that it's confusing a lot of people. I've heard this confusion many times now
16:48:43 <ydaniv> lea: I completely agree we need to solve this
16:48:47 <ydaniv> ... just about direction
16:48:55 <Rossen2> ack iank_
16:48:58 <miriam> q+
16:49:14 <ydaniv> iank_: I'm a little bit worried about compat here
16:49:39 <ydaniv> ... even when we first changed it to center, when we didn't have alignment KW, we ran into compat problems
16:49:56 <lea> q+
16:49:56 <ydaniv> ... it's a gut feeling this will be problematic, maybe introduce a new property?
16:50:09 <ydaniv> ... or another syntax to ignore margins?
16:50:13 <miriam> q-
16:50:29 <ydaniv> TabAtkins: trying to avoid a simple behavior switch, those are not great design
16:50:35 <ydaniv> ...  I think it might be not web compat
16:50:44 <ydaniv> ... that's the best design we've come by so far
16:51:08 <ydaniv> ... if you're not screwing with margin behavior too much this will work and preserve right behavior
16:51:15 <ydaniv> iank_: don't know
16:51:28 <ydaniv> TabAtkins: there are good and bad paths based on what you're doing
16:51:37 <ydaniv> iank_: people use dialogs in all sorts of ways
16:51:41 <ydaniv> ... worried...
16:52:07 <ydaniv> ... ppl set alignment properties, would like to try another solution
16:52:29 <ydaniv> TabAtkins:  I suspect some of directions you suggest would be just as bad
16:52:36 <ydaniv> iank_: maybe
16:53:09 <ydaniv> ... a lot of devs feel like the align properties should feel like auto margins
16:53:19 <Rossen2> ack kizu
16:53:49 <ydaniv> kizu: a few things about naming, for  popover it would be better, when you anchor it starts doing what it should
16:54:12 <ydaniv> ... q is how do we determine it? is it when there something in the insets?
16:54:23 <ydaniv> ... also think there's a second problem with try options
16:55:14 <ydaniv> ... very often you position something, you click on it and it's not there
16:55:37 <ydaniv> ... right now to replicate common libraries you need to do a lot
16:55:49 <ydaniv> ... so we should have a solution for ppl to not care about it
16:56:12 <ydaniv> TabAtkins: so naming for popover over dialog, you need to set <missed>
16:56:21 <ydaniv> ... you also have to reset margin auto to 0
16:56:39 <ydaniv> ... second, when you use position area
16:56:57 <ydaniv> ... we probably want to expand the definion to different things, will expand on separate issue
16:57:02 <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
16:57:02 <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.
16:57:07 <ydaniv> ... also third issue, separate
16:57:39 <ydaniv> lea: if down the line we want to branch off in a different way we'll need to introduce new stuff
16:57:58 <ydaniv> ...  so wonder id my proposed condition won't work, <missed>
16:58:17 <ydaniv> TabAtkins: the condition we're worrying about is not whether you're using it or not
16:58:37 <iank_> (because position-area is high priority we could coerce margins to zero at that stage)
16:58:41 <ydaniv> ... we can't style based on other styles
16:59:04 <ydaniv> lea: both features work around it by  IACVT
16:59:32 <diekus> diekus has joined #css
17:00:08 <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.
17:00:15 <ydaniv> TabAtkins: can we move back to issue?
17:00:23 <ydaniv> Rossen2: we are at time
17:00:44 <TabAtkins> topic: end
17:00:49 <TabAtkins> mason's issue: https://github.com/w3c/csswg-drafts/issues/12437
17:01:05 <ydaniv> masonf: please take a look there and add comments
17:01:08 <TabAtkins> about ::interest-hint
17:03:40 <antonp> antonp has joined #css
17:03:52 <emeyer> emeyer has left #css