16:58:15 <RRSAgent> RRSAgent has joined #css
16:58:15 <RRSAgent> logging to https://www.w3.org/2022/11/23-css-irc
16:58:17 <Zakim> RRSAgent, make logs Public
16:58:18 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:58:20 <flackr> flackr has joined #css
16:58:42 <ydaniv_> ydaniv_ has joined #css
16:58:53 <khush> khush has joined #css
16:58:57 <khush> present+
16:59:07 <dbaron> Present+
16:59:14 <JakeA> Present+
16:59:22 <ydaniv_> present+
16:59:51 <flackr> present+
16:59:59 <tantek> tantek has joined #css
17:00:02 <jfkthame> jfkthame has joined #css
17:00:27 <argyle> present+
17:00:48 <fremy> fremy has joined #css
17:01:06 <TabAtkins> ScribeNick: TabAtkins
17:01:38 <fremy> present+
17:01:41 <JakeA> TabAtkins: I guess the "(if it exists on the element)" bit is redundant then
17:02:41 <rachelandrew> present+
17:03:13 <miriam> present+
17:03:25 <vmpstr> present+
17:03:44 <oriol> present+
17:04:14 <emilio> present+
17:04:27 <chrishtr> present+
17:04:43 <TabAtkins> Topic: Keyframe offsets outside of the animations
17:04:45 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7825#issuecomment-1306090794
17:04:49 <TabAtkins> Rossen_: Proposed resolution linked in the agenda
17:05:00 <plinss> present+
17:05:19 <jfkthame> present+
17:05:20 <bradk> bradk has joined #css
17:05:24 <futhark_> futhark_ has joined #css
17:05:35 <futhark_> present+
17:05:48 <bradk> present+
17:05:50 <TabAtkins> flackr: with sla, especiallyw ith dynamicly defined keyframes, you can end up with offsets outside the range
17:06:15 <TabAtkins> flackr: Proposed solution is to allow these. They don't change the animation's active duration, but their effects still apply and just get clipped to the end of the animation duration.
17:06:33 <TabAtkins> flackr: And allow it for classic animations too (negative %, >100%)
17:06:45 <TabAtkins> +1 to this
17:06:55 <TabAtkins> we allow overshoot in other places like gradients
17:07:00 <bramus> present+
17:07:13 <TabAtkins> RESOLVED: Accept proposal to allow keyframes outside of the animation's duration.
17:08:14 <TabAtkins> s/And allow/But don't allow/
17:08:26 <TabAtkins> s/animations too/animations, due to possible compat/
17:08:49 <TabAtkins> Topic: JS API for view-timeline-inset
17:08:52 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7748#issuecomment-1306097703
17:09:27 <TabAtkins> flackr: Proposal was to allow insets in the ViewTimelineOptions object as either a string or a pair of CSSNumericValues
17:09:40 <TabAtkins> flackr: But I recalled on other issues there were parsing concerns for things other than idents
17:09:47 <TabAtkins> flackr: So i pinged Tab on this issue
17:09:57 <TabAtkins> flackr: So yes we should add this attr, but should it support strings?
17:10:12 <fantasai> scribe+
17:10:33 <fantasai> TabAtkins: While we aren't 100% consistent, we try to avoid doing CSS parsing on small instances of CSS values
17:10:36 <fantasai> ... in APIs like this
17:10:50 <fantasai> ... because in the rare cases where you need to do an escape, it needs to be double-escaped
17:11:01 <fantasai> ... The general rule for identifiers is that we don't parse stirngs [missed]
17:11:13 <fantasai> ... You can express any string as an ident if it's properly escaped
17:11:28 <fantasai> ... [something else]
17:11:43 <fantasai> ... So I proposed not allowing string-based values here, and just sticking with the TypedOM objects
17:11:47 <fantasai> ... They're easy to work with
17:11:53 <fantasai> flackr: should still allow string for auto
17:12:14 <fantasai> TabAtkins: especially because we need to allow identifiers, we'd need to do string parsing in identifiers
17:12:23 <fantasai> ... if you wanted a name with a weird thing, would need to double-escape
17:12:30 <fantasai> ... would have string just be the literal value of the string
17:12:37 <fantasai> ... which means we can't mix keywords with other values in strings
17:12:51 <Rossen_> ack fantasai
17:13:03 <TabAtkins> fantasai: I think the arg for wanting to allow string-based is that you can pipe getComputedStyle() right back into it
17:13:19 <TabAtkins> fantasai: and just easier to write as a literal "2px" rather than CSS.px(2)
17:13:43 <TabAtkins> fantasai: re ident escaping concerns, there's no custom idents in this API so escapes are never necessary anyway
17:13:47 <Rossen_> q?
17:13:53 <flackr> q+
17:14:19 <TabAtkins> flackr: I'm a little curious - if we want to use typedom objects going forward, is there easy ways to get that?
17:14:48 <fantasai> TabAtkins: There's a TypedOM for computed style
17:15:00 <fantasai> ... not all values have that defined, but for simple things it should work
17:15:07 <fantasai> ... for more complex ones, will just get a string
17:15:28 <TabAtkins> flackr: so maybe that alleviates some simple concerns
17:15:49 <TabAtkins> fantasai: Well what's the computed style of -inset? It's one or two values, so what will we get out of typed om computed style?
17:16:04 <TabAtkins> flackr: this is a new property, we can define it to be what we want for the input
17:16:14 <TabAtkins> fantasai: So what would that be?
17:16:23 <TabAtkins> flackr: A sequence of numeric or identifer values
17:16:35 <delan> present+
17:16:42 <Rossen_> ack flackr
17:17:24 <dbaron> https://developer.mozilla.org/en-US/docs/Web/API/CSS_Typed_OM_API#browser_compatibility
17:17:35 <TabAtkins> flackr: So I propose we onlya ccept the typedom representation, and specify the computed typed om for the property to give the same values, to support passthru
17:18:01 <TabAtkins> dbaron: is the API not gonna work right if the impl wants to do this without typed om?
17:18:18 <TabAtkins> dbaron: I ask because typedom is implemented right now in chromium but not gecko or webkit
17:18:24 <TabAtkins> flackr: sounds like it would be an issue
17:18:34 <iank_> I believe webkit has an implemtnation just not shipped yet
17:19:01 <TabAtkins> fantasai: What's the downside of stringbased?
17:19:11 <TabAtkins> fantasai: If we have both you can use whichever is easiest
17:19:31 <ydaniv_> +1 for both
17:19:53 <TabAtkins> TabAtkins: my only concern is impl complexity, and slightly being more consistent about parsing css vs taking strings literally, but i can go either way
17:20:20 <fantasai> Proposed to accept both string and TypedOM 2-value sequence inset within ViewTimeline Options
17:20:29 <TabAtkins> PROPOSED RESOLUTION: Offsets accept either a string or a sequence of typedom values
17:20:36 <fantasai> s/Offsets/Insets/
17:20:57 <TabAtkins> chrishtr: Do we need to specify how the string is parsed?
17:21:01 <TabAtkins> flackr: Matches the CSS property
17:21:28 <TabAtkins> RESOLVED: Insets accept either a string containing CSS, or a sequence of TypedOM values.
17:21:52 <fantasai> Proposed that existing ViewTimeline.startOffset and .endOffset attributes incorporate inset calculations (so that they continue to accurately represent the start/end scroll offsets of the ViewTimeline within the scroll container).
17:22:31 <flackr> +1
17:23:08 <ydaniv_> +1
17:23:17 <bramus> +1
17:23:24 <TabAtkins> RESOLVED: Accept fantasai's proposal for resolution 2
17:23:56 <Rossen_> s/Accept fantasai's proposal for resolution 2/Existing ViewTimeline.startOffset and .endOffset attributes incorporate inset calculations/
17:24:09 <TabAtkins> fantasai: final, do we expose the viewtimelineoptions on the timeline itself? doesn't seem to be use-cases. But we *could* add an inset or startInset/endInset to the timeline if we wanted to.
17:24:15 <flackr> +1 to deferring for now
17:24:19 <fantasai> s/viewtimelineoptions/inset values/
17:24:47 <flackr> (this is resolution 3 from https://github.com/w3c/csswg-drafts/issues/7748#issuecomment-1306097703 )
17:25:13 <TabAtkins> fantasai: not sure if it needs to be done or not, so unless someone thinks it's important we recommend resolving not to do it for now
17:25:50 <TabAtkins> RESOLVED: Defer adding inset properties to the timeline object
17:26:08 <TabAtkins> Topic: Declarative anchor fallback positioning
17:26:11 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7757
17:26:32 <fantasai> TabAtkins: At previous meeting when introduced anchor positioning
17:26:48 <fantasai> TabAtkins: Emilio brought up that XUL had similar functionality, and had a simple declarative way to express fallbacks
17:26:59 <fantasai> TabAtkins: This is good, current fallback is very complex
17:27:07 <fantasai> TabAtkins: I have a proposal in this thread for solving that
17:27:23 <fantasai> TabAtkins: Can still use full complex positioning if necessary, but this should solve common cases
17:27:34 <fantasai> TabAtkins: Not looking for resolution right now, just wanted to get attention for review and comment
17:27:43 <fantasai> iank_: Can you briefly describe this mode?
17:27:55 <fantasai> TabAtkins: The way you opt into it, rather than declaring a side to align to in the anchor
17:28:12 <fantasai> TabAtkins: Instead you say "auto", and it will automatically choose the opposite side of the property you're setting
17:28:23 <fantasai> TabAtkins: but if you would trigger fallback positioning, we flip around
17:28:32 <fantasai> TabAtkins: and align your bototm edge to the top edge
17:28:39 <fantasai> TabAtkins: so we can do this positoining without affecting layout
17:28:50 <fantasai> TabAtkins: then if neither works, we go to normal fallback rules
17:29:00 <fantasai> iank_: idk that you need auto on opposite side
17:29:07 <fantasai> iank_: how does this interact with maximum number of fallbacks?
17:29:26 <fantasai> TabAtkins: need auto on other side because if not, there's nothing to fall back to
17:29:40 <fantasai> TabAtkins: If you specify this for your top property, we can't switch to using bottom if your bottom is zero
17:29:43 <fantasai> iank_: ok
17:29:48 <fantasai> TabAtkins: wrt maximums, this will be part of that list
17:30:02 <fantasai> TabAtkins: effectively position fallback will have an extra entry, so this will be factored into that maximum
17:30:03 <fremy> q+
17:30:10 <fantasai> iank_: does this mean you need to set on both insets?
17:30:23 <fantasai> TabAtkins: no, set one to anchor and the other to auto
17:30:29 <fantasai> TabAtkins: it will be naturally sized
17:30:36 <fantasai> TabAtkins: we'll swap the properties if we need to for fallback reasons
17:30:42 <fantasai> [note that auto is the initial value]
17:30:52 <fantasai> iank_: You can embed an anchor inside of a calc() expression
17:31:09 <fantasai> iank_: so if you're not using the ?? anchor, what does that calc expression resolve to?
17:31:13 <fantasai> TabAtkins: after doing the flip?
17:31:20 <fantasai> TabAtkins: it resolves to the appropriate other edge
17:31:28 <fantasai> TabAtkins: Luckily because insets are specified in opposite directions
17:31:29 <Rossen_> ack dbaron
17:31:43 <fantasai> TabAtkins: if you use calc() to put you 10px from bottom edge, that same calc will work against the top
17:31:54 <fantasai> iank_: so you're taking the whole calc() and putting it in the other property, and the other property becomes auto?
17:32:02 <fantasai> TabAtkins: yes, we resolve exactly as if you'd done it on the other side
17:32:15 <fantasai> TabAtkins: just as position fallback already works, but we make it automatic for obvious placement
17:32:27 <fantasai> iank_: sounds fine, just concerned about magical swapping of computed values at layout time
17:32:41 <fantasai> TabAtkins: This is exactly position fallback, the same feature, we're just giving you one for free
17:32:53 <fantasai> iank_: not exactly, because you're taking e.g. top is auto, bottom is calc expression with anchor
17:33:08 <fantasai> iank_: the position fallback then is like the top becomes that calc function and bottom becomes auto
17:33:21 <fantasai> iank_: oh, and I see, you're saying that this will automatically populate a fallback position entry with those two things
17:33:26 <fantasai> iank_: okay, that makes sense
17:33:37 <fantasai> iank_: if you can write that as a note, this is how it should be implemented, that would be helpful
17:33:47 <fantasai> fremy: Small question
17:33:51 <fantasai> fremy: because I believe this would be common
17:34:01 <fantasai> fremy: what happens if you do it for top and left, and if so what happens?
17:34:17 <fantasai> TabAtkins: what exactly will happen is a great question, which I have not thought through the implications of!
17:34:27 <dino> dino has joined #css
17:34:46 <fantasai> TabAtkins: I don't have an answer for you yet.
17:35:06 <fantasai> TabAtkins: I don't think it's hugely important what the answer is... worst case maybe generate 3 fallbacks, generating vertical flip, horizontal flip, or both
17:35:09 <fantasai> TabAtkins: will think about it
17:35:22 <iank_> likely want the flips in the logical space vs the physical?
17:35:23 <fantasai> fremy: I guess maybe we can check what tooltips do on iOS/MacOS/Windows
17:35:32 <iank_> block flip vs. vertical flip
17:35:39 <fantasai> +1 iank
17:35:51 <Rossen_> ack fremy
17:35:56 <fantasai> TabAtkins: just wanted to get feedback, this was helpful
17:35:58 <TabAtkins> well, doesn't matter, point is you flip to the opposite side of wherever it's specified
17:36:28 <TabAtkins> Topic: Add view() to animation-timeline
17:36:30 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7587
17:37:06 <fantasai> PR: https://github.com/w3c/csswg-drafts/pull/7988
17:37:21 <TabAtkins> flackr: so we defined scroll() for anonymous timelines, but htere was no convenient way to describe an anonymous view timeline
17:37:32 <TabAtkins> flackr: I believe elika already has a PR for this, so asking for resolution to use that
17:37:34 <fantasai> -> https://github.com/w3c/csswg-drafts/pull/7988/files
17:37:47 <bramus> +1 on resolving.
17:38:03 <TabAtkins> TabAtkins: I assume that anonymous view timelines work similar to anonymous scroll timelines? Just look in the tree for the nearest obvious thing?
17:38:14 <TabAtkins> fantasai: Yes, it looks up to the nearest scroll container
17:38:18 <TabAtkins> +1
17:38:40 <fantasai> ACTION fantasai: clarify that it applies to the element it's specified on
17:38:57 <TabAtkins> RESOLVED: Accept fantasai's PR for adding view() function to animation-timeline
17:39:15 <TabAtkins> Topic: Additional resource-state pseudo-classes for img/picture
17:39:39 <TabAtkins> fantasai: someone asked about pseudos for images to indicate whtehr they're loading, failed, stalled
17:39:45 <TabAtkins> fantasai: So does the WG think this is reasonable?
17:40:03 <dbaron> I think Gecko has internal pseudo-classes that do this
17:40:55 <TabAtkins> fantasai: do we make loading &  buffering both amtch when a video is trying to buffer and when an image is loading?
17:41:02 <TabAtkins> TabAtkins: Like allow both to apply to either condition?
17:41:28 <TabAtkins> fantasai: Yeah they're both loading, tho i'm not sure if the words are appropraite
17:41:34 <TabAtkins> TabAtkins: I'm happy to defer that to editors
17:41:39 <bradk> applies to any element that can take time loading, eg iframes?
17:41:53 <TabAtkins> Rossen_: Sounds like there's general approval, should we reoslve on "yes, details TBD"?
17:41:56 <bradk> +1
17:41:58 <bramus> +1
17:41:58 <chrishtr> +1
17:42:06 <TabAtkins> fantasai: We can propose edits and come back.
17:42:32 <TabAtkins> Topic: Allow more pseudo-classes after pseudo-elements
17:43:21 <fantasai> TabAtkins: Currently, pseudo-elements allow a few pseudos to be put after them, :hover etc.
17:43:41 <fantasai> TabAtkins: question is whether to allow combinatoric ones (:is()/:not()/:where()) to be applied as well
17:43:48 <JakeA> q+
17:43:58 <fantasai> TabAtkins: Further, some pseudo-elements represent specific elements elsewhere in the DOM
17:44:18 <fantasai> TabAtkins: wondering if specific pseudo-elements can opt into allowing additional pseudo-elements
17:44:23 <fantasai> TabAtkins: but that's a different issue
17:44:30 <fantasai> TabAtkins: but first issue, allowing combinatoric ones
17:44:40 <fantasai> TabAtkins: Contents are still restricted to the user-action pseudos
17:44:53 <fantasai> JakeA: we're interested in this for view-transitions
17:44:54 <Rossen_> ack JakeA
17:44:59 <fantasai> JakeA: want to know if old or new view is only-child
17:45:03 <fantasai> JakeA: so allowing that would be useful
17:45:39 <TabAtkins> fantasai: two issues, one is we have a set of pseudos that are already allowed, and do we allow them to be put in :is()/etc
17:45:57 <TabAtkins> fantasai: second is allowing other pseudos on case-by-case basis, we should talk about that separately
17:46:00 <tantek> present+
17:46:24 <TabAtkins> fantasai: for is/not/where, it's about whether we can express the combinations of the user action pseudos
17:46:50 <fantasai> https://github.com/w3c/csswg-drafts/pull/8041/files
17:47:02 <tantek> could see this being useful for webdevs
17:47:33 <fantasai> oriol: these use forgiving parsing, would invalid pseudos be valid within them?
17:47:36 <fantasai> TabAtkins: yes
17:47:50 <fantasai> TabAtkins: this would allow more safely adding more pseudo-classes to a selector in the future
17:48:00 <fantasai> Rossen_: any other opinions?
17:48:44 <fantasai> TabAtkins: proposed, allow the "logical combination pseudo-classes" after pseudo-elements, with their contents having the same restrictions as the pseudo-elements themselves otherwise would have
17:49:14 <fantasai> RESOLVED: allow the "logical combination pseudo-classes" after pseudo-elements, with their contents having the same restrictions as the pseudo-elements themselves otherwise would have
17:49:46 <TabAtkins> fantasai: and more generically i want to resolve that the logical-combo pseudos can be used *anywhere* their contents are allowed
17:50:01 <TabAtkins> TabAtkins: I agree with being more generic if we can get away with it
17:50:03 <fantasai> fantasai: wanted to ask if anyone saw a problem with that
17:50:04 <tantek> no objection
17:50:13 <TabAtkins> (Don't think there's much issue beyond just implementing it.)
17:50:59 <TabAtkins> RESOLVED: Allow the logical-combination pseudo-classes generically, anywhere their contents are allowed.
17:51:30 <fremy> q+
17:51:39 <fantasai> TabAtkins: Second part of issue, should we allow additional pseudo-classes other than user-action pseudo-classes to be put after speudo-elements?
17:51:43 <fantasai> s/speu/pseu/
17:52:04 <fantasai> fremy: On previous resolution, does that mean you can change styles on ::before:hover ?
17:52:07 <fantasai> TabAtkins: yes
17:52:22 <fantasai> fremy: what if you create a loop with ::first-line:hover?
17:52:31 <fantasai> TabAtkins: hover loop, we already have that problem
17:52:38 <fantasai> Consider p:hover ::first-line
17:52:44 <fantasai> fremy: ok
17:53:23 <JakeA> I'm still +1 this
17:53:33 <bradk> +1
17:53:34 <fantasai> TabAtkins: back to issue, should we allow lifting restrictions on pseudo-elements followed by pseudo-classes?
17:53:43 <argyle> +1
17:53:46 <miriam> +1
17:53:48 <JakeA> q+
17:54:00 <Rossen_> ack fremy
17:54:02 <TabAtkins> fantasai: Okay as long as we do it as an allowlist, rather than blanket allowing
17:54:04 <Rossen_> ack JakeA
17:54:20 <TabAtkins> JakeA: would folks be happy with us using :only-child for view transitions?
17:54:34 <fantasai> TabAtkins: As long as it matches intent
17:54:49 <fantasai> TabAtkins: defined as up to two children, and this one says if you have only one
17:55:03 <fantasai> JakeA: But usually it doesn't count pseudos...
17:55:12 <fantasai> JakeA: but I guess if we're appying it to a pseudo
17:55:17 <bradk> :only-pseudo-element?
17:55:18 <fantasai> TabAtkins: pseudo-elements live in the tree
17:56:12 <TabAtkins> RESOLVED: Allow pseudo-elements to define additional pseudo-classes they allow to be placed after them.
17:56:51 <fantasai> Topic: Paired defaults
17:57:04 <fantasai> gitub: https://github.com/w3c/csswg-drafts/issues/7837
17:57:17 <fantasai> delan: This issue won't affect implementation complexity much, about what makes sense to authors
17:57:27 <fantasai> delan: some highlight pseudos have default background color and default color
17:57:33 <fantasai> delan: e.g. ::selection has default colors
17:57:36 <fantasai> delan: and ::target-text
17:57:52 <fantasai> delan: but it's not true for e.g. spelling/grammar error, where default styles add squiggly lines but don't change colors
17:57:59 <fantasai> delan: ::selection has special behavior called "paried defaults"
17:58:03 <fantasai> delan: rule is there for compat reasons
17:58:17 <fantasai> delan: means that those default colors only get used
17:58:25 <fantasai> delan: if neither color nor background was set by the author
17:58:29 <fantasai> delan: beside compat, has some other benefits
17:58:35 <fantasai> delan: prevents illegible combination of colors
17:58:48 <fantasai> delan: e.g. some browsers have light text for selections, and some have dark text
17:58:57 <fantasai> delan: so question is, should these apply to other highlight types?
17:59:05 <fantasai> delan: or only to ::selection?
17:59:38 <fantasai> florian: Point about default colors being relied on makes sense, so I would say yes it should apply to all
17:59:55 <fantasai> emilio: Gecko doesn't have this magic if the author specifies selection styles
18:00:01 <fantasai> emilio: do you know the state of interop?
18:00:07 <fantasai> delan: it's also in Gecko
18:00:29 <fantasai> emilio: if you specify ::selection  { background: green ; color: green; } we wouldn't magically infer the color
18:00:32 <fantasai> delan: that's separate
18:00:51 <fantasai> delan: this is if the author only sets one of these properties, does it get the UA color or does it get transparent/currentcolor
18:00:55 <fantasai> delan: inverting is a separate issue
18:01:04 <fantasai> florian: If we don't do it we have a risk of browser-dependent illegible things, and that's bad
18:01:43 <fantasai> fantasai: I think propsoed resolution is, do we apply paired efaults to all highlights
18:02:01 <fantasai> fantasai: so do we have any objections? if not we can resolve
18:02:25 <fantasai> s/efaults/defaults/
18:02:34 <fantasai> delan: so resolution is that they would apply to all fo the highights?
18:02:48 <fantasai> fantasai:
18:03:00 <fantasai> florian: we have delan, fantasai, and myself agreeing and nobody is pushing back
18:03:09 <fantasai> Rossen_: I'm not hearing any objections, so let's resolve
18:03:18 <fantasai> Rossen_: if anyone thinks about this we can come back and change if necessary
18:03:28 <fantasai> RESOLVED: paired defaults apply to all highlights
18:03:39 <fantasai> Rossen_: Happy Thanksgiving for those in the US
18:03:52 <fantasai> Rossen_: Remember next week is a long call, starts 7am Pacific for 3 hours
18:03:55 <fantasai> Meeting closed.
18:07:46 <fantasai> Topic: end
18:14:02 <Rossen_> Zakim, end meeting
18:14:02 <Zakim> As of this point the attendees have been khush, dbaron, JakeA, ydaniv_, flackr, argyle, fremy, fantasai, rachelandrew, miriam, vmpstr, oriol, emilio, chrishtr, plinss, jfkthame,
18:14:05 <Zakim> ... futhark_, bradk, bramus, delan, tantek
18:14:05 <Zakim> RRSAgent, please draft minutes v2
18:14:05 <RRSAgent> I have made the request to generate https://www.w3.org/2022/11/23-css-minutes.html Zakim
18:14:07 <Zakim> I am happy to have been of service, Rossen_; please remember to excuse RRSAgent.  Goodbye
18:14:11 <Zakim> Zakim has left #css
18:41:19 <jfkthame> jfkthame has left #css
20:54:04 <projector> projector has joined #css
20:54:34 <leaverou> leaverou has joined #css
20:55:04 <Rossen> Rossen has joined #css
20:55:35 <shans> shans has joined #css
20:56:05 <sylvaing> sylvaing has joined #css
22:11:02 <dbaron> I just added support for a "take up" command to github-bot.
22:11:18 <dbaron> This will allow setting up a new topic with one command rather than two.
22:11:38 <dbaron> In particular, the command "github-bot, take up URL-TO-GITHUB-ISSUE" will cause the bot to:
22:11:39 <github-bot> github-bot has joined #css
22:11:46 <dbaron> - switch to logging to that issue
22:11:58 <dbaron> - generate a "Topic:" line that is the title of that issue
22:12:38 <dbaron> You can give the bot the command with "/me" syntax (and it will correctly generate the "Topic:" line without the /me)
22:18:14 <astearns> dbaron: does it work with URLs to comments, like https://github.com/w3c/csswg-drafts/issues/5648#issuecomment-1240067326?
22:18:45 <dbaron> let me check :-)
22:23:47 <dbaron> astearns, yes, it works: https://github.com/dbaron/wgmeeting-github-ircbot/commit/ab988f1ce3724bb125a907421f464fb8ba63b633
22:25:41 <astearns> cool, thanks
23:26:34 <karlcow> karlcow has joined #css