16:56:54 <RRSAgent> RRSAgent has joined #css
16:56:59 <RRSAgent> logging to https://www.w3.org/2022/12/21-css-irc
16:56:59 <Zakim> RRSAgent, make logs Public
16:57:00 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:59:19 <flackr> flackr has joined #css
17:00:28 <argyle> present+
17:00:33 <rachelandrew> present+
17:00:33 <flackr> present+
17:00:50 <ydaniv> ydaniv has joined #css
17:00:54 <bramus> present+
17:01:35 <dholbert> dholbert has joined #css
17:02:06 <Rossen_> present+
17:02:11 <ydaniv> present+
17:02:35 <jfkthame> jfkthame has joined #css
17:03:18 <emilio> present+
17:03:18 <dholbert> present+
17:03:18 <jensimmons> present+
17:03:29 <TabAtkins> ScribeNick: TabAtkins
17:04:26 <jfkthame> present+
17:05:15 <plinss> present+
17:05:15 <fantasai> present+
17:05:15 <Rossen_> https://github.com/w3c/csswg-drafts/issues/8248
17:05:15 <dbaron> Present+
17:05:43 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/8248
17:05:43 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8248.
17:05:43 <github-bot> Topic: [css-nesting] Choose Nesting syntax — Option 3, 4 or 5?
17:05:53 <nigel> nigel has joined #css
17:06:04 <TabAtkins> jensimmons: We ran this survey and wrote an article on webkit.org
17:06:09 <nigel> Present+ NIgel_Megitt
17:06:11 <TabAtkins> jensimmons: Even tho it was bumpy, i think the reuslts are very clear
17:06:18 <TabAtkins> jensimmons: There's a lot of comments on twitter/masto/HN
17:06:22 <TabAtkins> jensimmons: And a very clear pref for Option 3
17:06:23 <nigel> s/NIgel_Megitt/Nigel_Megitt
17:07:02 <plinss> q+
17:07:07 <TabAtkins> TabAtkins: sounds like strong consensus
17:07:17 <smfr> smfr has joined #css
17:07:18 <TabAtkins> plinss: I have concerns.
17:07:22 <alisonmaher> alisonmaher has joined #css
17:07:28 <TabAtkins> plinss: I don't think we should decide purely by the poll.
17:07:36 <TabAtkins> plinss: That'd be fair if we had 2 or 3 options that were equiv
17:07:39 <Rossen_> ack plinss
17:07:48 <TabAtkins> plinss: But I think this is more involved than that, there are ramifications people werne't taking into account
17:08:00 <TabAtkins> plinss: Looks like a lot of people just want Sass, that's most votes for Option 3.
17:08:01 <astearns> q+
17:08:16 <ntim> ntim has joined #css
17:08:23 <TabAtkins> plinss: And the more I think about it, the more concerns I have with mixing selectors and properties.
17:08:30 <TabAtkins> plinss: Really not happy with the future constraints we're putting on the language.
17:08:51 <TabAtkins> plinss: Fundamental problem is tha tanything that's not obviously a property defaults to be a selector, adn that constraitns our abilitiy to ever extend property syntax again.
17:09:08 <TabAtkins> plinss: The default needs to be that it's a property and we need an indicator that it's a selector
17:09:20 <astearns> q-
17:09:21 <Rossen_> q?
17:09:21 <TabAtkins> plinss: Like @nest. I know that was rejected for verfbosity, but I'd be okay with a bare @
17:09:40 <TabAtkins> plinss: A lot of people are also supportive of OPtion 3 with mandatory &, and we could have @ do that.
17:09:48 <TabAtkins> plinss: So that's a compromise I can live with.
17:09:56 <TabAtkins> q+
17:10:32 <TabAtkins> astearns: I think I agree with peter to a certain extent, but I would want to have an idea of the kinds of things we are cutting ourselves off from
17:10:55 <TabAtkins> astearns: I don't know what it is that prioritizing selectors over props will make difficult to extend in the future
17:11:12 <chris_> chris_ has joined #css
17:11:17 <TabAtkins> plinss: For example, I think we wouldn't hav e been able to do custom props the way we did if we had this
17:11:44 <TabAtkins> plinss: Once upon a time idents started with a letter or a single dash, and I'm not sure what else we'll want to do with properties, but we'll have to invent some weird syntax.
17:12:13 <TabAtkins> astearns: I think I agree with the argument that if Sass nesting had never existed, that when we were adding this feature we'd do something more like option 5; we wouldn't consdier option 3 at all.
17:12:27 <TabAtkins> astearns: but the existence of Sass nesting is a design constraint that we really do have to respond to, and option 3 does do that
17:12:39 <TabAtkins> plinss: Another alt is we say screw it and adopt the sass syntax
17:12:40 <bradk> bradk has joined #css
17:12:47 <TabAtkins> plinss: A lot of people are opposed, but i'm curious if we can't afford it.
17:13:01 <TabAtkins> plinss: Back when we first started this, at Gecko, I had everyone telling us we couldn't do CSS due to perf.
17:13:13 <TabAtkins> plinss: Maybe we can afford a recursive descent parser now and do Sass syntax.
17:13:20 <TabAtkins> plinss: And tha'ts something I'd be okay with too.
17:13:26 <bradk> present+
17:13:30 <fantasai> s/too/too, because you're fully resolving everything/
17:13:32 <TabAtkins> plinss: I think it sitll gives us some potential for conflict but it's not as bad.
17:13:41 <smfr> present+
17:13:43 <fantasai> scribe+
17:13:58 <fantasai> TabAtkins: What we are prevented from extending in the future
17:14:04 <fantasai> TabAtkins: 2 aspects: need to avoid selectors and ??
17:14:09 <chris_> present+
17:14:12 <fantasai> TabAtkins: on selector side, means we can never add a new bare function syntax
17:14:28 <fantasai> TabAtkins: We have pseudo-classes that are functional, that's fine. But we can't add a plain function to selectors
17:14:46 <fantasai> TabAtkins: That doesn't seem like it would be a problem, lots of space for symbol-prefixed
17:15:12 <fantasai> TabAtkins: over on properties, need to start property with either ident or function
17:15:17 <fantasai> TabAtkins: can put stuff after ident/function
17:15:20 <fantasai> TabAtkins: just can't put before the property
17:15:39 <fantasai> TabAtkins: That does mean if we had done this in the past, we'd have had to do some compat analysis about allowing ident to have --start
17:15:53 <Rossen_> ack TabAtkins
17:15:53 <fantasai> TabAtkins: that was a change, but technically also needed to care about compat because previously invalid now valid
17:16:11 <fantasai> TabAtkins: those sorts of changes are likely ... if we need to change ident syntax in the future, we can navigate those, and unlikely to look like selectors too much
17:16:20 <fantasai> TabAtkins: doubt problem, and we have compat tools to figure it out
17:16:30 <fantasai> TabAtkins: beyond changing ident syntax, I don't think we're losing any important syntax space
17:16:55 <fantasai> TabAtkins: some ideas to put things before the properties, e.g. early sketches of additive cascade used + before/after property name to indicate prepend/append
17:16:59 <fantasai> TabAtkins: but we can choose an alternative syntax
17:17:04 <fantasai> TabAtkins: in practice not a large restriction
17:17:10 <fantasai> TabAtkins: large amount of syntax space we've left unexplored
17:17:22 <fantasai> TabAtkins: and rare places where might collide, can analyze so not shooting in the dark
17:17:36 <fantasai> TabAtkins: More generally, we've been talking about nesting syntax for a year, need to close the door at some point
17:17:49 <fantasai> TabAtkins: can't keep having ppl propose new alternatives
17:17:58 <fantasai> TabAtkins: latest option 3 is good improvement, and people like it
17:18:17 <fantasai> TabAtkins: if we continue messing around, and ignoring things like 80%-90% poll results, is going to make ppl angry, and won't accomplish anything
17:18:26 <fantasai> TabAtkins: more polls will result in similar result
17:18:34 <argyle> q+
17:18:42 <jensimmons> q+
17:18:59 <lea> lea has joined #css
17:19:01 <fantasai> Rossen_: Want to close the discussion, lots of tension but I also want to get to at least one more issue
17:19:19 <fantasai> Rossen_: will close the queue, drain it, and if we can't have a path for resolution, then we'll put to GH
17:19:30 <lea> present+
17:19:41 <TabAtkins> plinss: I hear what your'e saying about syntax
17:19:55 <fantasai> plinss: I hear what you're saying about syntax, but just want to be clear that we're blocking ourselves off from prepending to an ident. I think it's a decision we'll reget
17:19:55 <TabAtkins> plinss: We're blocking ourselves from prepending a property with anything that's not an ident, and I think we'll regret that
17:20:02 <TabAtkins> plinss: I think default to selectors was the wrong choice here
17:20:10 <TabAtkins> plinss: I'm sympathetic to "we've discussed forever"
17:20:19 <TabAtkins> plinss: But don't think we should take a decision that has problems we haven't throught thru
17:20:25 <TabAtkins> plinss: We ahve responsibility for th elong term
17:20:31 <TabAtkins> plinss: No t just to respond to the long term
17:20:55 <TabAtkins> fantasai: I'm sympathetic to peter's arguments but also agree with TAb that we need to clsoe on this
17:21:12 <TabAtkins> fantasai: In term sof forward compat, we shoudl be setting things up within these decl blocks that the parse stops at either a semicolon or a block
17:21:29 <TabAtkins> fantasai: and you throw out whatever as invalid
17:21:33 <Rossen_> ack fantasai
17:21:39 <TabAtkins> fantasai: Gives us some space to work with
17:21:47 <TabAtkins> fantasai: So we shoudl design invalid in a way that gives us room to extend
17:21:50 <Rossen_> Zakim close queue
17:22:04 <TabAtkins> fantasai: think we can
17:22:16 <TabAtkins> fantasai: and if there's specific bits of syntax we want to leave open for extensions, we can do that
17:22:31 <TabAtkins> fantasai: like if it starts with @ without an at-rule treat as a prop, etc
17:22:51 <TabAtkins> fantasai: But I think we should go with Option 3 as we have it now. Maybe small tweaks to nesure max compatibility, but think we shoudl go with that for now
17:22:55 <Rossen_> ack argyle
17:22:58 <TabAtkins> argyle: Happy to see this discussed
17:23:29 <TabAtkins> argyle: Wanted to mention we can't do exact Sass syntax. We can match as much as we can, but "just do Sass" isn't on the table. We've adopted as many tradeoffs we can.
17:23:39 <TabAtkins> argyle: So I think this has been in the tumbler enough to be a pearl
17:23:48 <bradk> +1 to possibly prepending ‘@‘ in the future to indicate it is a selector that follows
17:23:51 <TabAtkins> argyle: I like where we are now with all the options
17:24:03 <TabAtkins> (Happy to take an issue for that btw)
17:24:21 <TabAtkins> jensimmons: I think last time I expressed my opinion I was agaisnt option 3 and liked 4, and liked 5 when it came up
17:24:41 <TabAtkins> jensimmons: But while writing the article I started really hating OPtion 4 with a passion. There's still something about 5 that appeals, but I really think we should resolve on option 3, hopefully today
17:24:48 <lea> q?
17:24:52 <TabAtkins> jensimmons: I agree with Peter that a lot of people potentially didn't understand the gotchas with 3
17:24:56 <Rossen_> ack jensimmons
17:25:02 <Rossen_> Zakim, close queue
17:25:02 <Zakim> ok, Rossen_, the speaker queue is closed
17:25:13 <TabAtkins> jensimmons: But there were so manyc omments from people who really did udnerstand the gotchas, including several asking for madatory ampersand
17:25:19 <TabAtkins> jensimmons: So I think there is enough understanding from webdevs
17:25:36 <fantasai> s/madatory ampersand/mandatory ampersand as a way to compensate
17:25:38 <TabAtkins> jensimmons: Also convos internally in Apple - maybe we will find a way to do lookahead that's fast enough.
17:25:49 <TabAtkins> jensimmons: so we would be able to relax the syntax restriction
17:26:03 <TabAtkins> (Option 3 is indeed extensible to Sass version later, if we want)
17:26:29 <TabAtkins> jensimmons: I agree polls shoudln't dictate us, but given the fact that Option 3's big gotcha is webdevs might get confused, but watching their comments I got a lot of confidence tha toption 3 is the way to go
17:27:01 <bradk> +1 to resolving on option 3 today
17:27:02 <TabAtkins> Rossen_: So I've closed the queue. There's some clear statement of concern raised by Peter, and a clear voice of wanting to adopt 3 and make it work.
17:27:07 <bramus> +1 on moving foward with option 3
17:27:07 <lea> Many people got confused at my polls as well. I think the article did a great job at explaining the options, and no matter what we do, people will get confused anyway.
17:27:13 <matthieudubet> matthieudubet has joined #css
17:27:16 <lea> +1 on resolving on option 3 today
17:27:26 <TabAtkins> Rossen_: So I'd like to try for a resolution, we'll see if we get a strong objection.
17:28:12 <TabAtkins> plinss: I'm objecting to option 3 as it stands. Okay with trying to refine it further, but don't think it's the right decision as it stands.
17:28:28 <lea> Related to refining option 3 further: https://github.com/w3c/csswg-drafts/issues/7961
17:28:31 <TabAtkins> Rossen_: So to be clear - we want to narrow on Option 3 with options to refine it.
17:29:04 <TabAtkins> Rossen_: [doing a straw poll]
17:29:23 <TabAtkins> Rossen_: Options are 3, 4, or 5 as stated in the poll.
17:29:30 <bradk> 3
17:29:30 <argyle> 3
17:29:30 <flackr> 3
17:29:31 <lea> 3
17:29:31 <TabAtkins> 3
17:29:31 <fantasai> 3
17:29:31 <bramus> 3
17:29:35 <jensimmons> 3
17:29:41 <ntim> 3
17:29:46 <dholbert> 3
17:29:49 <matthieudubet> 3
17:29:51 <miriam> 3
17:30:05 <rachelandrew> 3
17:30:52 <fantasai> Conditional on ; terminating the selector parse
17:31:21 <TabAtkins> It does already do that, yeah
17:31:26 <TabAtkins> (the details are in Syntax)
17:31:57 <lea> q?
17:32:11 <TabAtkins> See https://w3c.github.io/csswg-drafts/css-syntax/#consume-qualified-rule for the ;-termination
17:32:37 <TabAtkins> fantasai: Note that my support is specifically if semicolon terminates the selector parse, so we can extend in the future more safely
17:32:39 <dbaron> how many valid selector beginnings are we accepting if we take option 3?
17:32:57 <fantasai> TabAtkins: Algorithm already terminates on ; if you think you're parsing a selector
17:33:33 <dbaron> (is it more than &, :, and combinator symbols?)
17:33:44 <fantasai> (no, I don't think it is)
17:33:49 <TabAtkins> dbaron, anything other than ident or function is a valid selector beginning, so long as you don't encounter a ; before the {
17:34:10 <chris_> 3
17:34:14 <dbaron> abstain
17:34:21 <nigel> abstain
17:34:23 <astearns> abstain
17:34:25 <jfkthame> abstain
17:34:28 <ydaniv> abstain
17:34:28 <smfr> abstain
17:34:29 <dino> dino has joined #css
17:34:29 <florian> abstain
17:34:38 <Rossen_> abstain
17:34:43 <dbaron> (abstaining because I think we could refine 3, I think)
17:34:47 <gtalbot> gtalbot has joined #css
17:35:15 <nigel> (Having read the comments around the poll, refining 3 seems like the best option)
17:35:27 <bradk> or some people are on call but not paying attention
17:35:36 <TabAtkins> Rossen_: Looks balanced between 3, abstain, and not saying anything, don't think we can resolve on that
17:35:40 <astearns> I think we need an issue on the specific problem of 3 boxing in syntax, with examples and possible ameliorations
17:35:47 <lea> q+
17:35:50 <TabAtkins> Rossen_: Can we leave Option 3 as the only path forward to refine?
17:36:03 <TabAtkins> Rossen_: Peter are you okay with that path forward?
17:36:39 <TabAtkins> plinss: I'm fine with improving our efforts on improving option 3, i'm not okay with excluding any new ideas
17:36:59 <TabAtkins> Rossen_: Right, just want to narrow down to option 3 from the options we have now
17:37:22 <TabAtkins> Rossen_: dbaron, you had an issue?
17:37:29 <TabAtkins> dbaron: Think we're better off working it out in an issue.
17:37:40 <flackr> I think a parser switch would be fine if we had to do it. Could be confusing but developers shouldn't switch back to property syntax after nesting selectors.
17:38:07 <TabAtkins> Rossen_: So we're rejecting Options 4 and 5, and continuing to refine Option 3. Is that a resolution?
17:38:11 <astearns> I disagree with that suggestion, flackr :)
17:38:25 <flackr> :)
17:38:26 <TabAtkins> lea: It looksk like there's a strong sentiment behind option 3 "but refine it", but it seems tha trefining means different things to different people
17:38:41 <TabAtkins> lea: Peter seems to be saying something more - not mixing selectors and decls in the same context.
17:38:50 <TabAtkins> lea: So it might be reasonable to have a lis to fthings we're looking to refine.
17:39:19 <TabAtkins> plinss: to clarify, i'm not fully opposed to mixing selectors and props at all, i just think we need a system that favors a property unless it's explicitly indicated as a selector
17:40:02 <TabAtkins> Rossen_: I want to close down this discussion today. So proposed resolution: narrowing down to Option 3, with continuing improvement before it's accepted
17:40:20 <dbaron> I think plinss's "single mechanism" might be too strong, but I think we could certainly find a different balance of which future syntax goes down the property path versus the selector path without changing any valid-today syntax in option 3.
17:40:52 <TabAtkins> fantasai: Just want some clarity - it seems Peter wants to separate out property/selector syntax with some symbol that indicates "you're now in selector mode" and he wont' accept anything other than that. That's not option 3, it's a previous option we've already considered.
17:41:01 <TabAtkins> fantasai: But OPtion 3 is interweaving mostly freely.
17:41:09 <argyle> option 1 as nesting-1, work out option 3 as nesting-2.. still think that's a valid plan forward
17:41:21 <chris_> we can go back to that previously rejected option if there is new information, yes
17:41:25 <TabAtkins> dbaron: I think one of peter's concerns was the % of stuff that goes down selector vs proeprty path, and where future things that are invalid today will go
17:41:45 <TabAtkins> dbaron: I think we can work out something that puts less stuff down the selector path and more down the property path.
17:42:06 <TabAtkins> fantasai: I think things that are invalid today, both go down the same path - parse until you hit the semicolon then throw it away as invalid.
17:42:33 <TabAtkins> plinss: I'm fine with david's refinement. Don't need a single way to say it's a selector - i'd prefer it, but a few ways will work too.
17:42:44 <TabAtkins> fantasai: Right now the final indicator is a semicolon or a {.
17:43:08 <TabAtkins> fantasai: if you're saying "i want specifically the three symbols" not combinators, that's something else
17:43:31 <TabAtkins> fantasai: If that's the main ojbection we can go back and say you *have* to start the selector with a simple selector
17:44:02 <lea> q?
17:44:03 <TabAtkins> plinss: My problem with that is any random new combiantor we add will hav eto be treated as a selector. It's open-ended, and I want it to not be open-ended. that's the crux of my ojbection.
17:44:13 <TabAtkins> (this was a really long 10min timebox)
17:44:32 <TabAtkins> lea: We're already nearly full on combinators anyway, probably future ones need to be /foo/ or something
17:45:01 <TabAtkins> plinss: We can maybe say "only today's combinators and a slash, nothing else", but I think that's limiting
17:45:10 <fantasai> I agree with that being too limiting
17:45:10 <dbaron> (I think we only have one or two ASCII characters left for combinators anyway.)
17:45:31 <TabAtkins> Rossen_: Ending the topic. I called for objections. Are there any?
17:45:38 <TabAtkins> Rossen_: No objections.
17:45:48 <chris_> \o/ progress!
17:45:50 <TabAtkins> RESOLVED: Reject options 4 and 5, go with option 3 with continuing refinement
17:46:31 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/2075
17:46:31 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/2075.
17:46:31 <github-bot> Topic: [web-animations-1] Don't preserve current time for scroll linked animations when changing playbackRate
17:47:02 <TabAtkins> flackr: We set up SLA so the time of th etimeline in which you play them isn't used for the start time, that would lead to skew with pages starting their SLA after the scroll started
17:47:17 <TabAtkins> flackr: We didn't account for some of the other APIs tho. I did an audit and playbackRate is the only one we haven't fixed yet.
17:47:31 <TabAtkins> flackr: So this proposal is that SLA doesn't try to preserve their current time when you change playback rate
17:47:58 <TabAtkins> flackr: I landed a simple fix, but Kevin brought up that when you reverse the naimation via negative playback rate, we shoudl fix it the same way as when you actually do a reversed animations.
17:48:05 <TabAtkins> flackr: So I landed a fix to change the start time there.
17:48:16 <TabAtkins> flackr: This aligns the playbackRate change to the behavior when you call .play()
17:48:21 <Rossen_> Zakim, open queue
17:48:21 <Zakim> ok, Rossen_, the speaker queue is open
17:48:34 <TabAtkins> I didn't look in detail but the expl makes sense to me
17:49:05 <TabAtkins> Rossen_: Objections?
17:49:17 <TabAtkins> RESOLVED: Accept flackr's fix
17:49:30 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/5261
17:49:30 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/5261.
17:49:30 <github-bot> Topic: [scroll-animations] Behavior of scroll-linked animations in the first frame
17:49:50 <TabAtkins> flackr: So SLA are based on layout of elements
17:49:56 <TabAtkins> flackr: but they can be discovered during style parse
17:50:09 <TabAtkins> flackr: and SLA can affect the style and layout
17:50:18 <TabAtkins> flackr: So we need to define the interaction during the initial lifecycle update
17:50:57 <TabAtkins> flackr: I have a PR that updates similarly to RO - after doing style and layout, you can do one more loop to handle SLA you've found. Unlike RO it's bounded to a single loop, and it runs in parallel with ResizeObserver so it's not an additional loop on top of that.
17:52:20 <TabAtkins> flackr: Anders prefers the approach where JS-constructred scroll timelines, we also don't freshen their time until after style and layout, so authors can observe they don't have a time initially, but after the style/layout update we'd repeat with times. I don't have a strong pref so I'm okay with that unless people feel we should force a style/layout immediately
17:52:35 <TabAtkins> +1
17:52:47 <TabAtkins> emilio: What are implications of not doing this second pass?
17:53:01 <TabAtkins> emilio: Is it just we don't start a timeline bc theres no scroller, so they see it next frame?
17:53:29 <TabAtkins> flackr: Yes, the first frame is incorrect because no SLA is done. Often completely missing th eanimation style, which I think is unacceptable due to likely flickering
17:53:41 <TabAtkins> smfr: Is this unique to SLA becuase the scroll position is input and you don't know it until layout?
17:53:50 <TabAtkins> flackr: No... sorta
17:53:56 <TabAtkins> smfr: Unsure why it's not a problem with nromal animations
17:54:13 <TabAtkins> flackr: We update animations at the point they're discovered-- you're right, determining the timeline time requires a layout update
17:54:35 <TabAtkins> emilio: And when are you proposing to run the second pass? unconditionally, or only when you discover new timeline aniamtions?
17:54:44 <TabAtkins> flackr: ONly when discovering new animations, adn only once per lifecycle update
17:55:05 <TabAtkins> flackr: We can define it to either be animations discovered during the style/layout cycle - idea is we'd have a flag on these timelines and check if it's a non-empty set
17:55:23 <TabAtkins> emilio: Do we want to do it with script-triggered udpates, or more like RO where it's only [...] loop?
17:55:28 <TabAtkins> flackr: My proposal is to only do RO
17:55:32 <TabAtkins> emilio: I think that's slightly better
17:55:42 <TabAtkins> emilio: We have some things that do similar, like focus fixup and stuff
17:56:01 <TabAtkins> emilio: Just we ahve several things that can trigger multiple passes and need to make sure they're properly defined
17:56:15 <TabAtkins> emilio: what happens if you do two script queries?
17:56:27 <TabAtkins> emilio: You ahve a pending style change, do gBCR(), and that discovers new timelines
17:56:35 <TabAtkins> emilio: Would a second gBCR() return a different result?
17:56:36 <ydaniv> q+
17:56:53 <TabAtkins> flackr: By spec, no. SCroll timelines only update their time at the start of the frame and during this discovery, at RO time.
17:57:07 <TabAtkins> emilio: Okay as long as this doesn't make us return something inconsistent during a single frame i think that's fine
17:57:29 <TabAtkins> ydaniv: The point where times are incorrect is just when the page loads and there's no scroll, right?
17:57:38 <TabAtkins> flackr: This can happen for any inserted content
17:57:48 <TabAtkins> flackr: So if you insert a scroller that's not laid out yet, it'll happen too
17:57:53 <TabAtkins> emilio: Or if display property changes
17:58:12 <TabAtkins> ydaniv: so it might require devs to have something like "always pull once on rAF" to make sure they have the correct time?
17:58:35 <TabAtkins> flackr: If you waited for rAF... yeah you'd have to poll it once
17:58:36 <smfr> s/pull/poll/ ?
17:58:45 <Rossen_> ack ydaniv
17:58:46 <ydaniv> poll (:
17:58:48 <TabAtkins> flackr: because the scroll timeline would not have determiend its correct time yet
17:58:58 <TabAtkins> flackr: It will be the time the frame is produced, but rAF happens before that
17:59:43 <TabAtkins> ydaniv: might be a good idea to prevent - sounds like a footgun to me if any change might get us into a wrong current timeline
17:59:56 <TabAtkins> flackr: This goes back to emilio's comment about JS-forced updates
18:00:12 <TabAtkins> flackr: If we decided it did, it would give you the correct result in these cases, but it also makes it a larger potential perf footgun
18:00:38 <TabAtkins> flackr: My argument for why this is okay is that this is consistent with RO - it'll be wrong at the same times.
18:00:53 <TabAtkins> flackr: So not inventing a new footgun, just following the path of an existing one.
18:01:20 <TabAtkins> emilio: main concern is that RO... you can't query RO arbitrarily, only get your callback invoked
18:01:32 <TabAtkins> emilio: So if there are use-cases to get the right answer from script, that might be slightly preferable
18:01:42 <TabAtkins> emilio: But my pref is also to have a well-defined time during the frame that does the right thing
18:02:01 <TabAtkins> Rossen_: Given we're over time, we can take this to the issue or do you have a scoped part of this resolution to take up?
18:02:34 <TabAtkins> flackr: I think we can resolve that we will repeat the layout for newly-discovered timelines in the lifecycle, but leave to the side whether forced style updates will do this as well
18:02:42 <TabAtkins> Rossen_: Objections to the scoped reoslution?
18:02:44 <TabAtkins> emilio: works for me
18:03:09 <TabAtkins> RESOLVED: Newly-discovered timelines trigger a new layout at the RO portion fo the frame lifecycle. (Maybe other times, tbd.)
18:03:16 <TabAtkins> github-bot, end topic
18:04:17 <astearns> TabAtkins: fantasai please look at https://github.com/w3c/csswg-drafts/issues/7413#issuecomment-1360444854 to see if we can resolve async
18:05:11 <Rossen_> Zakim, end meeting
18:05:11 <Zakim> As of this point the attendees have been argyle, rachelandrew, flackr, bramus, Rossen_, ydaniv, emilio, dholbert, jensimmons, jfkthame, plinss, fantasai, dbaron, NIgel_Megitt,
18:05:14 <Zakim> ... bradk, smfr, chris_, lea
18:05:14 <Zakim> RRSAgent, please draft minutes v2
18:05:16 <RRSAgent> I have made the request to generate https://www.w3.org/2022/12/21-css-minutes.html Zakim
18:05:23 <Zakim> I am happy to have been of service, Rossen_; please remember to excuse RRSAgent.  Goodbye
18:05:23 <Zakim> Zakim has left #css
18:59:11 <jensimmons> jensimmons has joined #css
19:37:30 <bradk> bradk has joined #css
19:46:25 <bradk> bradk has joined #css