14:55:40 <RRSAgent> RRSAgent has joined #css
14:55:45 <RRSAgent> logging to https://www.w3.org/2026/03/11-css-irc
14:55:45 <Zakim> RRSAgent, make logs Public
14:55:46 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
14:58:58 <dshin-moz> dshin-moz has joined #css
14:59:45 <kbabbitt> kbabbitt has joined #css
15:01:12 <romain> romain has joined #css
15:02:03 <TabAtkins> present+
15:03:17 <romain> present+
15:03:24 <ydaniv> ydaniv has joined #css
15:03:48 <kbabbitt> present+
15:03:51 <dbaron> Present+
15:03:57 <ydaniv> present+
15:03:59 <bramus> present+
15:04:02 <dshin-moz> present+
15:04:08 <ydaniv> ScribeNick: ydaniv
15:04:38 <ydaniv> github-bot, take up https://github.com/w3c/csswg-drafts/issues/13535
15:04:39 <github-bot> Topic: [css-values] Clarification on Simplification for clamp() with none values
15:04:39 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13535
15:05:26 <ydaniv> TabAtkins: currently the spec for clamp() says it acts like a max/min depending on where you use the value
15:05:49 <kizu> kizu has joined #css
15:05:56 <kizu> present+
15:06:09 <ydaniv> ... [summarizing description]
15:06:14 <emilio> present+
15:06:36 <romain> q+
15:06:43 <ydaniv> ... per spec Chrome is wrong, doesn't matter much to me how we go on with this
15:07:06 <astearns> ack romain
15:07:11 <emilio> q+
15:07:19 <ydaniv> ... unless anybody has a reason to care about that behavior specifically, I suggest open a bug on Chrome and close no change
15:08:01 <ydaniv> romain: How does this interact with color interpolation, like color-mix where we also have none, where this can be simplified or not
15:08:04 <ydaniv> ...
15:08:04 <miriam> present+
15:08:24 <ydaniv> TabAtkins: those nones are unrelated keywords, so should not have any effect
15:08:40 <ydaniv> romain: I think lea had some note regarding that
15:09:02 <ydaniv> ... where substituting none in color function is not the same
15:09:11 <ydaniv> TabAtkins: you can not write none into a claculation
15:09:46 <ydaniv> ... so doesn't have any connection with this none, it's not part of calculation, this none is only related as value to clamp()
15:09:54 <ydaniv> ... so it can't sub-in for that
15:10:09 <ydaniv> romain: ok, thanks
15:10:09 <astearns> ack emilio
15:10:43 <ydaniv> emilio: I don't care which way, but in FF it is implemented and was easier to implement.
15:11:24 <ydaniv> ... I'm ok with no change, it's a bit weird, FF actually does the same thing as Chrome but we did not ship it yet
15:11:36 <ydaniv> TabAtkins: so it's ok either way, don't care much
15:11:55 <ydaniv> emilio: my opinion is that it's simpler to implement with min/max
15:12:05 <ydaniv> astearns: is this an over simplification in any way?
15:12:21 <ydaniv> TabAtkins: no, you don't get one or the other, but it's the exact behavior
15:12:35 <ydaniv> ... we added the none since using clamp() as min/max is more handy
15:13:01 <ydaniv> astearns: don't see anyone from WebKit, we could resolve as a way to get their opinion
15:13:08 <emilio> sg
15:13:09 <ydaniv> TabAtkins: SGTM
15:14:22 <ydaniv> PROPOSED RESOLUTION: when possible we simplify clamp() to min() or max()
15:14:30 <ydaniv> astearns: objections?
15:14:39 <ydaniv> RESOLVED: when possible we simplify clamp() to min() or max()
15:14:53 <ydaniv> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11924
15:14:53 <github-bot> Topic: [css-values] Grammar syntax for defining excluded idents for <custom-ident> productions
15:14:53 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11924
15:15:33 <astearns> github-bot: none
15:15:33 <github-bot> astearns, Sorry, I don't understand that command.  Try 'help'.
15:15:42 <astearns> topic: none
15:16:11 <ydaniv> github-bot, take up https://github.com/w3c/csswg-drafts/issues/9451
15:16:11 <github-bot> Topic: [css-typed-om-1] Should css typed om support the same simplifications as css-values-4?
15:16:11 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9451
15:17:26 <ydaniv> emilio: this is about calc simplification, since we were implementing typed OM we had to add a lot of stuff to avoid,
15:17:39 <ydaniv> ... seemed silly since no one else added it
15:18:20 <ydaniv> TabAtkins: it was intended to reflect what you suggest, but was overlooked, let's add this simplifaction and not hold to intermediary info
15:18:29 <ydaniv> astearns: and we need to ammend WPTs?
15:18:31 <ydaniv> TabAtkins: yes
15:19:05 <ydaniv> PROPOSED RESOLUTION: calculation trees easily simplifies in all representations, including in exposed in Typed OM
15:19:14 <ydaniv> astearns: objections?
15:19:24 <ydaniv> RESOLVED: calculation trees easily simplifies in all representations, including in exposed in Typed OM
15:19:38 <ydaniv> github-bot, take up https://github.com/w3c/csswg-drafts/issues/13211
15:19:38 <github-bot> Topic: [css-properties-values-api] `@property` descriptors should be optional whenever possible
15:19:38 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13211
15:20:24 <ydaniv> TabAtkins: for now, for reasons we designed in the past, the @property does not give optional default values, all needs to be specified
15:20:37 <ydaniv> ... it proved to be annoyance in practice
15:20:47 <ydaniv> ... it's also been annoying in spec writing
15:21:15 <ydaniv> ... proposal is to make all descriptors in the @property optional as if it was untyped
15:21:20 <kizu> +calc(infinity) to the proposal
15:21:34 <ydaniv> ... I saw nothing but support on the thread
15:21:36 <ydaniv> +1
15:21:38 <miriam> +1 strong support
15:21:45 <kbabbitt> +1, this will also make writing supports-conditions for these easier
15:21:56 <ydaniv> astearns: anyone with reservations? or need more time?
15:22:16 <emilio> q+
15:22:25 <ydaniv> PROPOSED RESOLUTION: make all property descriptors in @property optional
15:22:30 <astearns> ack emilio
15:22:34 <ydaniv> astearns: objections?
15:22:57 <ydaniv> emilio: I think we also do validation on the descriptors, they need to match syntax
15:23:07 <kizu> q+
15:23:20 <ydaniv> TabAtkins: only change that if you specifty a non universal it needs to match syntax
15:23:28 <ydaniv> ... otherwise we keep existing behavior
15:23:30 <astearns> ack kizu
15:24:01 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/11-css-minutes.html fantasai
15:24:08 <ydaniv> kizu: +Infinity, only care about interop where authors do this but may start doing something some browsers, but still break in others
15:24:08 <romain> q+
15:24:13 <ydaniv> TabAtkins: true, we can see later?
15:24:27 <astearns> ack romain
15:24:29 <ydaniv> astearns: would you like to resolve? or wait?
15:24:34 <ydaniv> kizu: resolve please
15:25:08 <emilio> q+
15:25:08 <TabAtkins> interop is people wrote an *invalid* rule, got a normal custom prop, but now get *some* behavior
15:25:09 <ydaniv> romain: don't see any interop issue, since unregistered is the same as fallbacks we have now
15:25:32 <ydaniv> TabAtkins: [repeating above] ^
15:25:44 <emilio> q-
15:26:05 <ydaniv> kizu: or specify something that was not applied and now stops applying to things that don't match anymore
15:26:10 <romain> +1
15:26:22 <ydaniv> astearns: so are we still trying to resolve and see whether there's a problem?
15:26:29 <ydaniv> ... objections? (again)
15:26:48 <ydaniv> RESOLVED: make all property descriptors in @property optional
15:27:07 <ydaniv> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11924
15:27:07 <github-bot> Topic: [css-values] Grammar syntax for defining excluded idents for <custom-ident> productions
15:27:07 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11924
15:27:52 <ydaniv> TabAtkins: this one is about how custom-ident does not match
15:28:07 <ydaniv> ... Sam wanted to make it explicit in the grammar
15:28:27 <TabAtkins> <'property'> = <custom-ident> - [ none | foo | bar | baz | something-long ]
15:28:31 <romain> +1
15:28:34 <ydaniv> ... there are a lot of proposals for syntax, I slightly prefer a - combinator
15:29:03 <ydaniv> ... you must have a custom-ident on the left, and on the right the keyword
15:29:14 <TabAtkins> <'property'> = <custom-ident -[ none | foo | bar | baz | something-long ]>
15:29:28 <ydaniv> ... other suggestions are to put it directly into the custom-ident
15:29:47 <ydaniv> ... ok with any proposal if anyone has strong opinion
15:29:50 <fantasai> <'property'> = <custom-ident ![ none | foo | bar | baz | something-long ]>
15:29:52 <fantasai> was also proposed
15:29:57 <astearns> ack fantasai
15:30:12 <ydaniv> fantasai: unless we want to make this a general combinator, ...
15:30:24 <ydaniv> ... we should keep it inside the brackets
15:30:36 <lea> lea has joined #css
15:30:43 <ydaniv> ... otherwise it would be the [missed] operator
15:30:58 <astearns> s/[missed]/tightest
15:30:58 <TabAtkins> s/\[missed\]/tightest/
15:31:06 <ydaniv> ... between the 2 things I posted, if it's a combinator I prefer the -
15:31:55 <ydaniv> fantasai: the brackets serve as a grouping operator
15:32:07 <kizu> q+
15:32:21 <astearns> ack kizu
15:32:32 <fantasai> s/prefer the -, and if it's incorporated, I prefer the !. - reads like a dash, which we use for other purposes/
15:32:38 <ydaniv> kizu: off topic a bit, but nice to have for @property to use this there as well
15:32:38 <astearns> s/prefer the -/prefer the !/
15:32:57 <ydaniv> TabAtkins: after we resolve please open an issue on that
15:33:00 <ydaniv> kizu: sure
15:33:01 <weinig> q+
15:33:02 <fantasai> s/prefer the !/prefer the -, and if it's incorporated, I prefer the !. - reads like a dash, which we use for other purposes/
15:33:12 <astearns> ack weinig
15:33:28 <fantasai> s/prefer the -/prefer the - because it feels more like a combinator/
15:33:30 <romain> slight preference for <custom-ident ![ none | foo | bar | baz | something-long ]>
15:33:41 <ydaniv> weinig: fine with anything, I think for those who wanted to do more, would be good to aggregate what's not specified by the grammar and add that as well
15:34:00 <ydaniv> ... but interested in how we can get this done better
15:34:11 <dbaron> I somewhat like weinig's original suggestion of excludes=
15:34:20 <ydaniv> astearns: sounds like we're converging around using !
15:34:44 <ydaniv> dbaron: not a strong opinion but I kind of like the original suggestion of excludes but could be too verbose
15:34:52 <ydaniv> TabAtkins: don't mind, all reasonable
15:35:08 <ydaniv> fantasai: we don't really use a keyword exclusion operator
15:35:27 <TabAtkins> current modifiers are just: a plain `[...]` bracket, for ranges, and now would add `![...]` bracket for exclusions
15:35:45 <ydaniv> astearns: as spec production would be nice to have, a readable keywords seems ok to me
15:35:58 <TabAtkins> Notably CSS is the rare language where ! does *not* meant "not" lol
15:36:29 <ydaniv> fantasai: this would be the first place where we have a syntactic operator, and not need to go in that direction
15:36:38 <ydaniv> TabAtkins: leaning towards what fantasai said
15:36:40 <fantasai> s/we have/we'd have an identifier as/
15:36:55 <ydaniv> astearns: dbaron you want to argue more for the keyword?
15:36:58 <ydaniv> dbaron: ok with !
15:37:09 <fantasai> PROPOSED: <'property'> = <custom-ident ![ none | foo | bar | baz | something-long ]>
15:37:31 <ydaniv> PROPOSED RESOLUTION: we add a new ! brackets group to the custom-ident terminal to add keywords which are excluded from production
15:37:42 <ydaniv> astearns: objections?
15:37:51 <ydaniv> RESOLVED: we add a new ! brackets group to the custom-ident terminal to add keywords which are excluded from production
15:38:02 <fantasai> RESOLVED: Adopt <'property'> = <custom-ident ![ none | foo | bar | <non-terminal> | something-long ]>
15:38:49 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12735
15:38:49 <github-bot> Topic: [css-properties-values-api] `light-dark()` and system colors in initial values
15:38:49 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12735
15:39:31 <ydaniv> TabAtkins: props and values API says initial values have to be computationally independent
15:39:55 <ydaniv> ... question is does this mean that stuff like color scheme are not computationally independent?
15:40:11 <ydaniv> ... answer is yes, I don't think we need to add anything, it follows the definition
15:40:22 <miriam> q+
15:40:26 <ydaniv> ... since someone thought this is unclear, we could add a note
15:40:28 <weinig> q+
15:40:37 <ydaniv> ... I think we can resolve close no change
15:40:51 <ydaniv> dbaron: what's the current state of computed scheme colors?
15:40:59 <weinig> q-
15:41:16 <ydaniv> emilio: I think we ended up computes to color
15:41:19 <kbabbitt> system colors compute to color values
15:41:26 <dbaron> s/computed scheme/the computed value of system colors.  Does it compute to keywords or to/
15:41:28 <astearns> ack miriam
15:41:46 <ydaniv> miriam: I think that's right in existing spec, my question is do we need to keep this restriction?
15:42:00 <ydaniv> ... it's not the way authors think about custom properties
15:42:01 <emilio> q+
15:42:08 <ydaniv> ... if we don't need it we should not have it
15:42:16 <astearns> ack emilio
15:42:29 <ydaniv> emilio: it would be quite weird
15:43:05 <ydaniv> ... it's a restriction custom properties is known to have, I'd have to think how easy it is to remove this restriction
15:43:53 <ydaniv> TabAtkins: we have some color stuff here that is used as initial values in custom properties, but between the color property itself and several other properties which depend on other properties, it's a funky case
15:44:16 <emilio> color is also not quite that, because currentcolor computes to itself
15:44:18 <ydaniv> ... however, outside of color where we do use initial value like em it's calculated like initial em
15:44:46 <emilio> q+
15:44:49 <ydaniv> ... it seems weird to authors it's not resolving the same as set on the element they set it on
15:45:11 <ydaniv> miriam: I get the complexity, but authors don't have a good way to set a global initial defaults
15:45:51 <ydaniv> ... it needs a lot more teaching, or some better way to help authors set both, global defaults that can be relative, and initial value
15:46:09 <ydaniv> TabAtkins: would love to chat more on the use-cases, and see what are your expectations
15:46:14 <astearns> ack dbaron
15:46:35 <ydaniv> dbaron: one thought is what an initial value means is different between inherited and non-inherited
15:46:58 <ydaniv> ... on inherited it's used only on the root, as opposed to non-inherited
15:47:21 <ydaniv> ... if you wanted this it would be harder to work around the non-inherited ones
15:47:52 <astearns> ack fantasai
15:48:20 <astearns> ack emilio
15:48:59 <ydaniv> astearns: miriam would want to discuss the general authoring problems here?
15:49:03 <ydaniv> miriam: will open a new one
15:49:19 <ydaniv> astearns: so for this resolution we decide to add an example?
15:49:22 <ydaniv> TabAtkins: yeah
15:49:41 <ydaniv> PROPOSED RESOLUTION: Add an example as to why this case is computationally independent
15:49:52 <ydaniv> astearns: objections?
15:49:58 <ydaniv> RESOLVED: Add an example as to why this case is computationally independent
15:50:13 <ydaniv> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12791
15:50:13 <github-bot> Topic: [css-backgrounds][css-animations] Should background-* and animation-* longhands computed values serialize using the same truncation rules?
15:50:13 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12791
15:51:06 <ydaniv> weinig: this is about whether compat will hold up here, animations/background longhands are coordinated lists
15:51:32 <ydaniv> ... wanted to know if we want to resolve on compat serializations
15:51:43 <mustaq> mustaq has joined #css
15:51:59 <ydaniv> TabAtkins: in one of the properties having one tramps the others, in the other it's not
15:52:03 <kurt> kurt has joined #css
15:52:09 <ydaniv> ... I just care about having a consistent behavior
15:52:25 <ydaniv> weinig: not sure even all browsers do that, it's just what WPT test
15:52:42 <ydaniv> ... should be as round-trippable as possible
15:53:06 <ydaniv> ... I would be sticking with what the spec says should be correct
15:53:12 <ydaniv> emilio: seems FF is already doing that
15:53:20 <ydaniv> ... so probably compatible
15:53:21 <emilio> https://wpt.fyi/results/css/css-backgrounds/parsing/background-repeat-computed.html
15:53:25 <ydaniv> weinig: ok, thanks
15:53:28 <astearns> ack fantasai
15:53:42 <ydaniv> fantasai: I support what TabAtkins said, don't have opinion on which way
15:54:02 <ydaniv> ... backgrounds is a canonical example for this
15:54:18 <ydaniv> weinig: I think background is the one where it does not match the spec's behavior
15:54:23 <ydaniv> ... but in FF seems ok
15:54:23 <astearns> ack dbaron
15:54:26 <fantasai> s/this/coordinating list property group, spec doesn't use the term because it predates the term/
15:54:49 <ydaniv> dbaron: one thing that can happen, gCS and computed value are different things
15:54:52 <emilio> q+
15:55:08 <fantasai> s/on which way/on which way as long as Web-compatible/
15:55:19 <ydaniv> ... I would not like the truncation to be different, but it is today in some implementations so should be careful
15:56:30 <ydaniv> ... I think my prefs aggree with weinig, so that both computed value and gCS return the same value
15:56:44 <emilio> q-
15:56:51 <ydaniv> weinig: they should likely match, and I'll ensure on WPT we have something we're explicitly testing
15:57:17 <ydaniv> dbaron: there were some implementations that did weird thing to the computed value, don't know if these are still around today
15:57:40 <ydaniv> astearns: should we resovle on what we wish to see? and look for compat concerns? Or make smaller viable changes?
15:58:07 <ydaniv> weinig: this mostly comes down to changing background and mask-image in WK and CH, and update tests
15:58:12 <ydaniv> ... probably tests first
15:58:25 <ydaniv> astearns: updating the tests makes sense if we updated spec
15:58:38 <ydaniv> weinig: the spec is correct
15:58:43 <astearns> ack dbaron
15:59:13 <ydaniv> dbaron: side comment, if we do find a compat problem here, I'd like to keep the background and mask matching, then to try and make them match others
15:59:13 <fantasai> +1 dbaron
15:59:16 <ydaniv> +1 dbaron
15:59:54 <ydaniv> PROPOSED RESOLUTION: no change, update WPT to match the spec's expectations and see if there's web compat issues
16:00:01 <ydaniv> astearns: obejctions?
16:00:09 <ydaniv> RESOLVED: no change, update WPT to match the spec's expectations and see if there's web compat issues
16:00:35 <astearns> topic: end
16:00:48 <alisonmaher> alisonmaher has joined #css
16:00:50 <jbreiland> jbreiland has joined #css
16:00:55 <alisonmaher> present+
16:01:10 <flackr> present+
16:01:18 <jbreiland> present+
16:02:21 <PaulG> PaulG has joined #css
16:02:28 <PaulG> present+
16:02:40 <vmpstr> present+
16:02:51 <smfr> smfr has joined #css
16:06:14 <andreubotella> andreubotella has joined #css
16:06:14 <bramus> present+
16:06:15 <astearns> topic: Mar 11 agenda: https://lists.w3.org/Archives/Public/www-style/2026Mar/0008.html
16:06:21 <kbabbitt> present+
16:06:23 <andreubotella> present+
16:06:49 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12812
16:06:49 <github-bot> Topic: Fragmenting (`continue: collapse`) line-clamp containers
16:06:49 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12812
16:07:12 <TabAtkins> andreubotella: How do we handle a line-clamp container in a fragmentation context, like multicol
16:07:18 <TabAtkins> andreubotella: browsers differ, sometimes broken
16:07:39 <TabAtkins> andreubotella: also, what should happen when the line-clamp container itself has columns/etc
16:07:59 <TabAtkins> andreubotella: I think if we want to make them fragment, wk's behavior is what we'd want
16:08:22 <TabAtkins> andreubotella: You just slice the line-clamp container into fragments. the co9unt is preserved across the fragment break, and the height is the total height including the slice gap
16:08:34 <TabAtkins> andreubotella: this is WK's current -webkit-line-clamp behavior.
16:08:43 <TabAtkins> andreubotella: for clamping by height, they don't currently support it by defualt
16:09:12 <TabAtkins> andreubotella: also, overflow:hidden, which is used everywhere in webkit-line-clamp as its a required property there
16:09:18 <TabAtkins> andreubotella: depending on browser, it can make the box model different
16:09:38 <florian> q+
16:09:40 <TabAtkins> andreubotella: with line-clamp you don't need that overflow, but maybe we should make it automatically make the content monolithic
16:09:59 <TabAtkins> andreubotella: chromium does that by default, except when you set columns on the actual line-clamp container
16:10:04 <TabAtkins> andreubotella: (which seems to be a bug)
16:10:25 <TabAtkins> andreubotella: in WebKit where you're slicing the result into multiple columns, this is relatively easy to do
16:10:34 <TabAtkins> andreubotella: main problem is taking into account the gap between columns when clamping by height
16:10:48 <TabAtkins> andreubotella: but in engines where it fragments it's more complicated
16:10:55 <TabAtkins> andreubotella: so, should we allow this? what to do about it?
16:11:49 <mustaq> mustaq has joined #css
16:11:51 <emilio> q+
16:12:16 <TabAtkins> andreubotella: there's also a question - if you have display:block or flow-root the columns proeprties works, but not -webkit-box or float.
16:12:29 <astearns> ack florian
16:12:37 <emilio> I think we resolved on it happening at computed value time? So it should apply per spec I think
16:12:49 <TabAtkins> florian: when it comes to 'column' applying directly to a clamp container, not sure when we took a resolution but I think we did take one that says it won't apply
16:12:52 <astearns> astearns has changed the topic to: Mar 11 agenda: https://lists.w3.org/Archives/Public/www-style/2026Mar/0008.html
16:13:03 <TabAtkins> florian: the original draft for continue:discard explicitly worked with Multicol and the new value changes that
16:13:12 <TabAtkins> florian: so I think we did make a decision at some point and we should probably stick with it
16:13:44 <TabAtkins> florian: when instead it is *in* a fragmentainer i'd prefer fragmenting properly. i'd be okay with monolithic, don't see much use-cases there. would be sad about slicing in the middle of a line.
16:13:57 <TabAtkins> florian: can you reexplain WebKit behavior?
16:14:19 <TabAtkins> andreubotella: visually it behaves as fragmenting properly. but the layout engine basically does it in one single fragment, leaving the gap, then slices
16:14:28 <TabAtkins> florian: okay so it looks like it's fragmenting properly, that's fine
16:14:40 <TabAtkins> andreubotella: in layout engines that do it "properly" it's just a bi tmore complicated, is why I mentioned it
16:14:52 <TabAtkins> andreubotella: you need to keep track of the gaps and ...
16:15:15 <TabAtkins> andreubotella: when clamping by height you're not sure if you clamp until you've started working on the next fragment. that's a bit more complicated
16:15:34 <astearns> ack emilio
16:15:34 <TabAtkins> florian: it seems better to do the full fragment, but use-cases dont' seem strong. so if the monolithic beahvior is simpler that's ok by me
16:15:43 <TabAtkins> emilio: I agree monolithic is simpler
16:16:04 <TabAtkins> emilio: per spec, we resolve on -webkit-box to flow-root fixup to happen at computed value time, and it seems clear what happens there
16:16:12 <TabAtkins> florian: we could make an exception if we wanted to...
16:16:16 <TabAtkins> emilio: sure but why would we
16:16:29 <TabAtkins> andreubotella: if you agree that's what the spec implies, that's probably correct
16:16:34 <TabAtkins> andreubotella: I wasn't 100% sure
16:17:01 <astearns> ack fantasai
16:17:06 <TabAtkins> astearns: let's table that aspect for now, you can raise an issue if it turns out to still be important. want to concentrate on line-calmp containers in a fragment context
16:17:18 <TabAtkins> fantasai: I agree with florian that we should fragment properly
16:17:33 <TabAtkins> fantasai: don't have a strong opinion on a line-clamp that is also fragment context
16:17:47 <TabAtkins> fantasai: but *in* in a fragment context should do correctly, counting across the whole thing
16:18:01 <TabAtkins> fantasai: you just have to walk backwards when counting
16:18:15 <TabAtkins> emilio: our fragment breaks are always after a line... ok
16:18:28 <TabAtkins> emilio: it should be well-defined in terms of line count
16:18:52 <emilio> q+
16:18:59 <TabAtkins> astearns: so it sounds like we're converging on "properly" fragmenting line-clamp containers, taking wk's impl as a guide
16:19:19 <TabAtkins> andreubotella: in layout engines like chromium that's a bit harder. at the point where you're doing layout on the second fragment you can't modify the first anymore
16:19:29 <TabAtkins> andreubotella: so you'd have to make sure the clamp won't happen in the first frag
16:19:34 <TabAtkins> andreubotella: so more complicated but doable
16:19:41 <TabAtkins> emilio: I think was gonna suggest similar
16:20:08 <TabAtkins> emilio: if you grow the block past the clamp point, which you can by setting the height to a tall number, you can end in a situation where the clamp is in the previous fragment, line -1 basically
16:20:17 <TabAtkins> emilio: should be fine to treat it as zero or something. maybe a bit weird
16:20:28 <TabAtkins> emilio: but I think it's not a common use-case ,shoudln't matter much
16:20:50 <TabAtkins> astearns: proposed then, we will specify "actual" fragmentation for line-clamp containers in a fragmentation context, work out details as we go
16:20:54 <TabAtkins> astearns: objections?
16:21:02 <TabAtkins> RESOLVED: we will specify "actual" fragmentation for line-clamp containers in a fragmentation context, work out details as we go
16:21:22 <TabAtkins> astearns: do we want a resolution on a line-calmp container that *is* a Multicol, or a separate issue?
16:21:44 <TabAtkins> florian: if anyone wants to argue it should apply... currently spec says it doesn't and i'm okay with that
16:21:52 <TabAtkins> (I think it's reasonable to forbid it, seems weird)
16:22:02 <TabAtkins> astearns: hearing no one calling for it, we'll leave it as specified
16:22:12 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12814
16:22:12 <github-bot> Topic: [css-pseudo] Allow animations on ::first-letter and ::first-line similar to ::marker
16:22:12 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12814
16:22:33 <TabAtkins> astearns: looks like convo says "yeah let's do it"
16:22:41 <emilio> q+
16:23:22 <TabAtkins> dbaron: i'm not sure how much the specs for ::first-letter/line and impls match right now, and before we add animations we should make sure they agree
16:23:29 <emilio> +1
16:23:30 <TabAtkins> dbaron: for things like what inheritance and fictional tag sequence is
16:23:47 <TabAtkins> dbaron: the other thing I'm unsure about is whether it's asking only about CSS animations, or about animations and transitions
16:24:03 <TabAtkins> dbaron: when people talk about animations they sometimes mean T&A, and I think transitions is scarier if we don't have that interop
16:24:08 <astearns> ack emilio
16:24:23 <TabAtkins> (agree, animations seems pretty clear in its behavior, it's just setting values. reacting to values in transitions is trickier)
16:24:26 <fantasai> fantasai has joined #css
16:24:26 <TabAtkins> emilio: agreed
16:24:45 <TabAtkins> emilio: intention seems to be the computed values apply to the root of the first-letter style "box", and whatever comes out of inheritance from that just "happens"
16:25:07 <TabAtkins> emilio: given the state of interop for these pseudos, i'm not a fan of piling more stuff into it before solving those issues
16:25:34 <TabAtkins> astearns: and while I summarized the convo as 'let's do it', I was reading Rob's comment wrong. he was saying "there's no reason not to, except it would be hard"
16:25:41 <astearns> ack fantasai
16:25:43 <TabAtkins> flackr: right, I was saying it' is unlikely we could implement soon because eit would be complicated
16:25:58 <TabAtkins> fantasai: I feel like theoretically there's no strong reason to not do it, but if it's difficult to impl it's not a high prio
16:26:05 <TabAtkins> fantasai: it sounds like the issue is non-tree-abiding pseudos
16:26:11 <TabAtkins> fantasai: and for tree-abiding it's fine?
16:26:13 <TabAtkins> flackr: right
16:26:28 <TabAtkins> fantasai: so the resolution could be that animations and transitions aren't supported on non-tree-abiding
16:26:38 <TabAtkins> flackr: safari today does support *animations* on them
16:26:44 <TabAtkins> fantasai: so MAY support, optional?
16:27:10 <TabAtkins> flackr: maybe yeah. transitions is the tricky one, need to figure out when it happens. style change from an ancestor, or just from the pseudo itself? complicated. didn't test if safari supports them.
16:27:31 <TabAtkins> fantasai: I think if you have an El and it's transitioning, the child functionally transitions due to inheritance but isn't considered to be transitioning
16:27:39 <TabAtkins> fantasai: think it would be similar
16:27:54 <TabAtkins> flackr: so I think elika's point is every browser supports tree-abidng pseudos, so it would be good to clarify that's required
16:28:13 <TabAtkins> astearns: on the "may" thing, maybe leaving the spec saying nothing about non-tree-abiding might be better...?
16:28:31 <TabAtkins> fantasai: we're not allowing "whatever". I think we can specify... if there's details like what rob mentioned we can clarify them
16:28:48 <TabAtkins> fantasai: conflicts would be on certain non-tree-abiding ones. but to the extent that impls can figure it out for some, we should allow it
16:29:03 <TabAtkins> fantasai: so I think we should be clear - a&t are allowed on pseudos, but for non-tree-abiding they're optional
16:29:17 <TabAtkins> fantasai: so impls might be a ble to figure it out for highlights but not first-letter or wahtever
16:29:28 <TabAtkins> fantasai: these are a progressive enhancement, I think it's okay to be optional
16:29:31 <TabAtkins> q+
16:29:41 <TabAtkins> astearns: I agree if optionality is meant to be a temp stopgap
16:29:48 <TabAtkins> astearns: if there's a plausible way forward
16:29:55 <TabAtkins> fantasai: I think in an ideal world we should get there
16:30:08 <fantasai> scribe+
16:30:09 <TabAtkins> fantasai: but if someone is really excited about getting ::first-letter implemented, they should go for it
16:30:15 <astearns> ack TabAtkins
16:30:32 <fantasai> TabAtkins: wrt optional and progressive enhancement, I agree about transitions being an enhancement. Let's nail down details.
16:30:44 <fantasai> TabAtkins: Don't agree for animations. They are often not a progressive enhancement, can break content if they don't work.
16:31:02 <fantasai> TabAtkins: I think for non-tree-abiding, we should take a definite yes/no on animations
16:31:06 <fantasai> TabAtkins: and I would lean towards yes
16:31:10 <fantasai> TabAtkins: because theyr'e simpler
16:31:15 <fantasai> TabAtkins: but leave them unspecified now
16:31:32 <TabAtkins> astearns: but if we have a yes on animations, we run the risk on the spec being fiction since it doesn't seem to be a priority
16:31:44 <fantasai> astearns: But if we have a yes on animations, we run risk of spec being fiction, since not a priority or easy to add to engines that don't support
16:31:52 <TabAtkins> TabAtkins: wk supports animations right now, sometimes only one browser supports a feature for a while, that's fine
16:32:00 <astearns> ack fantasai
16:32:18 <TabAtkins> fantasai: for animations on content generally I agree, but for non-tree-abiding pseudos which are very limited, I don't think I agree. a shimmery highlight or something
16:32:44 <fantasai> TabAtkins: If you set an animation to make shimmery, need to make sure you have base styles that are readable.
16:32:55 <fantasai> TabAtkins: Authors will assume animations exist, and not have good base styles
16:33:03 <fantasai> TabAtkins: So worried about that
16:33:20 <TabAtkins> fantasai: do authors in the room have an opinion on that?
16:33:30 <romain> q+
16:33:46 <TabAtkins> flackr: for the other point, we do have things that are specified but not supported in all browsers yet. i'm okay with that. we're clearly not opposed to the behavior
16:33:49 <astearns> ack romain
16:34:05 <TabAtkins> romain: as an author i've never written fallbacks for an animation not working, so I agree with Tab that it could be bad
16:34:15 <TabAtkins> romain: it's fine if an animation doesn't play and just skips to the end, but it should *work*
16:34:45 <fantasai> TabAtkins: Let's spec that animations and transitions work on all tree-abiding
16:35:09 <fantasai> TabAtkins: On non-tree-abiding, animations work, and transitions are intentionally optional right now.
16:35:39 <TabAtkins> astearns: i'm fine with that, but it does somewhat go against the idea that authors will write animations that work fine in WebKit and fail in other engines
16:35:54 <fantasai> TabAtkins: That happens with plenty of properties that are supported in one browser and not others.
16:36:00 <fantasai> TabAtkins: We prefer wide support.
16:36:12 <fantasai> TabAtkins: I think it's fine as a temporary state of affairs, to have things be in one browser
16:36:19 <fantasai> TabAtkins: OK for browser to go ahead of each other in various ways
16:36:34 <TabAtkins> astearns: so we have two proposed resolutions, for tree-abiding and non-tree-abiding
16:36:37 <TabAtkins> astearns: any tweaks to those?
16:36:44 <TabAtkins> astearns: objections to the resolutions in IRC?
16:36:56 <TabAtkins> RESOLVED: animations and transitions work on all tree-abiding
16:37:06 <TabAtkins> RESOLVED: On non-tree-abiding, animations work, and transitions are intentionally optional right now.
16:37:15 <github-bot> Topic: [css-font-loading] Lack of interop on FontFace constructor.
16:38:02 <TabAtkins> astearns: Emilio had to drop, but his final comment has his current suggestion: quote invalid font-family names rather thanr ejecting the constructor
16:38:16 <TabAtkins> TabAtkins: I'm fine with that
16:38:21 <TabAtkins> astearns: objections?
16:38:34 <TabAtkins> fantasai: if that's what jfkthame says to do, i'm fine with it
16:38:54 <TabAtkins> RESOLVED: If a FontFace is constructed with an invalid font-family name, treat it as a quoted string rather than throwing
16:39:05 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/865
16:39:05 <github-bot> Topic: [css3 positioning] support position:sticky inside an overflow:hidden|auto on general parents
16:39:05 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/865
16:39:41 <TabAtkins> flackr: we decided in another discussion that it's reasonable to create a scroll container that onlys scrolls in one axis, and is clip in the other
16:40:22 <TabAtkins> flackr: following this line of thought, we can support... one of the use-cases for postiion-sticky responding to an ancestor scroll container, by saying the position-sticky in each axis looks for the nearest container that scrolls in that axis
16:40:39 <TabAtkins> flackr: this is a fairly constrained change, doesn't require new syntax, and supports horiz-scoll tables in vertical-scroll docs
16:40:50 <TabAtkins> flackr: we've tested it and it seems to work fine. does what users expect
16:41:05 <TabAtkins> flackr: so the proposal is that sticky can use different containers for each axis
16:41:18 <TabAtkins> astearns: does this cover the original test-case?
16:41:36 <TabAtkins> flackr: the original was relying on the implications of overflow:hidden... there are other APIs that can get that to work, I posted a demo
16:41:55 <TabAtkins> flackr: my proposal handles the either novel use-case which wasn't handled previously, which can be sticky-translated in different axises by different scrollers
16:42:06 <kizu> q+
16:42:13 <astearns> ack kizu
16:42:26 <TabAtkins> kizu: this is really nice to have. only concern is interop
16:42:42 <TabAtkins> kizu: a sticky element that previously didn't work well could start working and sticking
16:42:52 <TabAtkins> kizu: but it would be really nice for this to work
16:43:11 <TabAtkins> flackr: we expect that, since to set the container up you have to explicitly set overflow:clip on the off-axis, it'll be rare that existing content gets into this use-case
16:43:22 <kizu> Ah, yes, with `clip` is will be for sure safer
16:43:29 <TabAtkins> flackr: so I expect it to be safe, but experience will tell
16:43:48 <fantasai> TabAtkins: Just need to document this use case in the spec, to make clear that it works
16:43:50 <smfr> seems fine
16:44:04 <fantasai> ACTION: flackr to put example in the spec
16:44:13 <TabAtkins> astearns: proposal is position:sticky tracks the nearest scrolling container *per axis*
16:44:17 <TabAtkins> astearns: objections?
16:44:23 <TabAtkins> RESOLVED: position:sticky tracks the nearest scrolling container *per axis*
16:44:53 <TabAtkins> flackr: this is a long issue, there might be other use-cases but the two I mentioned seem to be the main ones
16:45:02 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/1525
16:45:02 <github-bot> Topic: [selectors] pseudo selector to match forms ValidityState
16:45:02 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/1525
16:45:37 <TabAtkins> astearns: Sebastian put this on the agenda but he's not here. there was a clarification he wanted to make. is anyone read up enough to talk about this?
16:46:00 <TabAtkins> astearns: skipping until Sebastian is available
16:46:08 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12495
16:46:08 <github-bot> Topic: [cssom-view] How to fulfill programmatic scroll promises?
16:46:08 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12495
16:46:24 <TabAtkins> flackr: we're resolved to have promises when you invoke scrolling methods
16:46:33 <TabAtkins> flackr: there were open questions about two main things, I think
16:47:09 <TabAtkins> flackr: one, in the original resolution we discussed having a way to tell the difference between a scroll that was interrupted and one that was completed. but that didn't make it into the spec text. we'd like to resolve the promise with a scroll result dictionary that tells the status
16:47:22 <TabAtkins> flackr: happy to bikeshed on the property for that
16:47:30 <TabAtkins> flackr: two, how to handle interruption of particular promises
16:47:35 <TabAtkins> flackr: points 2 and 3 in the issue
16:47:55 <TabAtkins> flackr: for 2, we expect only scrolls  that interrupt a particular scroller will resolve the promise for that scroller
16:48:27 <TabAtkins> flackr: for 3, a scroll promise for scrollIntoView is effectively like waiting for all the affected scrollers. so until all the scrolls are interrupted or completed it doesn't resolve. and when they are all resolved, we resolve the whole thing
16:48:30 <smfr> q+
16:48:33 <TabAtkins> q+
16:48:37 <astearns> ack smfr
16:48:56 <TabAtkins> smfr: i'm curious about scrollIntoView. on a nested scroller it might not scroll enclosing scrollers if they don't need to
16:49:07 <TabAtkins> smfr: so do they interrupt an ancestor scroll only *if* they need to change a position?
16:49:15 <TabAtkins> flackr: the intention is to track what the browser actually does with the scroll
16:49:36 <TabAtkins> flackr: so if you have an ongoing smooth scroll and you call scrollIntoView(), does it cancel the smooth scroll? If so, it should cancel the promise too
16:49:51 <TabAtkins> flackr: I believe it *should* cancel, you presumably want to stop the earlier scroll to honor the scrollIntoView request
16:49:53 <TabAtkins> smfr: seems reasonable
16:50:02 <ydaniv> q+
16:50:10 <TabAtkins> smfr: there's also a lot of logic in webkit to coalesce user scrolls
16:50:27 <TabAtkins> smfr: if you scroll with smooth and and then without smooth, the second clobbers. I guess that means the first is canceled
16:50:29 <TabAtkins> flackr: yes
16:50:33 <astearns> ack TabAtkins
16:50:50 <fantasai> TabAtkins: For scroll-into-view, are you planning to re-use existing promise machinery?
16:50:58 <fantasai> TabAtkins: so will get back array of scroll results, or something else?
16:51:33 <smfr> q+
16:51:37 <fantasai> flackr: Was thinking to have a single scroll result. Hard for developers to reason about an array
16:51:43 <fantasai> flackr: [missed]
16:51:50 <astearns> ack ydaniv
16:52:03 <TabAtkins> ydaniv: regarding rejecting the promise, a canceled scroll. should be consistent with how we reject on canceled animations, with aborterror
16:52:28 <TabAtkins> flackr: therew was a prior discussion on scroll promises where we're not rejecting them. it would raise compat issues due to a surprising new error
16:52:42 <TabAtkins> flackr: so we instead resolve successfully, with a result that says it's interrupted, not a rejection
16:52:45 <astearns> ack smfr
16:52:49 <TabAtkins> (agree, it's fine for this to be a non-exceptional result)
16:53:01 <TabAtkins> smfr: just checking, scrollIntoView() returns a promise?
16:53:03 <TabAtkins> flackr: yes
16:53:08 <TabAtkins> smfr: what about implicit ones like focus?
16:53:15 <TabAtkins> flackr: the dev can't get at that promise
16:53:26 <TabAtkins> smfr: okay, so you're not planning on exposing the indirect scrolls' promises
16:53:27 <TabAtkins> flackr: no
16:53:29 <TabAtkins> smfr: that's fine
16:53:51 <TabAtkins> astearns: are we going to resolve to let Rob do what he thinks is reasonable here, or be more explicit?
16:53:56 <emilio> More explicit is better :)
16:54:02 <emilio> But what rob said sounds good
16:54:09 <fantasai> TabAtkins: Everything Rob said sounds good, so happy to defer to him
16:54:26 <fantasai> PROPOSED: flackr to update spec with what he's outlined
16:54:36 <TabAtkins> RESOLVED: Rob update the spec per his comment. Can dig into particular details as needed.
16:55:36 <github-bot> Topic: [css-images-4] Add `light-dark-image()`, or generalize `light-dark()` for images too?
16:55:56 <fantasai> TabAtkins: We already have light-dark() for colors, makes it very convenient to write colors inline without indirection
16:56:13 <fantasai> TabAtkins: Similar request for other types of values, but the most important one is images. Identical use case to colors.
16:56:27 <fantasai> TabAtkins: a lot of agreement in the thread that this is a reasonable request
16:56:45 <fantasai> TabAtkins: proposal is that we either augment light-dark() to allow pair of colors OR pair of images, and resolves accordingly
16:56:54 <emilio> q+
16:56:59 <fantasai> TabAtkins: or we add a new function, light-dark-image(), same as light-dark() but accepts images instead
16:57:07 <astearns> q+
16:57:09 <fantasai> TabAtkins: Thread leans towards augmenting light-dark()
16:57:19 <fantasai> TabAtkins: There's further questions about allowint more values than just colors or images
16:57:27 <fantasai> TabAtkins: I prefer to not do that right now
16:57:35 <fantasai> TabAtkins: Partly because it has some parsing complications
16:57:51 <fantasai> TabAtkins: and also, we do have the ability to do that with if()
16:57:55 <fantasai> TabAtkins: and the use cases are rarer
16:58:10 <astearns> ack emilio
16:58:11 <fantasai> TabAtkins: So proposing to allow light-dark() to accept pair of images
16:58:24 <fantasai> emilio: I agree with Tab's proposal
16:58:27 <ydaniv> +1 TabAtkins
16:58:47 <fantasai> emilio: Third alternative is to make it an arbitrary substitution thing, but it makes problems especially for images
16:58:52 <fantasai> emilio: image caches, etc.
16:59:03 <fantasai> emilio: So keeping it simple, and if you want something complicated use if()
16:59:16 <fantasai> emilio: I haven't heard requests for any requests for anything else from FF frontend folks
16:59:51 <fantasai> astearns: So you implemented light-dark(<img>, <img>)?
16:59:55 <fantasai> emilio: yeah
17:00:04 <smfr> q+
17:00:06 <dbaron> Is there any complexity here about url() versus image() ?
17:00:10 <fantasai> astearns: I don't have a strong opinion on which way to go syntactically
17:00:25 <fantasai> astearns: Thinking about other extensions, overloading seems better than creating a new function per type
17:00:35 <fantasai> TabAtkins: If we branch out into more thing, grammar issues become more difficult.
17:00:39 <dbaron> (had to go, past 1pm)
17:00:51 <fantasai> TabAtkins: colors and images are 100% distinct (and should always be), but not doing that rn
17:00:58 <fantasai> TabAtkins: so we can address in the future
17:00:59 <astearns> ack smfr
17:01:10 <fantasai> smfr: People have been talking about URL arguments. Can you nest these?
17:01:12 <fantasai> emilio: Yes
17:01:21 <fantasai> emilio: And you can have the color version inside your gradient
17:01:47 <fantasai> emilio: could even nest that inside the image light-dark
17:01:55 <fantasai> [seems weird but doable]
17:02:05 <fantasai> PROPOSED: Overload light-dark() to accept image pairs
17:02:12 <fantasai> RESOLVED: Overload light-dark() to accept image pairs
17:02:16 <smfr> present+
17:03:36 <astearns> topic: end
17:03:44 <astearns> zakim, end meeting
17:03:44 <Zakim> As of this point the attendees have been TabAtkins, romain, kbabbitt, dbaron, ydaniv, bramus, dshin-moz, kizu, emilio, miriam, alisonmaher, flackr, jbreiland, PaulG, vmpstr,
17:03:47 <Zakim> ... andreubotella, smfr
17:03:47 <Zakim> RRSAgent, please draft minutes v2
17:03:49 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/11-css-minutes.html Zakim
17:03:55 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
17:03:55 <Zakim> Zakim has left #css
17:05:50 <jamesn> jamesn has joined #css
21:04:16 <Linux_Kerio> Linux_Kerio has joined #css
23:53:10 <Linux_Kerio> Linux_Kerio has joined #css