- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 01 Aug 2022 18:58:13 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `dispatching highlight events`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: dispatching highlight events<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7513<br> <TabAtkins> dandclark: so pointer events with highlights, this is about making highlight pseudos interactive like for a spellchecker<br> <TabAtkins> dandclark: first q is how do we dispatch these events, what's the event order<br> <TabAtkins> dandclark: first i assume the highlight object is the right thing to receive the event, rather than the individual ranges<br> <TabAtkins> dandclark: If i have a bunch of ranges on a single highlight, i probably want to do the same thing for each<br> <TabAtkins> dandclark: seems silly to have to set an event listener on each range, especially as the highlight moves<br> <TabAtkins> dandclark: and when considering dispatches, need to consider there can be multiple types of highlights, and possibly overlapping<br> <TabAtkins> dandclark: like a find-on-page that emphasizes and scrolls, and also a spellcheck that underlines misspelled words and shows spelling suggestions<br> <TabAtkins> dandclark: might want one of those to eat the click, so spelling error can win over find-on-page<br> <TabAtkins> dandclark: so i can talk about a fe wapproaches<br> <TabAtkins> dandclark: in the issue, version A is each highlight gets its own event<br> <TabAtkins> dandclark: in descending priority order<br> <TabAtkins> dandclark: they can be cancelable, so the default is to advance to the next highlight, and you can preventDefault()<br> <TabAtkins> dandclark: suspicious to fire an arbitrary number of events for a single action tho<br> <TabAtkins> dandclark: approach B is a single event for the top priority highlight, define event path so it goes thru other highlights, then bubbles to dom tree<br> <TabAtkins> dandclark: this seems like pretty normal appraoch. but there's a web compat problem<br> <emilio> q+<br> <TabAtkins> dandclark: currently pointer events can only ever be an element<br> <TabAtkins> dandclark: but now suddenly they can have non-element targets<br> <TabAtkins> dandclark: so might break assumptions<br> <TabAtkins> dandclark: the Edge explainer suggests lying about the event target to get around this<br> <TabAtkins> dandclark: thinking abou tit more, think it's not the right approach<br> <TabAtkins> dandclark: Approach C is a combo. we dispatch two events, one for highlights, one for dom tree. highlight one propagates thru overlapping highlights. if it's not preventDefault'd by the end, we fire a new one on the dom tree<br> <TabAtkins> dandclark: that dual-event appraoch is where I lean now<br> <flackr> q+<br> <TabAtkins> q+<br> <astearns> ack emilio<br> <astearns> q+<br> <TabAtkins> emilio: rather than messing witht he dom events and retargeting, can we add an api to highlight that tells "is point X intersecting the highlight?"? seems like that would let you do what you want with regular dom events<br> <TabAtkins> emilio: you handle the pointer event and ask the highlights if the point overlaps, and just deal with normal dom event<br> <TabAtkins> emilio: Seems simpler but still gives all the use-cases<br> <TabAtkins> emilio: If you ahve two objects, handling pointer event on one or the other...<br> <TabAtkins> emilio: the normal element pointer event should still work even if you click on the highlight<br> <TabAtkins> emilio: seems simpler and less risky, and doesn't introduce new event model<br> <TabAtkins> emilio: and will work with touch events, etc<br> <TabAtkins> emilio: curious if it's been considered?<br> <dandclark> q+<br> <TabAtkins> TabAtkins: so assumption is you'd iterate thru all your highlights and check?<br> <TabAtkins> emilio: Yes. and they can check if it's been defaulted, you can deal with the order yourself, etc.<br> <TabAtkins> dandclark: this seems useful for- given i have a click with an offset, show me all the highlights under this location? or go thru each highlight in the registry and check?<br> <emilio> boolean intersects(long clientX, long clientY)<br> <bkardell_> emilio: that is on highlight?<br> <TabAtkins> dandclark: Can def see if there's a pointer even thandler on the body, and i get an event, could ask platform for all the highlights at this point<br> <TabAtkins> emilio: was thinking about method on the highlight object<br> <TabAtkins> emilio: so you iterate over the highlights i nthe order you want<br> <TabAtkins> emilio: but that should provide all the flexibility you'll ever need<br> <TabAtkins> emilio: If we want something more convenient, could put one on the highlight registry that gives back all of them<br> <TabAtkins> emilio: would just be sugar over a for loop<br> <TabAtkins> emilio: so could use if you want a central place to handle all the highlights<br> <TabAtkins> emilio: but might also want to deal with each highlight separately<br> <astearns> ack flackr<br> <TabAtkins> flackr: My point was partially overlapped with emilio, concerned about a special event befor ethe dom event<br> <TabAtkins> flackr: could consider the highlight to be the normal action, so if the normal event wasn't defaulted you dispatch to highlight<br> <TabAtkins> flackr: longer term, we want to support css pseudo targets, wondering if that helps so we can just target those<br> <TabAtkins> dandclark: the highlight pseudo is a pseudo object, it's a little special...<br> <TabAtkins> flackr: i think my main concern is whether those should be given the event first<br> <TabAtkins> flackr: I think visually the highlight is behind the text, so from dev pov the element should get first crack, and pseudo gets opportunity after<br> <astearns> ack dbaron<br> <astearns> ack astearns<br> <TabAtkins> q-<br> <TabAtkins> dbaron: i think it's worth trying to get event.stopPropagation vs preventDefault to behave as closely as possible to normal<br> <TabAtkins> dbaron: I think what dan was originally defining was to make pD act like SP<br> <TabAtkins> dbaron: Hope we can do something better even if the dom event spec needs to expose some extra concepts<br> <TabAtkins> dbaron: thoughts on emilio's proposal<br> <TabAtkins> dbaron: first is i'm a little concerned a bout an appraoch tha tforces you to add event listeners to the doc, for cases where impls want to make optimizations for passive listeners<br> <TabAtkins> dbaron: if it's an event type where registering a non-passive listener, and you need to register non-passive for the highlight, you have to take the perf penalty document-wide<br> <TabAtkins> dbaron: that seems undesirable<br> <emilio> q+<br> <TabAtkins> dbaron: so i think that's a reason you might want to have EL registration be on more specific targets<br> <TabAtkins> dandclark: I like the simplicity of emilio's idea.<br> <TabAtkins> dandclark: if we can find a way around the perf hit<br> <astearns> ack dandclark<br> <TabAtkins> emilio: the initial proposal was about clicks<br> <astearns> ack emilio<br> <TabAtkins> emilio: don't think we can get much opt about passive vs non-passive event listeners<br> <TabAtkins> emilio: don't see how having highlights doesn't prevent you from losing optimizations<br> <TabAtkins> dbaron: what you said about the way to use the proposal is put an El on the document, and look up the point<br> <TabAtkins> dbaron: And that way of using it can be problematic<br> <TabAtkins> emilio: right, if you care about scroll and things that benefit from passive<br> <TabAtkins> emilio: But API doesn't let you use it for other event types<br> <TabAtkins> dbaron: I think when it's like "this is only for clicks *right now*", unsure we want to design around that<br> <TabAtkins> emilio: So API right now takes an x/y<br> <TabAtkins> emilio: Have clear text for mouse events to resolve that<br> <florian> q?<br> <TabAtkins> emilio: could let the method take an event object instead, so we can limit it to certain event types<br> <astearns> ack dbaron<br> <Zakim> dbaron, you wanted to comment on what inputs emilio's API needs<br> <TabAtkins> dbaron: ah yeah other point id' forgot. i think taking x/y doesn't handle [missed]<br> <TabAtkins> dbaron: you might click a piece of text with highlights that obscures another piece with highlights<br> <TabAtkins> dbaron: you're probably interested in the top element's highlihts, not the obscured one<br> <flackr> qq+<br> <TabAtkins> emilio: could define the api similar to getelementfrompoint where you do account for hit-testing<br> <TabAtkins> emilio: could define to only care about rects, like union the ranges<br> <florian> q+<br> <TabAtkins> emilio: or like elementFromPoint which cares about hit-testing and p-e:none/etc<br> <TabAtkins> emilio: Seems you could get that with just an x/y if you define it to do hit-testing<br> <TabAtkins> dbaron: yeah that sounds like it works<br> <florian> q-<br> <TabAtkins> emilio: So define it in terms of elementsFromPoint<br> <TabAtkins> emilio: If any of the elements intersect the highlight... something like that<br> <TabAtkins> emilio: specific semantics for intersecting highlights could be left to...<br> <astearns> q+<br> <TabAtkins> emilio: if both intersect the consumer can choose<br> <astearns> ack flackr<br> <Zakim> flackr, you wanted to react to dbaron<br> <TabAtkins> flackr: I think x/y works if you can get highlights on the targeted element<br> <TabAtkins> flackr: that'll account for hit-testing<br> <TabAtkins> flackr: but this is def going to be a perf issue, even if limited to mouse events<br> <TabAtkins> flackr: people might want to drag highlights, so they'll have pointerstart, and that means we have to delay scrolling<br> <TabAtkins> flackr: but if we fire on the highlight we can recognize it won't stop scrolling<br> <TabAtkins> emilio: but that would penalize other scenarios<br> <TabAtkins> emilio: not sure what the best way to do it is<br> <TabAtkins> emilio: needs real thought especially for pointerdown<br> <florian> q+<br> <TabAtkins> emilio: [missed due to truck outside]<br> <TabAtkins> emilio: there are use-cases for pointerdown<br> <TabAtkins> emilio: if we extend proposal, we'd dispatch to highlights, then to web content... we'd do it for every event type ayone would care about<br> <TabAtkins> flackr: highlight needs to be in the event target tree, but yeah currently tree is strictly ancestor tree so that would be a disconnect<br> <TabAtkins> astearns: q about emilio's proposal<br> <TabAtkins> astearns: you get coords, ask document fo rhighlights.<br> <TabAtkins> astearns: are we still able to have top priority highlight prevent other highlights from responding?<br> <TabAtkins> emilio: Yes, just check if the event was preventDefault'd and return rather than moving on to the next highlight<br> <dbaron> (do you mean stopPropagation or preventDefault for that case?)<br> <TabAtkins> (don't think it matters for the discussion)<br> <TabAtkins> astearns: So it's manual?<br> <TabAtkins> TabAtkins: Yes, all fully manually handled, they're not fired on the highlights by the browser stuff<br> <TabAtkins> fremy: So if you have multiple types of code doing highlights they don't know about each other<br> <TabAtkins> fremy: How can they work together/<br> <TabAtkins> emilio: Initial proposal was a bool on the highlight<br> <TabAtkins> emilio: If you need to be aware of one vs the other you need a central place to do it<br> <TabAtkins> TabAtkins: Right, given dan's initial use-cases (scroll and spellcheck) you *need* them to coordinate with each other anyway<br> <TabAtkins> emilio: with my proposal there's no change to event prop. you fire the same vents as with no highlights<br> <TabAtkins> emilio: Up to the website to either centralize their highlight handling, or have different listeners that handle them separately<br> <TabAtkins> fremy: but you can't decide which acts first<br> <TabAtkins> emilio: with a bool and two coords appraoch, that's right bc you have to handle the highlights<br> <dandclark> q+<br> <TabAtkins> emilio: But if we have the method on the highlight registry that returns highlights in order, you can check yourself if the one you're in charge of is first<br> <astearns> ack astearns<br> <TabAtkins> fremy: So if you're not, do you try again?<br> <TabAtkins> emilio: If you don't have event listeners in the right order you can have weirdness<br> <TabAtkins> fremy: But order isn't one order<br> <TabAtkins> fremy: Not sure there's one correct order<br> <TabAtkins> dbaron: i think emilio's proposal is that page author has to write their own event registraation system if they want to deal with multiple highlights<br> <TabAtkins> dbaron: we provide an api in the platform that says "here's the ordered list of highlights affected by this" and the author can process the list with their own reg system however they want<br> <TabAtkins> fremy: Yeah, just weird we don't provide that<br> <TabAtkins> fremy: you assume libraries will cooperate, not clear to me they will if they're different sources<br> <fantasai> +1 fremy<br> <TabAtkins> fremy: strange to assume that<br> <TabAtkins> emilio: my proposal is minimum that lets you build this<br> <GameMaker_> +1 fremy as well<br> <TabAtkins> emilio: but solving general case firing event listenres in an order that solves every use case, yeah it's a much more complicated problem<br> <TabAtkins> emilio: have to define which events do this, we start with click but have a million events<br> <dbaron> s/registraation/registration/<br> <TabAtkins> fremy: another option is we provide it. for each highlight, define which events you want to recieve, and we have an api that dispatches to them in a pseudo-event manner<br> <TabAtkins> fremy: So does preventDefault for you, etc<br> <TabAtkins> emilio: I'm not even sure there's a canon order you want to define events on<br> <TabAtkins> emilio: spellcheck error with a link inside<br> <TabAtkins> emilio: might seem reasonable to fire spellcheck first and link if not handled, but might be reasonable other way around<br> <TabAtkins> emilio: I think easiest is to make website choose<br> <TabAtkins> qq+<br> <TabAtkins> dandclark: advantage of having platform handle this, where we just propagate the event, is we already had an order of highlights<br> <TabAtkins> q-<br> <TabAtkins> dandclark: so think there is an advantage to use the existing order since things are built in already<br> <TabAtkins> emilio: there is reasons to do before, but also after<br> <TabAtkins> emilio: not clear to me why we should do them before or after in specific<br> <TabAtkins> fremy: i think this makes sense, let authors to do this<br> <TabAtkins> qq+<br> <TabAtkins> emilio: I think having an api that gives you ranges in order would be low level<br> <TabAtkins> emilio: if libraries say we can't use this because there's no good way to coordinate, then we can decide whether to fire events before or after<br> <bkardell_> q+<br> <TabAtkins> emilio: seems like an elegant way to handle the use-cases without making a call<br> <astearns> ack TabAtkins<br> <Zakim> TabAtkins, you wanted to react to astearns<br> <fantasai> TabAtkins: I think one detail of fremy's proposal is being missed, which is getting the list ordered is reasonable and authors handling on his own<br> <fantasai> TabAtkins: the problem is that you have to re-invent event dispatch, and hope other libraries can coordinate with you<br> <fantasai> TabAtkins: Given a list of highlights to displatch on, it fires events using normal event listener mchanics<br> <astearns> (isn’t this the first option?)<br> <fantasai> TabAtkins: handles preventDefault etc, as if part of the normal event dispatch order<br> <fantasai> TabAtkins: so don't have to re-invent<br> <fantasai> TabAtkins: doesn't require cross-library coordination of the events themselves<br> <fantasai> TabAtkins: e.g. fire highlight event, take a list of highlights, cranks through them in order as if part of eveent chain<br> <TabAtkins> emilio: so would be equivalen to making highlight even tlistener<br> <fantasai> emilio: it would be equivlanet to [..]<br> <TabAtkins> emilio: so basically it woud be a matter of writing that loop with the current event and dealing the pD/etc in that order<br> <fantasai> emilio: with api from before, give me a list of highlights, would be a matter of writing that loop with current event and dealing with event propagation and stuff manually<br> <fantasai> emilio: that seems reasoanble<br> <fantasai> emilio: page would be responsible at some point, to propagate [missed]<br> <bkardell_> q-<br> <fantasai> TabAtkins: on the hihglight registry, eyah<br> <fantasai> emilio: seems like eihter extension or replacement<br> <TabAtkins> s/[missed]/the highlight events/<br> <fantasai> emilio: still requires page's coordination<br> <fantasai> astearns: Tab described your first option from the issue?<br> <fantasai> dandclark: sounds similar, except instead of dispatching, need to register to dispatch<br> <fantasai> TabAtkins: Yes, page author still has to handle ordering and do what they need to do<br> <fantasai> TabAtkins: but otherwise platform handles events for you<br> <fantasai> dandclark: so if I have highlights on my page<br> <fantasai> TabAtkins: Ask the highlight registry are at this x,y, then call this with all of those<br> <fantasai> TabAtkins: in priority order<br> <fantasai> TabAtkins: if a highlight preventsDefault, then later things don't get the event<br> <fantasai> TabAtkins: which is what you want<br> <fantasai> TabAtkins: [missed]<br> <fantasai> dandclark: How do we know it's not happening twice?<br> <fantasai> dandclark: if my final page library says, okay, I need to trigger this ? and propagate the highlights<br> <fantasai> dandclark: [too fast]<br> <fantasai> dandclark: I have too different libraries<br> <fantasai> s/too/two/<br> <fantasai> TabAtkins: if you have 2 libraries both installing event handler on the element<br> <fantasai> TabAtkins: if not preventDefault, each one would run thorugh list, and you'd get repetitious behavior<br> <fantasai> florian: This approach both allows but also requires you to coordinate<br> <fantasai> florian: simple scenarios can coordinate by accident, but overall, if doing with multiple independent libraries<br> <fantasai> florian: need some kind of plan for interaction<br> <fantasai> florian: you need to think through it<br> <astearns> ack florian<br> <fantasai> florian: another thing I wanted to ask, unsure if decides,<br> <dandclark> q-<br> <fantasai> florian: all this discussion here, we're going to have a very similar discussion for every other type of pseudo<br> <fantasai> florian: e.g. ellipsis<br> <fantasai> florian: we shouldn't have 3-4 different solutions for each type of pseudo<br> <fantasai> florian: I think this approach works better, you're in charge of coordinating, coordinate to your heart's delight<br> <fantasai> florian: but it is a low-level approach, you *have to* coordinate<br> <fantasai> florian: For those who have thought about this, how do you generalize to other pseudos?<br> <fantasai> TabAtkins: Only concern I have is the actual invocation of your behavior, already have API for that called event listeners<br> <fantasai> TabAtkins: not using that sucks<br> <fantasai> TabAtkins: but if we recommend to authors to call dispatchEvent on your things, that's probably sufficient<br> <fantasai> TabAtkins: we have communication API ... but at least not inventing a new callback system<br> <fantasai> florian: can we do both? By default have a dispatcher that [..]<br> <fantasai> florian: and if you don't like that, do your own?<br> <fantasai> florian: If you don't say anything, we dispatch like this. I fyou don't like it, roll your own<br> <fantasai> fremy: If you want [missed]<br> <fantasai> fremy: we already have mech or that<br> <fantasai> emilio: but initial proposal fires at DOM<br> <fantasai> fremy: if you decide that you want to dispatch something, if it's imporant,, you can say it's ?? phase. We already have mechanism for it, this coordiation happens every day<br> <fantasai> fremy: we have ? phase, capturing, etc.<br> <fantasai> fremy: we already have these<br> <fantasai> fremy: it works<br> <fantasai> emilio: If the page hasn't called dispatchEvent on the registry<br> <fantasai> emilio: if we do ourselves, prevents page from doing it later<br> <fantasai> emilio: so only deault we could choose is after DOM dispatch<br> <fantasai> emilio: but might want to dispatch ???<br> <fantasai> emilio: so I think making highlight inherit from EventTarget makes sense<br> <fantasai> emilio: and propagating to highlight whenever page wants is reasonable<br> <fantasai> emilio: but how would that look like?<br> <fantasai> emilio: undefined ?? x,?<br> <fantasai> emilio: do for mouse events normally?<br> <fantasai> emilio: do the list thing?<br> <fantasai> TabAtkins: do the list thing manually<br> <fantasai> TabAtkins: you can check prevetnDefault by defaultPrevented<br> <fantasai> TabAtkins: we can put example code in the spec<br> <fantasai> emilio: So you don't want an API that does it for you?<br> <fantasai> TabAtkins: probably not<br> <fantasai> dandclark: If we have 2 libraries that are not coordinating, which one writes the for loop?<br> <fantasai> TabAtkins: You should check to see if default has been prevented<br> <fantasai> TabAtkins: if you're first, [...]<br> <fantasai> TabAtkins: or you can just stop propagation immediately<br> <fantasai> TabAtkins: event system can handle that<br> <fantasai> fremy: You may say that you don't want to prevetnt, but still click on the button<br> <fantasai> TabAtkins: Events should check themselves to see if prevented<br> <fantasai> fremy: if you preventDefault, the button won't click<br> <fantasai> emilio: That's the key of the issue, there's no good answer on whatever is the good ansewr<br> <fantasai> emilio: if you have a spelling eerror on a button, you might want a popup to suggest a fix<br> <fantasai> emilio: or you might want to click the button<br> <fantasai> emilio: It's not known which you want<br> <fantasai> fremy: I agree, but if every library makes its own for loop because it's necessary, then ??<br> <fantasai> emilio: we're not suggesting that<br> <fantasai> emilio: The library doesn't need to write the for loop. They add e.g. click event listener on its optject<br> <fantasai> emilio: something on the page writes the for loop once, and dispatches to all highlights<br> <fantasai> emilio: so no library needs to write the for loop<br> <fantasai> emilio: that's done once whenever page wants to handle that<br> <fantasai> fremy: If I use grammarly, grammarly needs to write the for loop or else it doesn't work<br> <fantasai> fremy: so they will write it because they need it<br> <fantasai> emilio: then they would only handle ranges that they register<br> <fantasai> fremy: but it still does not solve issue of order<br> <fantasai> fremy: run the grammarly thing and no consideration that some other things on top of them<br> <fantasai> emilio: if preventDefaulted then ???<br> <fantasai> fremy: Sitll the same issue, it's not preventDefaulted if there's another highlight before it<br> <fantasai> fremy: you have multiple highlights. Grammarly wants to work. So they will need to add an event to handle fix. If they want to make for loop, they can only include grammarly stuff<br> <fantasai> fremy: but they might want to run grammarly code only if no highlight on top of them<br> <fantasai> emilio: if the page has dispatched the same event to the highlight already<br> <fantasai> emilio: like you would dispatch the mouse event from the platform<br> <fantasai> emilio: if another highlight provider did something, registered dom event in capturephase, and have preventDefaulted it, then grammarly can check that and bail out<br> <fantasai> emilio: this event has been handled before, we may not even need our for loop<br> <fantasai> fremy: I don't quite understand, it's not clear what are we doing<br> <fantasai> TabAtkins: There are various ways for event handler to check if I've been called with this before<br> <fantasai> TabAtkins: In most cases not required, all first-party content, and don't care much<br> <fantasai> TabAtkins: should be generally OK, and complex cases need compexity anyway<br> <fantasai> TabAtkins: you can say I only want to be dispatched once, and guarantee that on your own, by checking and immediatley returning if you get called a second time<br> <fantasai> fremy: ...<br> <fantasai> TabAtkins: normal event dispatch would not call the same event on the same element more than once<br> <fantasai> TabAtkins: but we're not using normal event dispatch<br> <fantasai> astearns: any other lingering questions, or take back to the issue to discuss the current state of this fourth way<br> <TabAtkins> (store the last event you saw dispatched to yourself, and check if the new one is the same as the last; if so return immediately)<br> <fantasai> dandclark: I agree with taking back to the issue, I'm also a bit lost<br> <TabAtkins> so you can avoid the "double-dispatch" entirely on your own without any 3rd party coordination<br> <fantasai> astearns: Emilio, can I ask you to write up the proposal with all the details so that Dan has something to digest more easily than the minutes?<br> <fantasai> dandclark: Does this still have the perf issue dbaron raised?<br> <fantasai> dandclark: [missed]<br> <fantasai> emilio: for clicks sure there's no perf issue<br> <fantasai> emilio: for things like pointerdown, if you want notPassive handling of pointerDown, it feels like a global event listener is maybe not ideal<br> <fantasai> emilio: this may be fixable another way<br> <fantasai> emilio: like, maybe we need another member of listenerOptions<br> <fantasai> emilio: I don't have an answer for that right now<br> <fantasai> flackr: Maybe the highlight could have a different touchAction?<br> <fantasai> flackr: normally we encourage ppl to use passive events and use touch Action to specifiy whether to ???<br> <fantasai> flackr: if we had a way to specify the touch Action on the highlights to not depend<br> <fantasai> emilio: yes, you might want to allow touch Action on highlight pseudos, make that behave properly<br> <fantasai> emilio: it's a very good idea<br> <emilio> s/touch Action/touch-action<br> <fantasai> astearns: Anything more on this issue?<br> <fantasai> dandclark: Yes, I think we're good<br> <fantasai> astearns: do we discuss next issue? or wait on the details of this one?<br> <fantasai> dandclark: I think we wait<br> <flackr> s/???/to scroll or not<br> <fantasai> dandclark: next one is about answering question of given dispatch, how to we determine which range was targetted. I suggested adding a new event type<br> <fantasai> astearns: so closing off current issue and going to next issue<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7513#issuecomment-1201588806 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 1 August 2022 18:58:16 UTC