16:52:13 <RRSAgent> RRSAgent has joined #css
16:52:13 <RRSAgent> logging to https://www.w3.org/2022/11/09-css-irc
16:52:16 <Zakim> RRSAgent, make logs Public
16:52:17 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:56:07 <Rossen_> present+
16:57:22 <argyle> argyle has joined #css
16:57:38 <jfkthame> jfkthame has joined #css
16:59:03 <flackr> flackr has joined #css
17:00:39 <khush> khush has joined #css
17:01:02 <oriol> oriol has joined #css
17:01:06 <dholbert> dholbert has joined #css
17:01:19 <lea> lea has joined #css
17:01:20 <Rossen_> we'll try to get going at 9:02am PST
17:01:22 <PaulG> present+
17:01:25 <flackr> present+
17:01:26 <lea> present+
17:01:28 <oriol> present+
17:01:37 <argyle> present+
17:01:44 <chris> chris has joined #css
17:02:10 <bramus> present+
17:02:21 <rachelandrew> present+
17:02:24 <khush> present+
17:02:25 <dholbert> present+
17:02:26 <fantasai> presnet+
17:02:28 <fantasai> present+
17:02:31 <chris> present+
17:02:34 <florian> present+
17:02:35 <emilio> present+
17:02:47 <fantasai> scribenick: fantasai
17:02:52 <fantasai> Topic: Administrative
17:02:57 <JakeA> present+
17:03:08 <alisonmaher> alisonmaher has joined #css
17:03:12 <alisonmaher> present+
17:03:47 <fantasai> Rossen_: This is about 1/5 the number of Agenda+ issues. We will need, to and will, have another long call at the end of this month on November 30th
17:03:50 <tantek> tantek has joined #css
17:04:08 <Morgan> Morgan has joined #Css
17:04:14 <astearns> not next week, week after (Nov 23)
17:04:19 <fantasai> Rossen_: I sent an email to the private list about next week, US holiday week, asking to see if people will be around and whether to cancel next week or not
17:04:24 <jensimmons> jensimmons has joined #css
17:04:37 <jensimmons> present+
17:04:43 <fantasai> s/next week/week after next week/
17:04:45 <Morgan> present+
17:04:55 <fantasai> Rossen_: Any other topics?
17:04:56 <tantek> present+
17:05:16 <Rossen_> fantasai: two things, Jen and I are organizing a workshop on layout
17:05:20 <florian> fantasai: 2 things: 1) Jen and I are organizing a workshop on inline layout next monday
17:05:30 <jensimmons> https://fantasai.inkedblade.net/style/events/inline-workshop
17:05:51 <florian> fantasai: second thing: can the chairs add the "needs edits" label when we resolve on stuff
17:06:36 <florian> fantasai: going to read through the spec top to bottom, make sure people understand, see if it addresses their use cases, and maybe find issues
17:06:44 <fantasai> s/going to/workshop is, going to/
17:06:51 <fantasai> Rossen_: Any other topics?
17:07:05 <fantasai> Topic: [meta] Co-authoring CSS Design Principles with the TAG
17:07:13 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7835
17:07:25 <fantasai> lea: As many aware, TAG maintains Web Platform Design Principles document
17:07:30 <fantasai> lea: including principles for CSS
17:07:32 <ydanic> ydanic has joined #css
17:07:43 <ydanic> present+
17:08:06 <fantasai> lea: Down the line will add principles to help authors with their APIs
17:08:24 <fantasai> lea: There is overlap between TAG and CSSWG, but need tighter integration
17:08:34 <fantasai> lea: and e.g. fold in the documents fantasai is maintaining
17:08:47 <fantasai> lea: Some ideas that came up was, maybe there could be TAG-CSS TF
17:08:54 <fantasai> lea: or maybe have a label in our repo that the CSSWG monitors
17:08:59 <fantasai> lea: open to whatever ideas
17:09:23 <fantasai> Rossen_: We already have a TAG/CSSWG TF called Houdini
17:09:36 <fantasai> lea: Houdini has a different focus, though. Can have multiple TFs with different focus
17:09:47 <fantasai> Rossen_: Also my way of nudging group, that we have a bunch of things we still need to discuss for Houdini :)
17:10:05 <fantasai> Rossen_: I think it's an opportunity for the CSSWG to engage and help us drive better clarity
17:10:10 <fantasai> Rossen_: and help implementers and authors
17:10:25 <fantasai> Rossen_: Design principles in TAG have had good engagement, and community seems to be fairly responsive to what's in there
17:10:28 <fantasai> Rossen_: so huge +1
17:10:44 <Rossen_> ack fantasai
17:10:44 <Zakim> fantasai, you wanted to comment on URLs
17:10:58 <dholbert> scribenick: dholbert
17:11:07 <dholbert> fantasai: the url you're linking to isn't a w3.org url
17:11:10 <bradk> bradk has joined #css
17:11:19 <dholbert> fantasai: github urls might not be around at various points
17:11:24 <lea> W3C URL: https://www.w3.org/TR/design-principles/
17:11:33 <bradk> present+
17:11:40 <fantasai> https://wiki.csswg.org/ideas/principles
17:11:40 <jfkthame> present+
17:11:42 <dholbert> fantasai: design principles: there's a document that I maintain on the wiki
17:11:50 <dholbert> fantasai: maybe we can take that as a list of bugs to fix
17:11:54 <fantasai> https://fantasai.inkedblade.net/weblog/2019/designing-css
17:12:01 <dholbert> fantasai: there's also this article^
17:12:29 <fantasai> s/points/points, so please get in the habit of using the w3.org URL. If its out of date, update it/
17:12:38 <lea> q+
17:12:40 <fantasai> scribenick: fantasai
17:12:42 <florian> https://wiki.csswg.org/faq
17:12:56 <fantasai> florian: Also some interesting material to recycle in the FAQ, goes into why CSS works the way it does
17:13:12 <fantasai> lea: I just wanted to add, one framing is that we're using this as a pilot for how we work with other WGs more broadly
17:13:26 <fantasai> lea: plan is to eventually collaborate with more WGs, so whatever we decide should be more broadly applicable
17:13:29 <Rossen_> ack lea
17:13:45 <Rossen_> ack fantasai
17:13:48 <dholbert> fantasai: we could follow model of internationalization wg
17:13:56 <dholbert> fantasai: file issues in multiple repos
17:14:03 <lea> +1 to fantasai's idea
17:14:03 <dholbert> fantasai: e.g. file issue in tag repo and csswg repo
17:14:14 <fantasai> s/csswg repo/tracking issue in csswg repo/
17:14:26 <fantasai> Rossen_: Please comment on any ideas about scope or work mode in the issue
17:14:35 <fantasai> Topic: [css-shapes-1] Updated CR of CSS Shapes? Administrative Tracker For external review / publication tracking issues
17:14:39 <chris> q+
17:14:42 <fantasai> github: github: https://github.com/w3c/csswg-drafts/issues/6450
17:14:58 <fantasai> chris: I'm whining about this thing not being published since 2014
17:15:11 <fantasai> chris: I went through all the commits since 2014 and updated the Changes list
17:15:19 <fantasai> chris: added implementation, split privsec section
17:15:23 <fantasai> chris: I think this is ready to go
17:15:28 <astearns> q+
17:15:33 <Rossen_> ack chris
17:15:40 <Rossen_> ack astearns
17:15:40 <fantasai> astearns: Thanks so much for doing that work
17:16:02 <fantasai> astearns: My preference would be to get the edits for reconciling with gradient syntax first, but since you've done this work, I'm happy to publish now and republish later with the edits
17:16:06 <fantasai> chris: sounds good to me
17:16:16 <fantasai> chris: If you thought those edits would be timely that would be fine, but if you think it'll confuse people
17:16:26 <fantasai> astearns: No, I am now good for publishing and I can't guarantee that my edits will be timely
17:16:36 <fantasai> Rossen_: +1, thanks for the help chris this is great
17:16:44 <fantasai> Rossen_: objections to publish CRD?
17:17:09 <fantasai> RESOLVED: Publish css-shapes-1 CRD
17:17:17 <fantasai> Rossen_: again, thanks Chris, for doing the work
17:17:25 <fantasai> Topic: [css-view-transitions-1] Behaviour of the finished promise
17:17:38 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7956
17:18:07 <fantasai> JakeA: When you start a view transition, you get an object back that has some promises that you can use to track various things
17:18:13 <fantasai> JakeA: one of these is the "finished" promise
17:18:24 <fantasai> JakeA: question is, what should happen if the DOM change is successful, but the transition is not?
17:18:34 <fantasai> JakeA: transition could not be successful in the case of misconfiguration, e.g. duplicate IDs
17:18:50 <fantasai> JakeA: could also mean that transition is abandoned halfway through, because more important transition coming in
17:18:59 <fantasai> JakeA: Originally spec would reject unless the transition gets to final frame
17:19:10 <fantasai> JakeA: goes through the whole duration of the transition
17:19:28 <fantasai> JakeA: Proposing that it finishes whenever it gets to the end state
17:19:37 <fantasai> JakeA: we were influenced by animation.finish()
17:19:44 <fantasai> JakeA: and animation.finished which will resolve
17:19:47 <flackr> +1
17:20:17 <fantasai> JakeA: Desire to change this came after showing them the APIs, and asking them to guess what it would do
17:20:27 <fantasai> JakeA: that seemed to be where people were leaning :)
17:20:40 <fantasai> Rossen_: +1 for taking the time
17:20:49 <fantasai> Rossen_: and alignment with animations is awesome
17:20:51 <fantasai> Rossen_: any objections?
17:20:59 <bramus> +1
17:20:59 <fantasai> RESOLVED: Accept proposal
17:21:32 <fantasai> JakeA: Yes, animation needs to have stopped (even if not completed), and user is looking at new state
17:21:43 <fantasai> Topic: [css-view-transitions-1] CSS selector keywords
17:21:49 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7960
17:22:05 <fantasai> khush: This is about resolving on the selector keywords
17:22:14 <fantasai> khush: last meeting we got through everything except #4
17:22:26 <fantasai> khush: This is a pseudo-element for providing isolation for blending the old and new snapshots
17:22:33 <fantasai> khush: it's a leaf of the tree, only has old and new snapshots
17:22:59 <fantasai> khush: In terms of suggestions for naming, using word 'effect' or 'image', something to indicate that only nodes under here are replaced elements
17:23:16 <fantasai> khush: and need to disambiguate from view-transition-group() which cna change position/size, and can have other view-transition elements underneath it
17:23:23 <fantasai> khush: if we go with view-transition-image-foo, what's foo?
17:24:03 <fantasai> khush: Con of using "set" is that it doesn't indicate that DOM order matters, "list" makes it look like any number of elements but can only have two, and "pair" is nicest but sometimes there's only one element
17:24:14 <fantasai> khush: e.g. if DOM element only exists on one side
17:24:24 <fantasai> khush: but if we're okay with that, my proposal is view-transition-image-pair
17:24:45 <Morgan> Morgan has joined #css
17:24:49 <Rossen_> fantasai: +1 to using a pair. conceptually you have two things being transitioned independently
17:24:57 <Rossen_> ack fantasai
17:25:06 <fantasai> fantasai: wrt image, i'm less sure
17:25:21 <fantasai> JakeA: Tab wanted view-transition-images for brevity, but ppl didn't like plural
17:25:28 <ydaniv> ydaniv has joined #css
17:25:36 <fantasai> fantasai: for brevity, could also drop the "image" part and just say "view-transition-pair"
17:25:51 <fantasai> khush: "view-transition-group" and "view-transition-pair" not immediately obvious what's the difference
17:26:11 <fantasai> khush: but I could go either way, "view-transition-pair" vs "view-transition-image-pair"
17:26:21 <fantasai> Rossen_: I think group vs pair will clash for many non-native speakers, but wouldn't object
17:26:40 <fantasai> JakeA: It's not something folks will select a lot, ppl will select it ... I don't know, if they want to remove isolation for some reason?
17:26:45 <fantasai> Rossen_: even more reason to use a longer name
17:26:47 <flackr> Agree with Rossen_, I have a slight preference for view-transition-image-pair for clarity
17:27:00 <JakeA> +1 to image-pair
17:27:02 <khush> +1
17:27:03 <fantasai> Rossen_: Proposed to resolve on view-transition-image-pair
17:27:06 <fantasai> wfm
17:27:11 <lea> as a non-native speaker, I don't think group and pair are that frequently confused. Are there languages that do not distinguish between group and pair?
17:27:12 <ydaniv> +1 to image-pair
17:27:28 <fantasai> Rossen_: objections?
17:27:37 <fantasai> RESOLVED: view-transition-image-pair
17:27:47 <fantasai> Topic: [css-view-transitions-1] when to update the pseudo element styles
17:27:55 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7812
17:28:16 <fantasai> khush: Resolution in the last meeting, recap
17:28:27 <fantasai> khush: feature creates a pseudo-element which has snapshot and position from new DOM
17:28:39 <fantasai> khush: live, in sense that new DOM's painting changes will be reflecting
17:28:47 <fantasai> khush: also if position / layout changes, will be reflected
17:29:03 <fantasai> khush: keeping these two in sync requires step where we do layout on author DOM, and then generate a UA stylesheet
17:29:16 <fantasai> khush: do we conceptually see this UA style sheet generation as part of style resolution
17:29:34 <fantasai> khush: e.g. if author changes something about the DOM element, should they get those changes reflected in the pseudo-element if they query via script?
17:29:47 <fantasai> khush: or do we treat this as an explicit step that's part of the feature, and there's a specific point where we get these two things synced up
17:29:53 <fantasai> khush: last time we resolved on two explicit points
17:29:58 <fantasai> khush: this is only relevant if dev queries using script
17:30:02 <fantasai> khush: two options are:
17:30:22 <fantasai> khush: 1. Always keep in sync, treat as part of style resolution. If you call getComputedStyle(), we'll have to resolve style, generate styles and give an answer
17:30:34 <fantasai> khush: 2. Defined point on a frame, so you'll get stale data, whatever was computed in the last frame
17:30:45 <flackr> q+
17:30:51 <fantasai> khush: I think keeping in sync is more correct, but it's also harder because you have to do this loop to resolve style
17:31:02 <fantasai> khush: and we don't have a strong use case for why author would need this to always be in sync
17:31:08 <emilio>  q+
17:31:10 <fantasai> khush: so my suggestion is go with 2 defined points where we do this step
17:31:17 <fantasai> khush: if they query after updating DOM, they'll get stale data
17:31:24 <fantasai> khush: and in the future if we want we can make it more correct
17:31:35 <fantasai> khush: so that all updates are guaranteed to reflect correctly
17:31:38 <Rossen_> ack flackr
17:31:48 <fantasai> flackr: My preference is for reflecting up to date values, because that's what will be presented on screen
17:31:51 <fantasai> flackr: so more consistent
17:32:02 <fantasai> flackr: we only have to do this if the author queries the style, so most of the time we won't be doing this extra style update
17:32:16 <Rossen_> ack emilio
17:32:27 <fantasai> emilio: what's the use case for querying these pseudo-elements, and is there a defined answer assuming can target elements in the pseudo tree?
17:32:41 <fantasai> emilio: can't you write selectors that match multiple of these elements?
17:33:08 <fantasai> khush: use case is developer customization, could use information about what the element's transform or size is
17:33:17 <fantasai> khush: can query existing API
17:33:27 <fantasai> khush: element's size will be its border-box size
17:33:35 <fantasai> khush: Some things not available now, e.g. ink overflow bounds
17:33:42 <fantasai> khush: unless we expose no API for it
17:33:59 <fantasai> khush: I don't have any strong use case, just a speculative maybe you want to do a funky animation thing
17:34:21 <fantasai> emilio: My point is there's no good answer, if you write ::part() and that something matches 2-3 elements, what does getComputedStyle return?
17:34:34 <Rossen_> q?
17:34:39 <fantasai> khush: getComputedStyle has option to query an exact pseudo-element, so you can pass ::view-transition-group(name) and get from that element
17:34:57 <fantasai> emilio: a pseudo-element selector can match multiple pseudo-elements, so is it well-defined what happens?
17:35:17 <fantasai> khush: Similar discussion for web animations API, if it matches multiple pseudo-elements, treat it like querySelector and return the first one
17:35:22 <fantasai> emilio: so well-defined, ok
17:35:28 <fantasai> emilio: if there's a good answer, then sure
17:35:43 <fantasai> emilio: I assume if it works for web animations, making it work for gcs also makes sense
17:36:12 <fantasai> khush: I think flackr mentioned he preferred if we get these in sync
17:36:18 <vmpstr> q+
17:36:33 <fantasai> khush: also my ideal preference, but would it be ok for implementation complexity if we didn't do that for now, and if a use case do it right later?
17:36:42 <fantasai> flackr: if you don't do that, values would always be a frame out of date
17:36:51 <fantasai> flackr: wouldn't be able to use them
17:37:00 <fantasai> khush: answer for first frame is correct
17:37:07 <fantasai> khush: after UA does consruction
17:37:16 <fantasai> khush: It's only if you change as part of RAF as part of ??
17:37:30 <fantasai> khush: We don't retarget animations now anyway, so you'll get visual jumps
17:37:43 <fantasai> flackr: I've seen authors do things in RAF every frame, to manually position other elements in response to frames
17:37:59 <Rossen_> ack vmpstr
17:38:10 <fantasai> vmpstr: My preference is not keeping it always up to date, it's because there's a distinction between keeping styles conceptually up to date
17:38:21 <fantasai> vmpstr: but this isn't technically style, but UA style sheet that needs to be updated
17:38:35 <fantasai> vmpstr: ensuring that these values are kept up to date as style is unnecessary, other than point flackr raised
17:38:49 <fantasai> vmpstr: so I would preferred to have a defined step and update rendering, this is when the stylesheet is updated to reflect DOM changes
17:39:10 <fantasai> vmpstr: reason is, from implementation perspective, we would have to force style and layout to get this information to put in stylesheet and it's a lot more forced work
17:39:19 <fantasai> vmpstr: seems a lot more rendering needs to be forced in these cases
17:39:51 <Rossen_> fantasai: why not both?
17:40:08 <fantasai> s/both/allow both/
17:40:09 <Rossen_> ack fantasai
17:40:26 <dholbert> fantasai: text wrapping
17:40:35 <fantasai> fantasai: make it a quality of implementation issue
17:40:46 <emilio> q+
17:40:51 <fantasai> fantasai: and if it becomes a problem, people can file bugs against the implementations
17:40:54 <flackr> sgtm to leave it up to implementer
17:40:59 <fantasai> fantasai: to improve their fidelity
17:41:15 <fantasai> khush: I think for wording, use "should"
17:41:21 <flackr> This is also similar to the way reading scroll position may be more or less out of sync on diff browsers
17:41:25 <khush> UA styles on the pseudo-DOM should stay in sync with author DOM for any developer observable API
17:41:53 <fantasai> emilio: I think this is quite different from text-wrapping, it's an API you're asking a question
17:42:04 <fantasai> emilio: I think we can't do hard thing if we do the hard thing if we do the easy thing at the beginning?
17:42:15 <fantasai> emilio: people will rely on whatever ansewr you give them
17:42:32 <dholbert> fantasai: but if you give them more accurate answers, would that be a problem?
17:42:39 <fantasai> emilio: maybe relying on perf characteristics
17:42:57 <fantasai> emilio: if in a loop, and then changing DOM, implicitly relying on existing behavior or else stuff becomes super slow
17:43:07 <fantasai> emilio: maybe I'm being too pessimistic...
17:43:13 <fantasai> emilio:  my preference would be to define one answer
17:43:24 <fantasai> Rossen_: more correct and harder way?
17:43:48 <fantasai> emilio: Don't particularly care. Do understand the implementation complexity. Also don't see a lot of use cases for this to begin with
17:44:01 <fantasai> Rossen_: I want us to move forward here, take a resolution that's going to unblock us quicker
17:44:25 <flackr> I suppose if we do the easy thing first we can always try to change it to the more correct thing and consider the compat risk then
17:44:31 <fantasai> Rossen_: going back to original proposal, that was for the easier one which we can get to basically go to market quicker
17:44:40 <fantasai> Rossen_: get implementation experience and feedback, that's initial ask?
17:44:51 <fantasai> khush: That would be nicer, that said my proposal was on the assumption that this would be easy to change later
17:45:01 <fantasai> khush: that is, if we make API more correct we would not have a compat risk
17:45:08 <fantasai> khush: but if we have a compat risk, then I'm ok to do the harder thing first
17:45:29 <fantasai> Rossen_: from point of view of API and its evolution, taking scoped resolution here doesn't preclude us doing better later
17:45:36 <fantasai> Rossen_: our decisions today are open to improvement tomorrow
17:46:01 <fantasai> khush: I didn't quite follow, what are we resolving on?
17:46:04 <fantasai> Rossen_: the easier one
17:46:15 <fantasai> khush: Emilio was concerned changing later would be bad for compat
17:46:19 <fantasai> emilio: I think so
17:46:27 <fantasai> emilio: since these are relatively expensive updates
17:46:36 <fantasai> emilio: it's very easy to depend on not doing hard work
17:46:45 <fantasai> Rossen_: If I'm hearing, you want to do harder work now now
17:46:51 <fantasai> emilio: I don't mind which we choose, as long as we choose one
17:47:13 <fantasai> khush: If we have to make one choice right now, and given uncertaintly about valid use case, we prefer developer ease over implementer ease so we do harder thing first
17:47:20 <fantasai> emilio: No strong opinion on which one
17:47:52 <fantasai> emilio: my point is, I think if we start with easy one, we can't switch to hard one
17:47:57 <fantasai> emilio: not leave it up to UA or future
17:48:11 <fantasai> emilio: let's just decide what we want
17:48:34 <fantasai> emilio: I've no strong opinion, but khush seems to think harder one is better for devs
17:48:41 <khush> UA styles on the pseudo-DOM stay in sync with author DOM for any developer observable API
17:48:50 <fantasai> khush: proposal ^
17:49:25 <dbaron> Present+
17:49:29 <fantasai> RESOLVED: UA styles on the pseudo-DOM stay in sync with author DOM for any developer observable API
17:49:53 <fantasai> Topic: [css-contain-2] Incomplete event definition for ContentVisibilityAutoStateChanged
17:50:01 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7603
17:50:29 <fantasai> oriol: This issue covers different things, but only want to discuss name of the event
17:50:38 <fantasai> oriol: contain introduced ContentVisiblityAutoStateChanged event
17:50:50 <fantasai> oriol: this is inconsistent naming, since other events they use the present tense and this is using past tense
17:51:03 <fantasai> oriol: there's even a proposed design principle in TAG about naming events about avoiding past tense
17:51:10 <fantasai> oriol: just some legacy events are using past tense
17:51:28 <fantasai> oriol: So should we align with this design principle?
17:51:34 <fantasai> oriol: This feature has already shipped in Blink in July or such
17:51:47 <fantasai> oriol: but maybe it could still be compatible to change or maybe Blink could support both for awhile or something like that
17:51:59 <fantasai> oriol: Firefox is implementing now, and WebKit has not implemented this property yet
17:52:32 <fantasai> florian: Do you want to change the name of the event and the object type or just the event?
17:52:36 <vmpstr> q+
17:52:37 <fantasai> oriol: It should be consistent
17:52:41 <flackr> I *think* this is the use counter for registrations: https://chromestatus.com/metrics/feature/timeline/popularity/4328
17:52:42 <emilio> ack emilio
17:52:55 <vmpstr> https://chromestatus.com/metrics/feature/popularity#ContentVisibilityAutoStateChangedHandlerRegistered
17:52:56 <Rossen_> ack vmpstr
17:53:15 <fantasai> vmpstr: On Chrome status there is 0.048% that register a handle for this event
17:53:22 <fantasai> vmpstr: it's a low usage but it's non-zero
17:53:51 <fantasai> Rossen_: is that above the threshold? Wasn't it 0.03%
17:54:10 <fantasai> vmpstr: Justification is that the state change has already happened, different from click event where you can preventDefault
17:54:16 <fantasai> vmpstr: but that's why it was named in the past tense
17:54:38 <flackr> Also animationstart, animationend, transitionstart, transitionend
17:54:40 <fantasai> oriol: form controls also have change event for afterwards, can't prevent change, and this event is in present
17:54:50 <emilio> Yeah, lots of precedents there, `visibilitychange` / `pageshow` / etc
17:54:54 <emilio> +1 for changing
17:55:16 <fantasai> Rossen_: Can we resolve to change, and if we get feedback strongly that this will be a problem, we can revisit?
17:55:26 <fantasai> Rossen_: from spec point of view, right thing to resolve is in favor of change
17:55:26 <fantasai> +1
17:55:27 <vmpstr> +1
17:55:31 <Rossen_> q?
17:55:45 <fantasai> RESOVLED: Change to present tense for ContentVisiblityAutoStateChanged (event and object)
17:56:15 <fantasai> Topic: [css-view-transitions-1] content-visibility: auto elements are relevant to the user during a transition
17:56:21 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7874
17:57:00 <fantasai> vmpstr: content-visibility: autho  not user relevant, they don't update rendering, so we can't tell if they've been tagged with a view transition name
17:57:12 <flackr> q+
17:57:23 <fantasai> vmpstr: so we'd like to say that such elements that are not relevant to the user can't participate in the view transition because they're far enough offscreen
17:57:39 <fantasai> flackr: my preference was element can participate, because could move on screen, but none of its descendants
17:57:50 <fantasai> vmpstr: sorry, meant the subtree elements cannot be detected as participating in this transition
17:57:56 <Rossen_> ack flackr
17:58:07 <fantasai> vmpstr: content-visiblity: auto only affects content
17:58:11 <fantasai> flackr: with that correct, good with that
17:58:20 <fantasai> Rossen_: proposal?
17:58:36 <fantasai> vmpstr: elements under content-visiblity:auto element that skip its contents cannot be discovered as participating in view transition
17:58:38 <flackr> +1
17:59:03 <fantasai> s/cannot/are not eligible to be/
17:59:12 <fantasai> florian: seems reasonable
17:59:13 <fantasai> +1
17:59:21 <fantasai> Rossen_: objections to resolving on that edited proposal?
17:59:42 <fantasai> RESOLVED: elements under content-visiblity:auto element that skip its contents are not eligible to participate in view transition
17:59:45 <fantasai> Topic: End
18:00:06 <fantasai> Rossen_: Reminder to reach out on private list if you have opinions about Thanksgiving week call
18:01:03 <fantasai> Meeting closed.
18:50:43 <Francis_Storr> Francis_Storr has joined #css
19:31:52 <bradk> bradk has joined #css
19:56:20 <bradk> bradk has joined #css
19:56:57 <bradk> bradk has joined #css
20:10:38 <Francis_Storr> Francis_Storr has joined #css
20:27:30 <projector> projector has joined #css
20:28:00 <leaverou> leaverou has joined #css
20:28:30 <Rossen> Rossen has joined #css
20:29:00 <shans> shans has joined #css
20:29:31 <sylvaing> sylvaing has joined #css
20:34:19 <Zakim> Zakim has left #css
21:02:24 <karlcow> karlcow has joined #css
23:00:22 <karlcow> karlcow has joined #css