14:58:30 <RRSAgent> RRSAgent has joined #css
14:58:34 <RRSAgent> logging to https://www.w3.org/2025/09/24-css-irc
14:58:34 <Zakim> RRSAgent, make logs Public
14:58:35 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
14:59:42 <lea> lea has joined #css
15:01:14 <kbabbitt> kbabbitt has joined #css
15:01:22 <kizu> kizu has joined #css
15:01:36 <kizu> present+
15:01:39 <oriol> oriol has joined #css
15:01:48 <kbabbitt> present+
15:02:07 <ydaniv> ydaniv has joined #css
15:02:24 <oriol> present+
15:02:59 <fantasai> fantasai has joined #css
15:06:05 <fantasai> fantasai has joined #css
15:06:28 <fantasai> Topic: CSS Values Level 5
15:06:32 <fantasai> Agenda: https://lists.w3.org/Archives/Public/www-style/2025Sep/0015.html
15:06:37 <fantasai> ScribeNick: fantasai
15:06:40 <ydaniv> present+
15:06:57 <github-bot> Subtopic: [css-values] attr()'s url type seems wrong
15:07:16 <emilio> present+
15:07:16 <miriam> present+
15:08:00 <lea> present+
15:08:00 <fantasai> annevk: attr() started supporting types allowing to parse attributes according to specified CSS types
15:08:09 <fantasai> annevk: Some issues here.
15:08:19 <fantasai> annevk: One was about passing the base URL along. Some discussion about that, forget the outcome.
15:08:43 <annevk> annevk has joined #css
15:08:59 <fantasai> astearns: Munira suggested making the type invalid
15:09:10 <fantasai> annevk: That is my preferred solution as well
15:09:34 <emilio> q+
15:09:40 <fantasai> annevk: Resolving as document stylesheet maybe works. But if you resolve and serialize, it ends up as all ASCII, which is all Western-centric. Not what you want to print.
15:09:53 <fantasai> annevk: like domain name would become pyunicode
15:10:05 <fantasai> annevk: If you want it as a formatting feature, you'd need to add a converter function
15:10:15 <fantasai> annevk: which we haven't exposed previously, and has security implications
15:10:23 <fantasai> annevk: Browsers have not yet converged on a single algorithm for that operation
15:10:34 <astearns> ack emilio
15:10:41 <fantasai> emilio: Multiple base URL is not an issue.
15:10:48 <fantasai> emilio: That said, I don't disagree with making it invalid.
15:10:56 <fantasai> annevk: So you'd parse it for each document separately?
15:11:07 <fantasai> emilio: attr() is substituted at computed value time, so you need to have the element and the document
15:11:13 <fantasai> annevk: So when you compute the value, you parse the attribute value
15:11:14 <fantasai> emilio: Yes
15:11:27 <fantasai> emilio: You can optimize some cases but basically yes
15:11:35 <fantasai> annevk: So you go into CSSOM, you get attr()
15:11:49 <fantasai> emilio: The stylesheet has a base URL of its own, but it's not the base URI we're talking about here.
15:12:02 <fantasai> annevk: Does the CSSOM have an object representing attr() you can query?
15:12:05 <fantasai> emilio: Maybe with typed OM
15:12:12 <fantasai> emilio: But you don't know which element you're applying the function to
15:12:21 <fantasai> emilio: It's likely that idk about typed OM internals much
15:12:29 <fantasai> emilio: but I imagine it presents as a function value with a keyword inside
15:12:34 <fantasai> emilio: Might be a string or whatever
15:12:45 <fantasai> emilio: But it's tangential. You can share a stylesheet across multiple docs without an issue
15:13:06 <fantasai> astearns: Problem is that making invalid breaks print formatters
15:13:33 <fantasai> annevk: Yeah, some want to do things like print URL of the link. But then you run into the i18n problem. Only works well for ASCII inputs, and that doesn't feel responsible to standardize
15:13:44 <emilio> scribe+
15:13:45 <astearns> ack fantasai
15:14:04 <emilio> fantasai: was it the case that the existing formatters use a different syntax? In which case making type(<url>) invalid wouldn't change anything?
15:14:17 <emilio> ... presumably they are stuck on whatever syntax they support
15:14:38 <emilio> ... seems we could try to standardize what they support but dropping type() from the spec shouldn't change it
15:14:46 <emilio> ... but agreed we shouldn't break their existing content
15:14:49 <emilio> ... that'd be bad
15:15:10 <fantasai> annevk: Unclear if they support the current syntax
15:15:45 <fantasai> astearns: Could take a resolution that `type(<url>)` is invalid, hoping print formatters are not using that syntax yet?
15:16:02 <fantasai> TabAtkins: I'm happy with that.
15:16:20 <fantasai> TabAtkins: We can also put an allowance for e.g. non-security-sensitive uses such as printing
15:16:38 <fantasai> annevk: Not so much security, but i18n concern
15:16:50 <fantasai> annevk: If the idea of this function is to display the URL, then we should have a good way of displaying
15:17:11 <fantasai> annevk: If we just echo the value, then it will work for Western docs but fall apart everywhere else
15:17:16 <fantasai> annevk: In which case I'd rather avoid
15:17:27 <fantasai> annevk: making something that works for a subset of the world
15:17:45 <fantasai> astearns: By making invalid now, not blocking a future where we figure out how to make it work well for i18n
15:17:56 <fantasai> annevk: Yes. We should probably get there eventually. Just not a priority to figure out for anyone atm
15:18:05 <fantasai> astearns: Ok, let's take a resolution and see how Mike responds to it.
15:18:24 <fantasai> PROPOSED: Make type(<url>) invalid in the attr() function (for now).
15:18:26 <TabAtkins> +1
15:18:40 <fantasai> RESOLVED: Make type(<url>) invalid in the attr() function (for now).
15:19:08 <TabAtkins> scribe+
15:19:13 <github-bot> Subtopic: [css-values-5] Computed (vs used) value of mix() functions
15:19:38 <TabAtkins> fantasai: we have mix() that compute a weighted average from a list of items and %s
15:19:51 <TabAtkins> fantasai: sometimes you can compute it to a final value, others you need to keep values distinct until used value time
15:19:57 <TabAtkins> fantasai: we have two ways of simplifying we could take
15:20:08 <TabAtkins> fantasai: one is to simplify as much as possible, including collapsing some items in the list
15:20:20 <TabAtkins> fantasai: or we can just simplify each argument, preserving the number of items
15:20:38 <TabAtkins> fantasai: so your computed value serialization would be either a single value, or a list with same number of items as previous. no halfway point like in the first option
15:20:51 <emilio> I think whatever calc() does?
15:20:53 <TabAtkins> fantasai: currently we've specced the second option since it seems simpler, wanted opinions
15:20:58 <TabAtkins> calc() does first options
15:21:04 <TabAtkins> astearns: doesn't first option lose info?
15:21:20 <TabAtkins> astearns: how would I be able to look at list of values and get an average if I didn't know how many itmes where there?
15:21:30 <TabAtkins> fantasai: each item has a weight, so your combined item has the combined weight
15:21:34 <TabAtkins> fantasai: [gives example]
15:21:45 <TabAtkins> astearns: ah, makes sense
15:21:56 <lea> no opinion either
15:22:12 <TabAtkins> astearns: slight preference for second, it preserves more of author intent
15:22:16 <TabAtkins> astearns: and this is hopefully an edge case
15:22:24 <lea> +1
15:22:32 <kbabbitt> also lean slightly toward option 2
15:22:38 <emilio> q+
15:22:38 <TabAtkins> TabAtkins: Emilio commented in chat, seemed to lean option 1
15:22:48 <astearns> ack emilio
15:22:56 <TabAtkins> emilio: is there a reason to not be consistent with calc? max simplification?
15:23:08 <lea> What does min()/max() do? That might be a better precedent than calc() as it has multiple arguments too
15:23:13 <TabAtkins> fantasai: calc() is hierarchical, you kinda combine things that are adjacent until they can't be combined any more
15:23:36 <TabAtkins> fantasai: in mix(), if first and last can be combined, middle can't, you'll get a combined item that has to go first or last...
15:23:48 <TabAtkins> emilio: I think we should simplify nested mix() if possible, and that bubbles
15:24:01 <TabAtkins> fantasai: yes, if you can collapse a mix() into one value, you do that. this is if at least one item can't be combined
15:24:09 <TabAtkins> emilio: ah kk, thought you were never simplifying
15:24:17 <TabAtkins> fantasai: nah, just if one item can't be simplified
15:25:00 <fantasai> TabAtkins: min()/max() simplify by combining items, so that's a precedent
15:25:08 <fantasai> TabAtkins: from some feedback from smfr back in the day
15:25:25 <TabAtkins> astearns: should we go with option 1 then, for precedent?
15:25:40 <TabAtkins> fantasai: it's a little easier for min/max since you just drop some, while here you have to change values, but it's certainly doable
15:25:54 <TabAtkins> astearns: so proposed is to simplify as much as possible (combining items when it can) for computed value
15:26:21 <TabAtkins> fantasai: I feel like manipulating the result will be odd, but...
15:26:22 <TabAtkins> RESOLVED: simplify as much as possible (combining items when it can) for computed value
15:26:43 <github-bot> Subtopic: [css-values-5] Allow `if()` in descriptors
15:27:28 <fantasai> TabAtkins: We have if() function which allows conditional tests. But only works in properties, because substitution functions are only defined in that context
15:27:46 <fantasai> TabAtkins: but there are good use cases for being able to use if() with global tests like MQ
15:27:57 <fantasai> TabAtkins: It could be done by using conditional at-rules today
15:28:00 <lea> q?
15:28:11 <fantasai> TabAtkins: if() is a nice syntactic convenience.
15:28:24 <fantasai> TabAtkins: Anders says it's doable as long  as we're clear which tests can be used outside an element ocntext
15:28:41 <fantasai> TabAtkins: I agree, should be useful. Right now just style query and color scheme query that we'd have to turn off. But doable
15:28:52 <fantasai> TabAtkins: So I suggest we accept this feature, spec text TBD
15:28:53 <lea> +1, many upsides, little to no downsides
15:28:59 <astearns> ack fantasai
15:29:08 <TabAtkins> fantasai: I think it makes sense, but rather than excluding we should use an allowlist
15:29:10 <emilio> q+
15:29:12 <TabAtkins> TabAtkins: agree
15:29:18 <lea> q+
15:29:23 <TabAtkins> fantasai: like there's a lot of variable stuff we can't do outside of an element context
15:29:24 <astearns> ack emilio
15:29:39 <fantasai> emilio: relatedly, there might be descriptors (e.g. @font-face) ...
15:29:53 <fantasai> emilio: even in the case in the OP, @font-face is exposed to the FontFace API
15:30:01 <fantasai> emilio: It's fairly different from media case
15:30:08 <fantasai> emilio: I'm not sure how we should expose these values when you ask for them
15:30:14 <fantasai> emilio: Seems weird to do the substitution when you do the getter
15:30:20 <fantasai> emilio: requires updating style information, it's a bit annoying
15:30:29 <fantasai> TabAtkins: currently those return strings
15:30:32 <fantasai> TabAtkins: so I think it's fine?
15:30:41 <fantasai> TabAtkins: we'd have to define how substitutions are reflected
15:30:51 <fantasai> TabAtkins: and I think it's fine to say that the OM doesn't reflect substitutions
15:31:26 <fantasai> emilio: That means the programmatic functions need to accept these, and those are exposed to workers, which is annoying
15:31:41 <fantasai> emilio: There's a lot of edge cases to think about
15:31:46 <fantasai> emilio: And that's just the @font-face ones
15:32:06 <fantasai> emilio: And then @page stuff might affect MQ?
15:32:18 <fantasai> astearns: So seems useful thing, but complications to work through.
15:32:27 <astearns> ack lea
15:32:38 <fantasai> lea: Do we need to exclude variables syntactically?
15:32:54 <fantasai> lea: Could define that variables resolve to their initial value.
15:32:58 <fantasai> lea: idk if web compatible
15:33:05 <fantasai> lea: but as an author, that's what I would expect
15:33:16 <fantasai> TabAtkins: I would say that those tests, not on allow list, would just resolve to false
15:33:25 <fantasai> TabAtkins: that would potentially allow us to turn on some tests in the future
15:33:36 <astearns> ack fantasai
15:34:08 <TabAtkins> fantasai: given all that, I think we should maybe defer this to later... I don't want us to spend tons of times going down the rabbit holes and delaying if() on elements
15:34:38 <TabAtkins> fantasai: so maybe say this is a good idea, but for the next level. sounds like it'll be a bunch of work on the spec and impl side, for something that is technically doable right now in other ways
15:34:44 <emilio> +1
15:34:50 <TabAtkins> fantasai: so I worry if we batch it all together it'll be slower to get the core feature interoperable
15:35:08 <TabAtkins> astearns: so we could resolve to accept it but punt to the next level. no more delay needed
15:35:15 <TabAtkins> astearns: agree we shoudln't gate the existing if() on this
15:35:16 <TabAtkins> +1
15:35:30 <fantasai> PROPOSED: Work on this in the next level.
15:35:48 <fantasai> RESOLVED: Work on this in the next level (in consideration of all the complications outlined above).
15:36:03 <github-bot> Subtopic: [css-values-5] Clarify how `<attr-unit>` should be parsed
15:36:33 <fantasai> TabAtkins: Right now stuff for <attr-unit> production says "take this numerical attribute and pretend it's a pixel value"
15:36:39 <fantasai> TabAtkins: says to parse it as a <number>
15:36:52 <fantasai> TabAtkins: How literal are we about that? Is it a NUMBER token from Syntax? Or a <number> value from values?
15:36:57 <fantasai> TabAtkins: the latter allows all the math functions
15:37:11 <fantasai> TabAtkins: we need to clarify the spec in either direction
15:37:22 <fantasai> TabAtkins: an earlier version of extended attr() was very specifically only looking for number tokens
15:37:32 <fantasai> TabAtkins: for implementation simplicity reasons
15:37:46 <fantasai> TabAtkins: it solved the use cases and was easy to do
15:37:57 <fantasai> TabAtkins: as you allow more complicated things, it becomes more complicated
15:38:12 <fantasai> TabAtkins: probably not worse than allowing more complexity in other values?
15:38:26 <fantasai> TabAtkins: originally we added calc(), and then a jillion more math functions
15:38:34 <astearns> ack fantasai
15:38:40 <TabAtkins> fantasai: this brings up interesting q
15:39:00 <TabAtkins> fantasai: do we want to distinguish between CSS types (which should parse as full CSS) but have a different syntax for simple things
15:39:03 <TabAtkins> fantasai: like "just a number"
15:39:11 <emilio> q+
15:39:40 <TabAtkins> fantasai: for some core types like number... for string type we have a special type that doesn't do CSS parsing and just uses the attr value, so we already have cases for this distinction
15:39:55 <TabAtkins> fantasai: so maybe this is a case where we distinguish
15:40:10 <TabAtkins> fantasai: if you want CSS length values, use type(<length>), if you want CSS numbers, use type(<number.)
15:40:19 <TabAtkins> fantasai: but if you just want a number interpreted as px, use this other syntax
15:40:31 <TabAtkins> fantasai: and maybe that syntax is just the syntax we had before, with the keywords
15:40:34 <astearns> ack emilio
15:40:42 <fantasai> emilio: What is the behavior with custom properties?
15:40:52 <fantasai> emilio: I would assume you ? parse calc() there
15:40:58 <fantasai> emilio: consistency with that would be fair
15:41:25 <TabAtkins> fantasai: this would mean any type() annotation is consistent with properties, but attr() would allow some extra things
15:41:33 <TabAtkins> emilio: agree that a raw number makes sense
15:41:52 <TabAtkins> fantasai: yeah, raw number with a unit appended, and a raw string, those are the special things we should be able to do
15:42:11 <TabAtkins> astearns: we could take a resolution to define the type() parsing and have a new issue for extending the attr() for these raw types
15:42:25 <fantasai> TabAtkins: This issue is about the unit keywords, not type() function
15:42:46 <fantasai> TabAtkins: I'm happy with the proposal, where type keywords work for raw values, and anything with type() function is a CSS parse.
15:42:56 <fantasai> TabAtkins: Probably means we want to add one more keyword for number, for raw numbers
15:43:14 <fantasai> TabAtkins: currently we have raw-string, all the units, and %
15:43:29 <fantasai> fantasai: so you're proposing raw-number?
15:43:54 <emilio> q+
15:44:15 <TabAtkins> proposed: all the unit/% keywords are "raw number" - only a literal number. Add raw-number that's the same without a unit. All type() values are CSS-parsed, so type(<number>) allows calc()/etc
15:44:24 <fantasai> PROPOSED: type() values are parsed just as in custom properties. Other attr() type values (units % etc) areliterals.
15:44:27 <astearns> ack emilio
15:44:50 <fantasai> emilio: seems fair. I wish the keyword was just 'number'. It's a fairly common use cases, and 90% of use cases would be covered by it.
15:44:59 <fantasai> emilio: raw-string is the default, so right now you don't have to type it
15:45:05 <fantasai> TabAtkins: I'm fine with plain 'number'.
15:45:36 <fantasai> PROPOSED: type() values are parsed just as in custom properties. Other attr() type values (units % etc) are literals. Add a 'number' keyword for literal numbers.
15:45:46 <fantasai> RESOLVED: type() values are parsed just as in custom properties. Other attr() type values (units % etc) are literals. Add a 'number' keyword for literal numbers.
15:46:08 <github-bot> Subtopic: [css-values-5] Using `if()` to do dark/light switching of image urls.
15:46:43 <fantasai> astearns: proposed to add a color-scheme() test to if()
15:47:00 <emilio> q+
15:47:06 <fantasai> fantasai: is that cyclic?
15:47:07 <TabAtkins> add color-scheme() test to if(), which tests the used color scheme on the element
15:47:11 <astearns> ack emilio
15:47:27 <fantasai> emilio: should we look at inherited value?
15:47:38 <fantasai> TabAtkins: not cyclic because not looking at color-scheme property
15:47:50 <fantasai> s/not looking at/wouldn't work on
15:48:05 <fantasai> TabAtkins: Looking at parent color-scheme wouldn't be useful.
15:48:15 <fantasai> TabAtkins: It's not a complicated dependency, so should be straightforward.
15:48:23 <fantasai> TabAtkins: we can make color-scheme() test fail in color-scheme property.
15:48:34 <fantasai> emilio: There are typed custom properties as well...
15:48:49 <fantasai> TabAtkins: We already have spec mechanisms to handle arbitrarily complex dependency chains accurately
15:48:55 <fantasai> TabAtkins: this would add a dependency in
15:49:08 <fantasai> TabAtkins: same as using a style test depends on custom property
15:49:25 <fantasai> TabAtkins: thing to be concerned about is if likely that future language editions would create cycles that aren't already present
15:49:35 <fantasai> TabAtkins: but I think it's safe to say that color-scheme won't depend on anything in the future
15:49:49 <astearns> ack fantasai
15:49:50 <TabAtkins> fantasai: I defer to impls on implementability
15:50:10 <TabAtkins> fantasai: but if we'll have special behavior on color-scheme prop to have it work, we should do the same as font-size/em
15:50:23 <TabAtkins> fantasai: it also makes a somewhat useful thing - you can do the opposite color scheme of your parent
15:50:43 <fantasai> astearns: Question of whether to add color-scheme() to container queries as well
15:50:58 <fantasai> fantasai: if we're doing the hard one we should do the easy one :)
15:51:02 <lea> +1 for color-scheme() on color-scheme resolving to parent color-scheme. I wish we had done that with var() too
15:51:03 <fantasai> TabAtkins: Agree we should keep them in sync.
15:52:06 <fantasai> PROPOSED: Add color-scheme() test to both @container queries and if(). Open question on what color-scheme() checks when in the color-scheme property.
15:52:48 <fantasai> fantasai: Can we just resolve on the color-scheme() checks parent color-scheme?
15:53:00 <fantasai> TabAtkins: unsure, let's leave it unresolved and discuss in other issue
15:53:28 <fantasai> RESOLVED: Add color-scheme() test to both @container queries and if(). Open issue on what color-scheme() returns when used in color-scheme property.
15:53:54 <github-bot> Subtopic: [css-values-5] *-interpolate() grammar can lead to confusing values
15:54:25 <fantasai> TabAtkins: kbabbitt noted that the interpolate puts the value we're interpolating first, then options, then a list of stops
15:54:41 <fantasai> TabAtkins: he points out that this looks confusing because some of the options can be affecting output values
15:54:42 <TabAtkins> background-color: color-interpolate(300px in hsl, 200px: red, 500px: green, 600px: blue);
15:54:48 <una> una has joined #css
15:54:50 <fantasai> TabAtkins: but are placed next to the input value
15:55:06 <fantasai> TabAtkins: 300px in hsl loos like it's modifying 300px
15:55:14 <fantasai> TabAtkins: wanted to see if we could rearrange syntax to make it less confusing
15:55:17 <noamr> noamr has joined #css
15:55:28 <fantasai> TabAtkins: oriol's suggestion was to put the options first
15:55:29 <TabAtkins> color-interpolate(in hsl / 300px, 200px: red, 500px: green, 600px: blue)
15:56:00 <fantasai> TabAtkins: this puts the options close to the 'interpolate(' word
15:56:10 <lea> q+
15:56:18 <fantasai> TabAtkins: uses a slash to separate the value out, to avoid syntactic ambiguity
15:56:18 <astearns> ack lea
15:56:41 <fantasai> lea: Not a strong objection, but I would prefer to avoid mixing slashes vs commas, because CSS is inconsistent in how it handles it
15:56:52 <fantasai> lea: can we use a keyword?
15:56:58 <lea> color-interpolate(in hsl at 300px, 200px: red, 500px: green, 600px: blue)
15:57:00 <astearns> ack fantasai
15:57:02 <oriol> q+
15:57:17 <TabAtkins> fantasai: I haven't looked at this issue, but here's a wild idea. all the other values have a colon, what if you said `300px: in hsl`
15:57:26 <lea> q+
15:57:27 <TabAtkins> fantasai: so the first value is what we're interpolating, and options for the values
15:57:29 <lea> qq+
15:57:31 <astearns> ack oriol
15:57:36 <PaulG5> PaulG5 has joined #css
15:57:52 <fantasai> oriol: Another point is, I believe we can just use a comma as a separator as there's no grammar overlap
15:57:53 <TabAtkins> oriol: something else I was saying is I think we can just use a comma as a separator, ther'es no grammar overlap
15:58:07 <TabAtkins> oriol: agree with Lea that mixing slash and comma is a bit weird. so I think we can just use a comma
15:58:09 <astearns> ack lea
15:58:09 <Zakim> lea, you wanted to react to fantasai
15:58:22 <fantasai> lea: Syntactically we want to distinguish prelude from list
15:58:27 <fantasai> lea: So we want it to not look the same
15:58:30 <TabAtkins> lea: to Elika, syntactically we want to distinguish the prelude from the other arguments. the more similar it is to other args the worse the readability is, I think
15:58:36 <emeyer> emeyer has joined #css
15:58:43 <astearns> ack lea
15:58:53 <TabAtkins> fantasai: I don't love having them in a different order. putting the value, the core thing you're acting on, last...
15:58:57 <lea> `color-interpolate(at 300px in hsl, 200px: red, 500px: green, 600px: blue)` seems ok to me?
15:59:04 <TabAtkins> fantasai: it's also often not '300px', it's something complicated like a var()
15:59:14 <TabAtkins> fantasai: it's one of the most important parts of the function, the first thing you'll think about
15:59:48 <fantasai> astearns: Sounds like we don't have consensus on a direction yet.
16:00:18 <fantasai> RESOLVED: Explore options for making a syntactic distinction between input and interpolation options.
16:00:38 <fantasai> Topic: Main CSS Call - Administrative
16:01:07 <dholbert> dholbert has joined #css
16:01:21 <romain> romain has joined #css
16:01:25 <futhark> futhark has joined #css
16:01:25 <romain> present+
16:01:33 <kbabbitt> present+
16:01:38 <jfkthame> jfkthame has joined #css
16:01:46 <rachelandrew> present+
16:01:46 <futhark> present+
16:02:05 <Kurt> Kurt has joined #css
16:02:09 <bramus> present+
16:02:15 <jfkthame> present+
16:02:17 <alisonmaher> alisonmaher has joined #css
16:02:20 <ydaniv> present+
16:02:22 <alisonmaher> present+
16:02:24 <dholbert> present+
16:02:41 <fantasai> Subtopic: Winter F2F Dates - Poll
16:02:45 <fantasai> -> https://app.rallly.co/poll/JVvrK6xuIeIK
16:02:57 <fantasai> fantasai: Reminder to fill out the poll for dates so we can plan the winter F2F!
16:02:59 <bkardell> bkardell has joined #css
16:03:09 <djmarland> djmarland has joined #css
16:03:09 <fantasai> Topic: Publications
16:03:16 <astearns> github-bot, subtopic https://github.com/w3c/csswg-drafts/issues/12756
16:03:16 <github-bot> Subtopic: Updated WD of CSS Images 4
16:03:16 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12756.
16:03:34 <Kurt> present+
16:03:45 <castastrophe> castastrophe has joined #css
16:03:49 <castastrophe> present+
16:03:57 <djmarland> present+
16:04:07 <fantasai> RESOLVED: Update WD of css-images-4
16:04:29 <TabAtkins> ScribeNick: TabAtkins
16:04:31 <flackr> flackr has joined #css
16:04:36 <flackr> present+
16:04:45 <TabAtkins> ChrisL: other is flexbox
16:04:56 <TabAtkins> fantasai: last I checked, it needed Changes compiled, and I haven't finished that
16:05:06 <TabAtkins> ChrisL: we were waiting on an edit from you, and you posted that you'd done it
16:05:13 <TabAtkins> fantasai: yes. so now it' just compile the changes list and publish
16:05:26 <lea> present+
16:05:34 <TabAtkins> astearns: so let's get that Changes list updated, we'll come back to CRD when it is
16:05:36 <emeyer> present+
16:05:38 <bkardell> present+
16:05:50 <fantasai> fantasai has changed the topic to: https://lists.w3.org/Archives/Public/www-style/2025Sep/0016.html
16:05:56 <ChrisL> present+
16:05:59 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12218
16:05:59 <github-bot> Topic: [css2][css-flow][css-sizing] How do min/max block sizes affect bottom margin collapse with last child?
16:05:59 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12218.
16:06:03 <DavidA> DavidA has joined #css
16:06:10 <djmarland> present+
16:06:17 <DavidA> present+
16:06:27 <miriam> present+
16:06:33 <TabAtkins> oriol: a container can collapse its bottom margins with its contents bottom margins *if* the height property computes to auto (plus border/padding/etc)
16:06:47 <TabAtkins> oriol: but it's not clear how min-height and max-height should affect that
16:07:13 <TabAtkins> oriol: beahvior in webkit and servo is they just check 'height'. if it's auto, they collapse. even if min-height is large enough that the margins dont' overlap
16:07:24 <TabAtkins> oriol: I dont' think this makes sense, want to change to match gecko and blink
16:07:38 <TabAtkins> oriol: they check that the final height is the intrinsic height, and only allow collapsing bottom margins in that case
16:07:57 <TabAtkins> oriol: some weird things. intrinsic height is 20px, max-height:0, min-height:20, the heights will match
16:08:18 <TabAtkins> oriol: but the height that actually wins is an extrinsic height. if specified in 'height', that would prevent collapsing
16:08:32 <TabAtkins> oriol: also not clear how this works with the intrinsic keywords in the *-height props
16:08:40 <TabAtkins> oriol: Ian has a proposal in the issue which sounds fine to me
16:08:49 <TabAtkins> oriol: we just stop checking that the height computes to auto
16:09:08 <TabAtkins> oriol: instead we first resolve intrinsic height, not including end margins of contents, then check the actual height, and if they're the same we allow collapse
16:09:15 <TabAtkins> oriol: I think this is fine, so long as it's web compatible
16:09:29 <TabAtkins> oriol: not sure if Ian's on the call, but I suppose he's willing to try it
16:09:52 <TabAtkins> iank_: yes, i'm willing. scariest thing I can think of is if you have a container with height:100px, and a direct child with height:100% and margins, that margin will start poking out.
16:10:08 <TabAtkins> iank_: it already pokes out the top, so there's at least symmetry. it's a relatively simple change for us so we're willing to try it out
16:10:24 <TabAtkins> oriol: so I guess we can resolve, and if it's not web-compat we can revisit
16:10:29 <TabAtkins> fantasai: checking understanding...
16:10:39 <TabAtkins> fantasai: you set height to 20px and intrinsic size happens to be 20px, you'd collapse margins
16:10:46 <TabAtkins> fantasai: but setting to 21px wouldn't allow collapse
16:10:49 <TabAtkins> oriol: yeah
16:11:02 <TabAtkins> fantasai: that seems like a problem if you're animating between values, just as you touch the intrinsic height
16:11:07 <emilio> q+
16:11:15 <TabAtkins> fantasai: so I think it's not great
16:11:20 <TabAtkins> fantasai: but sympathize with simplifying the logic
16:11:59 <TabAtkins> oriol: good point. maybe instead of completely dropping the height:auto condition... we could keep it but
16:12:30 <TabAtkins> oriol: for example, non-zero padding bottom. that prevents collapsing bottom margins. then you include the content margins into intrinsic height
16:12:54 <TabAtkins> oriol: I think if height also prevents collapsing bottom margins, we should also include bottom margins in intrinsic height
16:12:58 <TabAtkins> iank_: not wild about that
16:13:10 <TabAtkins> iank_: note we already have the problem Elika brings up with animating max-height
16:13:17 <TabAtkins> iank_: and animating max-height is quite common
16:13:23 <astearns> ack emilio
16:13:33 <TabAtkins> emilio: and you almost always clip due to it being a BFC anyway
16:13:52 <TabAtkins> fantasai: with max-height you don't have a single point, you have a flip point where you go from collapsing to not collapsing
16:14:03 <TabAtkins> fantasai: this behavior is weird because you collapse at only one single point
16:14:24 <TabAtkins> astearns: is that weirdness worse than the current, where things collapse or not only based on whether you have height:auto set?
16:14:35 <TabAtkins> fantasai: I think that's worse, yeah. happy to extend the height:auto stuff to include intrinsic sizes
16:14:43 <TabAtkins> fantasai: especially in block layout, all the intrinsics are equivalent
16:15:03 <TabAtkins> fantasai: and height:auto is interesting because it's.... your BFC won't collapse anyway
16:15:13 <TabAtkins> fantasai: I think if you have any kind of intrinsic size on height you can be allowed to collapse
16:15:13 <TabAtkins> q+
16:15:21 <TabAtkins> fantasai: but if your height value is a fixed size it shoudln't clamp
16:15:33 <TabAtkins> iank_: if we go down this route i'd like to do what blink does
16:15:48 <TabAtkins> iank_: we take the initial block size, and see if that's definite or not. that's subtlety different from checking the keywords
16:16:11 <TabAtkins> iank_: we try to resolve the b lock size with no intrinsic sizes, there's rules that fall out of that. calc-size() complicates, for example. and if that's indefinite we allow collapsing margins
16:16:15 <TabAtkins> fantasai: not sure I understand
16:16:40 <TabAtkins> iank_: it's close... the reason we've gotten into this situation is the rule was written with css2 in mind, where only 'auto' was intrinsic
16:16:48 <TabAtkins> iank_: we've added so much more, especially calc-size()
16:17:05 <TabAtkins> iank_: so the current thing we do in blink is in each layout, you always calculate an intrinsic block size
16:17:15 <TabAtkins> iank_: i'd like to use the same logic here for margins
16:17:30 <TabAtkins> fantasai: followed until the last
16:17:44 <TabAtkins> iank_: so we calculate the initial block size. if it's indefinite, we allow collapsing margins
16:17:51 <TabAtkins> fantasai: is "initial block size" - what is it?
16:18:07 <TabAtkins> iank_: at the start of every layout algo you compute this size...
16:18:12 <TabAtkins> fantasai: say a <p>, what's the initial
16:18:18 <TabAtkins> iank_: indefinite, since those are height:auto
16:18:44 <fantasai> scribe+
16:18:45 <astearns> ack TabAtkins
16:18:47 <antonp> antonp has joined #css
16:19:08 <fantasai> TabAtkins: Ian's brought up calc-size() a few times. I want to make sure calc-size( auto, 20px) is not meaningfully different from 20px
16:19:21 <fantasai> TabAtkins: that should act, for all purposes, the same of having an actual intrinsic size of 20px
16:19:30 <fantasai> TabAtkins: but because directly specifying 20px, would be nice if it matched 20px directly
16:19:43 <fantasai> TabAtkins: but those should be the same, I think
16:19:50 <astearns> ack fantasai
16:19:59 <TabAtkins> fantasai: I was gonna say opposite. it might make sense to have calc-size() always allow margin to collapse
16:20:08 <TabAtkins> fantasai: the same as if it was just "auto"
16:20:43 <TabAtkins> fantasai: margin collapse is just real weird with min/max etc. you can have margins collapse that aren'ta actually lined up, if you imagine margins as a transparent boundary around the element, because partial collapse doesn't exist. they either collapse or don't.
16:20:55 <TabAtkins> fantasai: so having calc-size() behave as always collapse probably makes sense to me
16:21:04 <TabAtkins> astearns: we're finding more ways to disagree, let's take this back to the issue
16:21:18 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12220
16:21:18 <github-bot> Topic: [css-align] Does `vertical-align` on table cell set `align-content` safely or not?
16:21:18 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12220.
16:21:42 <TabAtkins> oriol: when align-content:normal on table-cell, spec says to use vertical-align
16:21:50 <TabAtkins> oriol: so v-a:bottom acts like a-c:end
16:22:01 <TabAtkins> oriol: in some corner cases it might be possible to have contents of a table cell overflow the cell
16:22:16 <TabAtkins> oriol: these corners cases aren't very interoperable, but I could trigger them in both blink and webkit
16:22:23 <TabAtkins> oriol: wondering if these alignments, then should be safe or not
16:22:41 <TabAtkins> oriol: spec doesn't say whether it's safe or not, so I suppose eit's the default safety
16:22:47 <TabAtkins> oriol: but browsers dont' agree with that or each other
16:22:53 <TabAtkins> oriol: Gecko I coudln't trigger overflow anyway
16:23:00 <TabAtkins> oriol: fantasai said probably safe is better, i'm fine with that
16:23:09 <TabAtkins> fantasai: in general a lot of css2 stuff did safe overflow
16:23:21 <TabAtkins> fantasai: it's a better default behavior in many cases
16:23:31 <TabAtkins> fantasai: so given it's a legacy behavior, i'd prefer safety for vertical-align
16:23:34 <TabAtkins> astearns: other comments?
16:23:59 <TabAtkins> oriol: proposed resolution: when resolving align-content:normal on a table cell, we use safe alignment
16:24:08 <TabAtkins> astearns: concerns?
16:24:30 <TabAtkins> RESOLVED: when resolving align-content:normal on a table cell, we use safe alignment
16:24:40 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10937
16:24:40 <github-bot> Topic: [css-tables][css-sizing] What sizing keywords allow fixed table mode?
16:24:40 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10937.
16:25:17 <TabAtkins> iank_: we had a resolution to just have width:auto trigger fixed table layout
16:25:33 <TabAtkins> iank_: this isn't web-compat, there's a library that sets width:max-content on tables and assumes they'll go into fixed mode
16:25:44 <TabAtkins> iank_: so my proposal is we have width:auto *or* max-content, we trigger fixed layout.
16:25:53 <TabAtkins> iank_: not including a calc-size(), it's those keywords literally
16:26:01 <TabAtkins> astearns: so just adding one more condition to the list?
16:26:02 <TabAtkins> iank_: yes
16:27:04 <TabAtkins> oriol: correction, auto/max-content *prevent* fixed layout.
16:27:35 <TabAtkins> fantasai: so you can set table-layout to fixed or auto. if you set 'fixed', but width is 'auto' (or, proposed, max-content), you'll instead get auto layout.
16:27:48 <TabAtkins> fantasai: can we instead just say that only extrinsic sizes allow fixed?
16:27:56 <TabAtkins> iank_: no, doesn't work
16:28:07 <TabAtkins> oriol: also if we add more conditions it's harder to opt into this behavior
16:28:24 <emilio> So we're resolving on Gecko's behavior right?
16:28:34 <TabAtkins> astearns: so proposed resolution: add max-content to the list of exceptions that prevent table-layout:fixed
16:28:43 <TabAtkins> iank_: I believe yes, gecko's behavior
16:29:09 <TabAtkins> RESOLVED: width:max-content prevents table-layout:fixed from working
16:29:33 <TabAtkins> github-bot: take up https://github.com/w3c/csswg-drafts/issues/12732
16:29:33 <github-bot> Topic: [css-anchor-position-1] position-visibility: anchors-visible should be clear about when is visibility determined
16:29:33 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12732.
16:29:55 <TabAtkins> emilio: the spec doesn't say when the anchor's visibility is checked
16:30:09 <TabAtkins> emilio: and when I was looking to implement, I realized the spec technically allows....
16:30:17 <TabAtkins> emilio: if it did something more complicated you could only do it as post layout
16:30:25 <TabAtkins> emilio: but the clipping thing specified is at layout time
16:30:29 <TabAtkins> emilio: the issue is about defining *when*
16:30:46 <TabAtkins> emilio: webkit does it during layout. blink does some intersection observer thing, which is a bit more flexible
16:30:51 <TabAtkins> emilio: but might be more confusing
16:31:09 <TabAtkins> emilio: if you change layout in a way that overflows, then elementFromPoint(), whether that hit test succeeds or not depends on timing
16:31:16 <TabAtkins> emilio: no strong opinion on what happens, just want it specified
16:31:24 <TabAtkins> emilio: I think Tab added an edit
16:31:41 <TabAtkins> emilio: should check with WebKit. and spec edit should use some of the post-layout things Rune is doing.
16:32:00 <futhark> q+
16:33:05 <TabAtkins> TabAtkins: I specified "just before ResizeObserver", because that's what Philip said and Emilio agreed. More details would be great.
16:33:46 <TabAtkins> emilio: it needs to be a bit more detailed, because ResizeObserver loop is more stuff - content-visibility, scroll size observer... it needs to be specced in amore detailed way. rune can give details
16:34:02 <astearns> ack futhark
16:34:06 <TabAtkins> futhark: sorry, don't have specific context on position-visibliity, but it does make sense to happen at same time
16:34:17 <TabAtkins> futhark: also on whether rpost-layout snapshot happens before or after resizeobserver
16:34:20 <TabAtkins> futhark: ties in, I agree
16:34:49 <TabAtkins> fantasai: I pinged antii to see if he has feedback. I have no idea how this timing fits in with anything
16:35:06 <fantasai> s/antii/antti/
16:35:07 <TabAtkins> fantasai: I just want authors to have something that generally works. not sure to what extent we care about exact nuances beyond that
16:35:19 <emilio> q+
16:35:21 <TabAtkins> fantasai: so how much of this is about authors caring about timing, and how much is about writing WPTs
16:35:49 <TabAtkins> fantasai: so long as the author-observable behavior is something they're happy about, and we have interop on aspects that we need *for authors*
16:35:55 <astearns> ack emilio
16:36:11 <TabAtkins> emilio: not about locking things down. timing issue ends up... if we dont' define it, we'll hit compat issues.
16:36:40 <TabAtkins> emilio: it's pretty different observable behavior. if you do it before resize, then layout changes from an RO won't hide an anchor until next frame
16:37:14 <TabAtkins> emilio: on flip side, if you do it during layout, that's most CSS-y it's not really observable, but it's less flexible. can't check for intersection with other elements.
16:37:32 <TabAtkins> emilio: i'm assuming blink is actually reusing Intersection observer, which does a lot more than just checking scroll overflow
16:37:39 <TabAtkins> emilio: that's a big behavior different, should use one or the other
16:37:48 <TabAtkins> emilio: IO uses overflow-clip, o-c-margin, etc
16:37:55 <TabAtkins> emilio: and those are probably something the author would expect to work
16:38:03 <TabAtkins> fantasai: yeah, defining whether we check clip is definitely defined
16:38:15 <TabAtkins> TabAtkins: I think that's already defined
16:38:39 <fantasai> TabAtkins: We should define behavior we want
16:38:50 <TabAtkins> emilio: right now I think spec is just overflow based
16:38:55 <TabAtkins> astearns: so how to resolve on this?
16:39:07 <TabAtkins> emilio: if we want to check IO things, we need to define a fixed point in the frame timing
16:39:16 <TabAtkins> fantasai: I think we should just be checking for what's in the spec right now
16:39:28 <TabAtkins> fantasai: if we did clip path and other stuff.... I don't think tha't snecessarily what authors would expect
16:39:37 <TabAtkins> emilio: if you did this as an author you'd do IO
16:39:45 <TabAtkins> fantasai: sure but i'm not convinced it's really what you *want*
16:40:19 <TabAtkins> fantasai: so we have some qs to investigate. what do we think authors expect about clip behavior and anchor visibility? and the timing question
16:40:23 <TabAtkins> fantasai: which depends on that first q
16:40:27 <TabAtkins> emilio: I think that makes sense
16:40:37 <fantasai> s/first q/first question, so let's answer that one first/
16:40:53 <TabAtkins> emilio: I think spec currently only does check from the anchor to the CB of the positioned El, and that's another big change from IO
16:41:12 <TabAtkins> fantasai: right, I think IO isn't what we want to do
16:41:32 <TabAtkins> emilio: maybe. I think it's weird, for example, to not intersect with the viewport.
16:41:36 <TabAtkins> astearns: take back to the issue, then?
16:41:37 <TabAtkins> fantasai: yes
16:41:45 <TabAtkins> github-bot, topic https://github.com/w3c/csswg-drafts/issues/12610
16:41:45 <github-bot> Topic: [css-anchor-position-2] Add `any` keyword support to `anchored(fallback)` container queries
16:41:45 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12610.
16:42:19 <TabAtkins> fantasai: discussion about anchored() query for anchor-pos-2, where you can ask which area it's anchored in
16:42:46 <TabAtkins> fantasai: proposal was to add an 'any' keyword, combinable in the same way span-all is combinable, so you can query "I want to check if it's on the left, in any track"
16:43:10 <TabAtkins> fantasai: Tim brought up that if you omit the keyword from an axis, it would make more sense to default it to 'any' in queries, rather than span-all like in the property
16:43:34 <TabAtkins> fantasai: so proposal is that a duplicated keyword is duplicated as normal, but if it would instead default to span-all in the property, it defaults to 'any' in the query
16:43:37 <TabAtkins> +1
16:43:52 <fantasai> TabAtkins: Sounds good. Tim's argument makes sense.
16:44:25 <fantasai> PROPOSED: 'any' keyword is allowed wherever 'span-all' is allowed, and omitted values that would default to 'span-all' default to 'any' for queries.
16:44:36 <futhark> q+
16:44:54 <TabAtkins> futhark: is it possible to ask for fpwd for anchor-pos-2 once this is in?
16:45:01 <TabAtkins> astearns: let's get this in first
16:45:03 <TabAtkins> astearns: objections?
16:45:03 <fantasai> RESOLVED: 'any' keyword is allowed wherever 'span-all' is allowed, and omitted values that would default to 'span-all' default to 'any' for queries.
16:45:07 <astearns> ack futhark
16:45:32 <TabAtkins> fantasai: I'd like a week to review the new spec before fpwd
16:45:50 <TabAtkins> astearns: Rune, could you add a comment to #6900 to ask for publication next week?
16:46:06 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12652#issuecomment-3292939040
16:46:06 <github-bot> Topic: [web-animations-2][css-animations-2] animation-trigger CSS syntax
16:46:06 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12652.
16:46:33 <TabAtkins> fantasai: two things. first here is the syntax of animation-trigger, which binds a named event to an animation
16:46:52 <TabAtkins> fantasai: given that comma-separated is already used to align them with the animations
16:47:04 <TabAtkins> fantasai: we need something else. could use a trigger() function, but maybe awkward
16:47:19 <TabAtkins> fantasai: I think the current syntax proposed is to use space separation, with name first then actions
16:47:35 <TabAtkins> fantasai: and because the event is syntax unique, it would go first and dictate what arguments would apply to it
16:47:38 <flackr> something like [<dashed-ident> <behavior/actions>]+ ?
16:47:46 <TabAtkins> fantasai: yes, like that
16:47:50 <futhark> present-
16:47:52 <TabAtkins> flackr: seems reasonable
16:48:14 <TabAtkins> ydaniv: sounds fine. Robert had some concerns about later having multiple triggers....
16:48:19 <TabAtkins> flackr: that's implied here
16:48:27 <TabAtkins> flackr: the dashed-ident doesnt' clash with the behavior/action values
16:48:44 <TabAtkins> fantasai: an alternative is to flip the order.... but that could be confusing
16:49:20 <TabAtkins> proposed resolution: syntax of animation-trigger is [<dashed-ident> <behavior/actions>]+#
16:49:35 <TabAtkins> RESOLVED: syntax of animation-trigger is [<dashed-ident> <behavior/actions>]+#
16:49:46 <github-bot> Topic: [css-anchor-position] fallback-position behavior: spec vs. expectation
16:50:20 <TabAtkins> fantasai: emeyer raised this. there was previously behavior differences in fallback choosing
16:50:27 <TabAtkins> fantasai: we were previously greedy with fallback behavior
16:50:57 <fantasai> TabAtkins: When you have multiple fallbacks, current spec behavior is to run through the list to pick the first one that doesn't overflow
16:51:15 <fantasai> TabAtkins: If layout changes such that an earlier option would now be valid, current spec doesn't go back.
16:51:28 <fantasai> TabAtkins: it only changes which fallback is used when your current fallback choice stops being valid
16:51:35 <fantasai> TabAtkins: then it re-evaluates the list again
16:51:44 <fantasai> TabAtkins: Alternate behavior is to check after every layout
16:51:55 <fantasai> TabAtkins: so that you're always taking the most favorable option, if it is valid
16:52:19 <emeyer> q+
16:52:19 <fantasai> TabAtkins: This "greedy" behavior is what WebKit did have earlier, but spec has for some time focused on "stable" version
16:52:31 <fantasai> TabAtkins: Eric noticed the different and ran some polls on what they prefer
16:52:43 <fantasai> TabAtkins: Respondants seemed to strongly prefer the "greedy" behavior
16:53:07 <fantasai> TabAtkins: If you resize an element such that first element causes overflow, and then the popover flips to the other side, then you widen element again, it still stays on that other side until you do something to make it invalid
16:53:16 <fantasai> TabAtkins: Preference was to flip back to the first option if possible
16:53:31 <fantasai> TabAtkins: fantasai and I discussed this, and a few points
16:53:52 <fantasai> TabAtkins: We thought the preferred behavior might differ based on whether you are responding to layout changes, or whether you are responding to something more passive like scrolling
16:54:31 <fantasai> TabAtkins: Also point out that you would need to re-run multiple anchor layouts every time layout changes if we went with "greedy" behavior
16:54:36 <astearns> ack emeyer
16:54:39 <fantasai> TabAtkins: which is therefore less efficient
16:55:07 <kizu> q+
16:55:11 <TabAtkins> emeyer: I ran the poll not because I had a preferred, but because I discovered there were two behaviors
16:55:23 <TabAtkins> emeyer: when I put up the epoll I expected it to be about 50/50
16:55:29 <TabAtkins> emeyer: it wasn't, which is why I opened the issue
16:55:36 <TabAtkins> emeyer: even in the small poll there was such a strong tilt
16:55:51 <TabAtkins> emeyer: there are arguments in both the poll and the issue for both behavior
16:56:03 <TabAtkins> emeyer: roman and I are probably in agreement that this should be switchable
16:56:21 <TabAtkins> emeyer: as some people say, they'd prefer that, for a given layout state, the popover should always be in the same place regardless of history
16:56:32 <TabAtkins> emeyer: in my slider example, a given slider position should always give a consistent label position
16:56:43 <TabAtkins> emeyer: while a11y people said having things jump around more is an a11y problem
16:56:58 <TabAtkins> emeyer: I don't think I have a strong preference but it needs to either be more clearly explained, or given authors an option
16:56:59 <astearns> ack kizu
16:57:12 <TabAtkins> kizu: I think we definitely need an option. each version has pros and cons
16:57:28 <TabAtkins> kizu: I think current spec behavior is okay as default if it has better perf and makes less layout jumps
16:57:47 <TabAtkins> kizu: but as seen by the poll, people do expect greedy behavior. it's what the libraries do.
16:58:00 <emilio> q+
16:58:01 <TabAtkins> kizu: and it'll be needed for migrating from those js libraries, as the beahvior change might not be wanted
16:58:26 <TabAtkins> kizu: so I think current spec is okay for default if there's an option to have a less stateful version
16:58:34 <astearns> ack emilio
16:58:35 <emeyer> +1 to everything kizu just said
16:58:47 <TabAtkins> emilio: I'd rather stick with the current spec behavior rather than having an option
16:59:02 <TabAtkins> emilio: this option would mean running layout on scroll every time you're in any fallback beyond the first
16:59:07 <TabAtkins> emilio: which is annoying
16:59:30 <TabAtkins> emilio: for a small tooltip that's probably fine, but a sidebar, something big that's in a fallback state most of the time, that's not great
16:59:37 <astearns> ack fantasai
16:59:52 <TabAtkins> fantasai: I think I agree with Emilio that running the choice algo on scroll is a bad idea
16:59:57 <TabAtkins> fantasai: definitely not default to it
17:00:08 <TabAtkins> fantasai: but for cases where you're running layout anyway, re-evaluating might not be that bad
17:00:34 <TabAtkins> fantasai: so i'd be open to allowing greedy behavior but not for scroll. only for CB changes
17:00:48 <TabAtkins> astearns: i'm hearing even the folks that want a switch are fine with current default
17:01:00 <TabAtkins> astearns: should we resolve to use the current spec text as default, explore a switch in the issue?
17:01:02 <TabAtkins> +1
17:01:07 <Kurt> +1
17:01:07 <fantasai> https://www.w3.org/TR/css-anchor-position/#position-try-order-property
17:01:14 <TabAtkins> fantasai: a place to have the switch is probably in position-try-order
17:01:30 <TabAtkins> astearns: proposed resolution is no change for the default, we'll investigate a switch
17:01:33 <TabAtkins> astearns: objections?
17:01:42 <TabAtkins> RESOLVED: no change for the default, we'll investigate a switch
17:01:57 <TabAtkins> emilio: can we resolve on not being greedy on scroll changes?
17:02:04 <fantasai> SUMMARY: Significant concern about re-running selection on scroll
17:02:05 <TabAtkins> astearns: we'll discuss whether we have the greedy switch at all
17:02:12 <TabAtkins> emilio: ok
17:02:19 <TabAtkins> github-bot, end topic
17:02:34 <fantasai> -> https://app.rallly.co/poll/JVvrK6xuIeIK
17:02:48 <fantasai> POLLLLLL!!!!!!!!!!!!!!!! ^^^^^^^^^^^^^^^^
17:37:52 <antonp> antonp has joined #css
19:28:17 <Zakim> Zakim has left #css