15:58:53 <RRSAgent> RRSAgent has joined #css
15:58:57 <RRSAgent> logging to https://www.w3.org/2025/03/19-css-irc
15:58:57 <Zakim> RRSAgent, make logs Public
15:58:58 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:00:45 <kizu> kizu has joined #css
16:00:49 <kizu> present+
16:01:08 <jfkthame> jfkthame has joined #css
16:01:16 <kbabbitt> kbabbitt has joined #css
16:01:42 <alisonmaher> alisonmaher has joined #css
16:01:44 <rachelandrew> present+
16:01:46 <alisonmaher> present+
16:02:18 <TabAtkins> ScribeNick: TabAtkins
16:02:27 <dbaron> Present+
16:02:54 <kbabbitt> present+
16:02:58 <ntim> present+
16:03:21 <gfaujdar> gfaujdar has joined #css
16:03:31 <gfaujdar> present+
16:03:54 <dholbert> dholbert has joined #css
16:04:00 <smfr> smfr has joined #css
16:04:06 <PaulG> PaulG has joined #css
16:04:06 <smfr> present+
16:04:07 <TabAtkins> astearns: any agenda changes?
16:04:08 <TabAtkins> presnet+
16:04:11 <TabAtkins> present+
16:04:11 <PaulG> present+
16:04:25 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/6900#issuecomment-2715192840
16:04:26 <github-bot> Topic: Republishing Tasks Permathread
16:04:26 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6900.
16:04:26 <miriam> present+
16:04:49 <TabAtkins> ntim: I'd like to request FPWD of Forms
16:04:57 <TabAtkins> ntim: currently an unofficial draft, woudl like to get ball rolling
16:05:22 <TabAtkins> ntim: the current draft defines appearance:base, and a set of pseudo-elements for form controls
16:05:30 <flackr> flackr has joined #css
16:05:32 <TabAtkins> ntim: a few more things for form control styling
16:05:35 <flackr> present+
16:05:51 <TabAtkins> ntim: this has been discussed in teh joint openui/csswg meetingws
16:06:05 <TabAtkins> astearns: there are a bunch of open issues, so clearly people are interested
16:06:09 <TabAtkins> astearns: are there also pending PRs?
16:06:18 <TabAtkins> ntim: yes, i've approved most of them. currently one left open, i think
16:06:26 <vmpstr> present+
16:06:29 <TabAtkins> astearns: so your intent is to merge everything we've got in the pipeline before fpwd?
16:06:36 <TabAtkins> ntim: not necessarily
16:06:49 <TabAtkins> astearns: i'd like to get some more co-editors to help out
16:06:57 <TabAtkins> astearns: would you prefer that before fpwd, or after?
16:07:01 <TabAtkins> ntim: after
16:07:14 <TabAtkins> astearns: k, i'll plan to do that right after fpwd
16:07:27 <TabAtkins> no questions, spec looks reasoanble for an early fpwd
16:07:44 <TabAtkins> ??: can someone remind me about the process? what does being a WD do?
16:08:10 <TabAtkins> astearns: a FPWD is our intent to work on this. IPR becomes an issue for merging things into an official FPWD, as opposed to an editor's draft that hasn't been adopted yet.
16:08:12 <florian> q+
16:08:25 <astearns> ack florian
16:08:39 <TabAtkins> florian: yeah, until it's a WD of some kind (incluing FPWD) it's not actuallya  deliverable fo the group, this is the official start
16:08:53 <TabAtkins> florian: as mentioned, this has patent implications, W3C patent rules start applying to WD, not EDs
16:09:25 <TabAtkins> florian: member companies don't need to license things just because we start publishiing, but they do need to start paying attention. their lawyers will get a notification, becuase eventually they'll need to license patents if they don't object.
16:09:46 <TabAtkins> fantasai: the name is "first PUBLIC working draft"; in the past editor's draft werent' public so this was the first that was public
16:10:12 <TabAtkins> fantasai: in the interest of "release early, release often" we don't want to wait for a polished spec, but want it up enough that people know how the spec is going to go
16:10:35 <TabAtkins> fantasai: major conflicts, might want to delay for a bit. like in Variables, early on there were a lot of possible directions and none of them caught traction.
16:10:48 <TabAtkins> fantasai: when we finally hit on the current model and it caught, we finally made the FPWD for it
16:11:07 <TabAtkins> fantasai: so the point at which you're aksing for feedback outsdie the WD, that's when yous hould FPWD
16:11:21 <TabAtkins> florian: other topic. I understand this is also supposed to take over some parts of CSS UI 4
16:11:28 <TabAtkins> florian: some issues in the spec asking about taking over bits
16:11:29 <fantasai> s/major conflicts/major conflicts in underlying model/
16:11:51 <TabAtkins> florian: i think we probably should, for most at least. don't think we need to solve those for fpwd, since the text is already in a spec, but we should decide on which things move and which things stay soonish.
16:12:03 <TabAtkins> florian: happy to work with Tim to figure this out either before or after fpwd, whatever's helpful
16:12:09 <TabAtkins> ntim: let's do it after
16:12:24 <TabAtkins> ntim: i think it's weird to move something from a higher level spec to an unofficial draft
16:12:34 <TabAtkins> florian: sure, so FPWD to get the new stuff, then migrate once it's official. works for me.
16:12:35 <astearns> ack fantasai
16:13:02 <TabAtkins> fantasai: some notes, FPWD patent stuff is like 90 days or 120 days from the first public draft for the timer to kick in, so even if you add stuff afterwards, it's as if it was in the fpwd
16:13:25 <TabAtkins> fantasai: also note, all Working Drafts have some degree of patent protections, while none of our Editors Drafts do. so it's actually important ot publish your drafts.
16:13:44 <TabAtkins> astearns: proposed resolution is to publish a FPWD of CSS Forms. Objecteions?
16:13:51 <TabAtkins> RESOLVED: Publish FPWD of CSS Forms
16:14:03 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10845
16:14:03 <github-bot> Topic: [css-conditional-5] `CSSContainerRule.containerName`/`containerQuery` should return a list
16:14:03 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10845.
16:14:21 <TabAtkins> astearns: miriam, this was months ago, but you put this on the agenda last year
16:14:25 <TabAtkins> miriam: okay, let's review...
16:14:27 <dholbert> present+
16:15:19 <TabAtkins> miriam: we resolved earlier that a @container prelude could accept a list of conditions, but we didn't update the CSSOM to return a list
16:15:36 <TabAtkins> miriam: so the proposal is that CSSOM should reflect that list back to us
16:15:45 <TabAtkins> astearns: it's mentioned that none of the impls do it yet
16:15:50 <TabAtkins> miriam: at least, last yes, yes
16:16:04 <emilio> s/yes, yes/year, yes
16:16:10 <TabAtkins> astearns: so proposed resolution is to update CSSOM to match the resolution?
16:16:11 <kbabbitt> seems reasonable to me
16:16:12 <TabAtkins> miriam: yes
16:16:32 <TabAtkins> emilio: is the proposal to return a readonly sequence?
16:17:18 <TabAtkins> TabAtkins: i was thinking about that too. either it's readonly, or it could be settable but the list you get from the getter is "dead", doesn't reflect back into the object if you mutate
16:17:33 <TabAtkins> astearns: i think guillaume's PR doens't mention the read/write nature of the list
16:17:55 <TabAtkins> emilio: some back compat too. for the single-condition case, it might need to still return a string
16:18:12 <TabAtkins> astearns: do you think it's reasoanble to resolve on returning the list and find out if we have compat problems?
16:18:13 <kschmi> kschmi has joined #css
16:18:33 <emilio> TabAtkins: if today we allow a comma-separated list, how is it reflected? Just comma-separated list?
16:18:39 <emilio> ... if so it might be worth keeping the property alone
16:18:48 <emilio> ... and just have a function to get the listified version
16:19:07 <TabAtkins> miriam: maybe more complicated, containerName wouldn't make sense if it was returning the whole prelude
16:19:32 <TabAtkins> miriam: maybe nobody is usign the feature yet?
16:20:16 <TabAtkins> TabAtkins: propose we just reoslve to fix, and let editors figure out what it should look like
16:20:20 <TabAtkins> astearns: and who shoudl edit it?
16:20:25 <TabAtkins> TabAtkins: miriam or emilio?
16:20:40 <TabAtkins> emilio: this sounds reasonable. note that Firefox doesn't support multiple conditions yet, so it's not an issue for us.
16:20:52 <TabAtkins> emilio: maybe other browsers dont' eitehr, presumably they'd have run into this containerName issue too
16:21:15 <TabAtkins> astearns: so proposed resolution is we'll accommodate our intent in the CSSOM spec, but leave details to the editors to figure out what is possible given the constraints
16:21:51 <TabAtkins> miriam: can we get a little further? do we just have one property that returns a list, or a string property plus a list accessor?
16:22:00 <TabAtkins> astearns: i'd prefer only one, but i don't know if it's possible
16:22:08 <TabAtkins> emilio: i agree if we coudln't return a list...
16:22:29 <TabAtkins> emilio: but also the name is optional. if you have multiple container conditions, what are the names...?
16:22:55 <TabAtkins> emilio: if you have three conditions, only the first and third have a name...
16:23:09 <TabAtkins> TabAtkins: this is why i suggested leaving the details to the editors, i think they'd be pretty obvious once you start working it out
16:23:21 <TabAtkins> emilio: yeah, we can try to sort it out and come back with a more fleshed out proposal
16:23:23 <TabAtkins> miriam: sure
16:23:33 <TabAtkins> astearns: so we're resolved to fix this, and bring the solution back to the group
16:23:37 <TabAtkins> astearns: objections?
16:23:55 <TabAtkins> RESOLVED: Editors will figure out how to fix the OM to match the new behavior, and bring it back to the group for review
16:24:23 <emilio> github-bot, take up https://github.com/w3c/csswg-drafts/issues/1914
16:24:23 <github-bot> Topic: [css-scoping-1] Dynamic changes of state and attributes referenced by :host-context rules are pretty hard to handle efficiently.
16:24:23 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/1914.
16:25:01 <emilio> TabAtkins: emilio brought up the issue that `:host-context` pseudo-class matches the host element inside a shadow root, and it matches the host if any of the ancestors match the compound
16:25:18 <emilio> ... intention was to solve some theming use cases (light/dark mode etc)
16:25:32 <emilio> ... issue is that this is not very efficient, tree-crossing, and invalidation is difficult
16:25:48 <emilio> ... since then, most of the use cases can be replaced by style queries (and better)
16:26:02 <emilio> ... e.g. instead of light / dark class, you can use it to set a custom prop and use inheritance
16:26:10 <emilio> ... shadow tree can use a style query
16:26:23 <emilio> ... it handles scoping / don't have to worry about which one is closer
16:26:36 <emilio> ... it pulls in the cost of the container query but avoids the cost of cross-tree invalidations
16:26:47 <emilio> ... emilio and WebKit impl would prefer to remove host-context
16:26:54 <emilio> ... afaict it's only chrome
16:27:15 <emilio> ... this could be a compat issue for chrome, so fairly limited
16:27:28 <emilio> ... so I'm ok with dropping this given the powers CSS has now
16:27:39 <emilio> ... unless there's objections I'd be happy with a resolution
16:27:50 <emilio> astearns: do you think you'll be successful convincing Blink to remove it?
16:28:03 <keithamus> q+
16:28:09 <emilio> TabAtkins: we shall see
16:28:19 <astearns> ack keithamus
16:28:30 <emilio> ... but at least it can be clear that it's chrome-only and not intended to be implemented everywhere
16:28:34 <emilio> keithamus: is there a use counter?
16:28:41 <emilio> TabAtkins: not sure but that'd be the first step in our deprecation process
16:28:58 <emilio> astearns: is there anything that host-context can be used for not covered by container-style queries?
16:29:15 <emilio> TabAtkins: the only difference is it switches who has control over
16:29:30 <emilio> ... that said you shouldn't be depending on details from the outer tree if the outer tree isn't expecting it
16:29:40 <emilio> ... shouldn't really matter where the control lives
16:29:51 <emilio> ... but if the same person controls both sides, there's no difference in abilities
16:29:57 <dbaron> use counter: https://chromestatus.com/metrics/feature/timeline/popularity/470
16:30:47 <emilio> TabAtkins: slowly trending upwards but given the numbers probably possible to remove via a deprecation process
16:30:56 <emilio> astearns: proposed resolution to drop `:host-context()`, objections?
16:30:59 <emilio> +1 :-)
16:31:12 <emilio> RESOLVED: Drop `:host-context()`
16:31:26 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/11864
16:31:26 <github-bot> Topic: [css-values-5] Make UA, not author, deal with floating point errors in random()
16:31:26 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11864.
16:31:58 <emilio> TabAtkins: `random()` has been getting some attention. gets a numeric range, with an optional step
16:32:22 <emilio> ... if you have 100, 200, 150 ... [missing]
16:32:35 <emilio> ... works fine with integer values, but not with floating points
16:32:48 <emilio> ... because 0.1 * 3 is one step further than 0.3
16:33:02 <emilio> ... exact details about the number system would expose this sort of precision issues unpredictably
16:33:13 <emilio> ... even where these are consistent people get bit by this all the time
16:33:18 <emilio> ... floating point math is hard
16:33:23 <emilio> ... various ways to get around
16:33:27 <emilio> ... an epsilon
16:33:37 <emilio> ... that's what we proposed adding
16:33:53 <emilio> ... whenever you calculate the steps you calculate an epsilon of 1/1000th of the step size
16:34:11 <emilio> ... as long as that's around the max we include it
16:34:31 <emilio> ... 1/1000 is more than large enough for any precision issues but small enough to not triggering it accidentally
16:34:58 <emilio> ... authors might need to spell out 1.3333 to get reliably
16:35:09 <iank_> When you get to the extreme values doesn't floating-point go outside the 1% range?
16:35:09 <emilio> ... unless any objections that's on the spec already
16:35:10 <emilio> +1
16:35:15 <weinig> q+
16:35:16 <emilio> q+
16:35:19 <emilio> s/+1//
16:35:34 <emilio> iank_: only when you get to extraordinarily extreme values
16:35:44 <emilio> ... not reasonable to be used in CSS
16:35:51 <kbabbitt> s/iank_:/TabAtkins:/
16:35:54 <iank_> ok
16:36:06 <emilio> ... if you get beaten by it you're going to have problems anyways
16:36:11 <astearns> ack weinig
16:36:14 <emilio> ... even for 1M pixels you should be fine
16:36:28 <emilio> weinig: if the only use case is evenly dividing ranges by a number
16:36:43 <emilio> ... an alternative would be to have a keyword that specifies that instead of a step size you specify the number of buckets
16:36:49 <emilio> ... the impl then can do it for any value
16:37:23 <emilio> ... barring that there's also a more classical, similar function from TAOCP, using the ...
16:38:00 <emilio> ... from "accuracy of floating point arithmetic" from TAOCP
16:38:03 <emilio> ... I'll paste it in
16:38:21 <emilio> TabAtkins: certainly happy to defer to people that have thought more about it
16:38:27 <emilio> ... certainly happy to about
16:38:41 <emilio> weinig: the important bit is that the epsilon is not constant
16:39:01 <emilio> TabAtkins: don't want to force people to write a calc() to get the right thing
16:39:19 <emilio> ... so it can also work with 1.3333 or so
16:39:30 <emilio> weinig: I really worry about trying to invent our own thing
16:39:44 <emilio> ... specially if a property has small numbers or ranges far away from zero
16:39:53 <emilio> ... so trying to find another solution seems wise here
16:40:01 <dholbert> q+
16:40:09 <emilio> TabAtkins: re. your first question about dividing the range in buckets, issue is usability
16:40:13 <emilio> ... in the abstract it's the same
16:40:26 <emilio> ... in practice knowing the number of buckets means range / step size
16:41:00 <emilio> ... you have start and end, calculating the number of buckets needs unit division
16:41:11 <emilio> ... inclined to avoid that one even it does solve the fundamental issue
16:41:20 <fantasai> scribe+
16:41:29 <astearns> ack emilio
16:41:50 <fantasai> emilio: Was going to suggest same as weining, can't you get around the unit size with round() ... I guess it gets complicated if you want to handle mixed units
16:41:56 <fantasai> ... but definitely annoying
16:42:14 <fantasai> TabAtkins: the atan() hack for stripping units is not great
16:42:18 <astearns> ack fantasai
16:42:43 <emilio> fantasai: wanted to say that the idea that I have four segments, rather than step by 10px, is a different feature
16:42:46 <emilio> ... but not the same
16:42:56 <emilio> ... we should make the step size work in an intuitive way
16:43:17 <emilio> ... given the step size, if they're 0.1% to the end, it seems we should use the end
16:43:34 <weinig> The floating point comparison accuracy compare function from Knuth is - Knuth, D. E. "Accuracy of Floating Point Arithmetic." The Art of Computer Programming. 3rd ed. Vol. 2. Boston: Addison-Wesley, 1998. 229-45.
16:43:35 <emilio> ... I think making the author deal with this by round() or so is really hostile
16:43:47 <emilio> ... we should be handling that math for them
16:44:04 <emilio> ... only case where we might want to do the accuracy comparison is if you don't have any step size indicated
16:44:13 <emilio> ... so I think tab's proposal is the right way to go
16:44:18 <kizu> +1 to the proposal as well
16:44:23 <astearns> ack dholbert
16:44:24 <emilio> ... trying to just solve the floating point case is not a good idea
16:44:34 <weinig> (boost has a good write up, https://www.boost.org/doc/libs/1_34_0/libs/test/doc/components/test_tools/floating_point_comparison.html)
16:44:40 <emilio> dholbert: regarding the 3.333 from 0 to 10, thinking about 6.66667 from 0 to 20
16:44:56 <emilio> ... seems this would introduce an arbitrary minimum amount of precision
16:45:00 <emilio> ... to get the right result
16:45:26 <emilio> ... maybe seems slightly surprising that it automatically starts rounding at a particular rounding of precision
16:45:32 <emilio> ... feels a bit magical
16:45:46 <emilio> TabAtkins: you're right that you need at least 4 digits
16:46:00 <emilio> dholbert: maybe unavoidable
16:46:14 <emilio> TabAtkins: yeah, spec says to provide five digits of precision intentionally
16:46:37 <emilio> astearns: sounds like the proposed resolution is to accept the epsilon proposal subject to some refinement looking through the literature
16:46:44 <emilio> ... is that good enough?
16:46:57 <emilio> weinig: don't wanna block it, this seems like a good start
16:47:06 <jensimmons> jensimmons has joined #css
16:47:09 <emilio> fantasai: I think the "let's split into n parts" is not bad
16:47:15 <emilio> ... it's just a different feature
16:47:45 <emilio> weinig: some wording for pixels vs numbers having different epsilons could be good to think about
16:47:55 <emilio> TabAtkins: I think you're right that a unit-based approach might be useful
16:48:20 <emilio> weinig: the reason why this is on my mind is that we recently had an issue with epsilons in the color space, to determine something if something is powerless
16:48:33 <emilio> ... and that epsilon wasn't defined, and the value in webkit was too large
16:48:49 <emilio> ... getting this right can cause real issues
16:49:02 <emilio> ... I wanna think a bit harder about it for the color part but these are details that we can work out
16:49:18 <emilio> astearns: proposal is to accept the draft with follow-up refinements as needed
16:49:28 <emilio> RESOLVED: accept the epsilon proposal, with follow-up refinements as needed
16:49:46 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/11742
16:49:47 <github-bot> Topic: [css-values-5] Maybe min, max and step should not be part of the random-caching-key
16:49:47 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11742.
16:50:07 <fantasai> Proposal at https://github.com/w3c/csswg-drafts/issues/11742#issuecomment-2707697957
16:50:24 <emilio> TabAtkins: defining randomness in CSS because the execution model is not strictly temporal
16:50:33 <emilio> ... can't hold on to existing values
16:50:50 <emilio> ... don't want to calculate a random value on every recalc
16:50:59 <emilio> ... you need to have some stability
16:51:15 <emilio> ... the old draft did this via a caching key approach
16:51:30 <emilio> ... so if the key is the same between two instances of a random() function then the values need to be the same
16:51:35 <emilio> ... this caching key has changed tho
16:51:58 <emilio> ... author could provide a custom-ident, but also min/max/step values were pulled in
16:52:36 <emilio> ... any other random function would probably have a different step and thus generate a different random value
16:52:50 <emilio> ... this worked reasonably well but did mean that values could be accidentally linked together
16:53:08 <emilio> ... so random width/height you would get a random square
16:53:13 <emilio> ... rather than a random value
16:53:19 <fantasai> s/value/rectangle
16:53:51 <emilio> ... fantasai proposed something else, which is on the spec right now. Caching key is (property, index among random values in that property)
16:54:12 <emilio> ... so if you use `width: ...;` the key is (width, 0)
16:54:27 <emilio> fantasai: you don't want a global random
16:54:33 <emilio> ... caching key also includes the element identity
16:54:54 <emilio> ... all of that gets computed to a random value which they inherits so that we don't recalc it for inheritable properties
16:55:30 <emilio> TabAtkins: so on a single element if you use the same values on different properties you're guaranteed to get distinct values
16:55:57 <emilio> ... you can override it if you want, so you could still pass the same ident to width/height
16:56:07 <emilio> ... some good examples of this are in the spec
16:56:27 <emilio> ... don't know what people might need for this but I propose we accept the new draft based on elika's proposal for the different key
16:56:28 <emilio> q+
16:56:39 <emilio> ... one further question about bikeshedding the keyword name
16:56:42 <weinig> q+
16:56:45 <astearns> ack emilio
16:56:56 <fantasai> emilio: Is this declaration index thing local to each element you compute?
16:57:16 <fantasai> TabAtkins: There's a 2nd thing you can provide, which is a keyword indicating whether this value should be shared by all elements with this style, or be element-specific.
16:57:26 <fantasai> TabAtkins: Then it either includes the element identity in the caching key or not
16:57:34 <weinig> q-
16:57:44 <kschmi> kschmi has joined #css
16:57:50 <fantasai> emilio: Say you have 2 selectors with random() and you have an element that matches one, and another that matches both of them
16:58:01 <fantasai> emilio: so in one the index ...
16:58:09 <fantasai> TabAtkins: index is just the number of random() instances in that declaration.
16:58:16 <fantasai> TabAtkins: so for 'width' always index of zero
16:58:37 <fantasai> emilio: So if they're in different elements, they would be shared?
16:58:56 <fantasai> TabAtkins: if not adding extra "match-across-elements" keyword, then they all include element ident
16:59:05 <fantasai> TabAtkins: This is new, because CSS generally doesn't care where a value came from
16:59:19 <fantasai> TabAtkins: whether spell out in comma-separated selector list, or in a style attr, these are all the same
16:59:28 <fantasai> TabAtkins: I want to maintain that equivalence as much as possible
16:59:38 <fantasai> TabAtkins: so only including information from declaration it lives in. Nothing from style rule or selector.
16:59:49 <fantasai> emilio: So maybe some things that you would expect to work don't?
17:00:01 <fantasai> emilio: e.g. 10 elements, each with style blah: random()
17:00:04 <fantasai> emilio: ok, sounds good
17:00:18 <fantasai> TabAtkins: To be clear, having it vary by element is the default. You have to specify keyword to make it shared across elements.
17:00:26 <fantasai> TabAtkins: so common case would be what you expect there
17:00:28 <fantasai> emilio: seems reasonable
17:00:38 <fantasai> emilio: Shorthands maybe funny?
17:01:02 <fantasai> TabAtkins: it uses the declared property, e.g. in 'margin' you'd use 'margin' as part of the key, not the longhand names
17:01:21 <fantasai> TabAtkins: if you write 'margin: random(...)' you get equal margins on all four sides
17:01:35 <fantasai> TabAtkins: there's a bit of text in the draft about how this works for custom properties, it's a bit weird (unfortunately)
17:01:52 <fantasai> TabAtkins: unregistered vs registered properties, since the latter compute and the former don't before substitution
17:01:57 <cabanier_> cabanier_ has joined #css
17:02:26 <fantasai> emilio: Might be confusing, but as long as we clarify impact of registration should be ok
17:02:30 <fantasai> astearns: over time
17:02:43 <astearns> ack fantasai
17:03:07 <emilio> fantasai: what we're trying to do is by default you get max randomness (varies by element, property, declaration index), but doesn't by where you declare it
17:03:21 <emilio> ... within an element you can make it shared by using the custom property
17:03:37 <emilio> ... can share across elements with the keyword tbd
17:03:44 <emilio> ... I think it's the right direction
17:03:57 <emilio> astearns: a bit concerned about oriol's comments
17:04:04 <fantasai> astearns: Concerned about Oriol not being convinced yet.
17:04:16 <emilio> TabAtkins: I feel strongly about this model
17:04:23 <emilio> fantasai: we should give oriol a chance to comment on here
17:04:29 <emilio> astearns: let's defer this to next week
17:04:48 <TabAtkins> github-bot, end topic
17:11:17 <janina1> janina1 has joined #css
17:18:33 <dgrogan> W3C breakouts day is next Wednesday. The WG meeting is still on though, right?
19:21:59 <astearns> dgrogan: yes, but I haven’t seen the schedule to see what we conflict with. Is it available yet?
19:24:43 <Zakim> Zakim has left #css
19:26:32 <astearns> dgrogan: ah, it looks like we are not overlapping any of the 1-hour time slots: https://github.com/w3c/breakouts-day-2025/wiki/Session-Time-Slots
19:47:26 <projecto-> projecto- has joined #css
19:47:56 <leaverou_> leaverou_ has joined #css
19:48:57 <Rossen-> Rossen- has joined #css
19:49:27 <shans_> shans_ has joined #css
19:49:57 <sylvaing_> sylvaing_ has joined #css
20:08:09 <dgrogan> oh great, thank you for checking
20:31:38 <argyle> argyle has joined #css
21:26:00 <jfkthame> jfkthame has joined #css
22:39:44 <jfkthame> jfkthame has joined #css
22:52:32 <jfkthame> jfkthame has joined #css
23:10:38 <jfkthame> jfkthame has joined #css