Matthew: I wrote a sort of proposed comment... I think the use case is a good one to be trying to solve.. some issues, particularly this changes long established behaviour. On Monday it sounded like that we (or someone) had asked them to be more specific. and actually now we're asking them to be less specific... A couple of other things - one was a question on the way focus order works... The other is: it adds a value to the CSS interactivity property which we just had a concern about in #1037. But still it's predicated on this thing that we asked people not to ship.

Dan: Dependency?

Matthew: it has a dependency on a value on the CSS interactivity property - in 1037 we asked them to not ship so this has similar issues. Jeffrey has also give some feedback.

Marcos: It seems to replicate popover... I don't agree that shifting this from developers to UAs is something that's going to work well.

Matthew: webkit supported popover=hint but not the specific interest target because it overrides the UI for long press. Also: would we want to chnage prefetch rules?

Martin: in an application if you tap on something that isn't a link then everything's fine... it's just a matter of building app such that there aren't multiple layers of interaction... This is one ... where we (mozilla) are getting pressure from Google. The upshot is still the same. There is no consensus on the feature. It requires uninform acceptance to change the bounderies of standardization. It has long been the case that long-press is UA behaviour, not something in the spec... Unless Safari willingly concedes that it's subject to standardization then I don't see this going anywhere...

Marcos: Martin raises an interesting point around long-press.. Trying to figure out why we haven't standardized the long press...

Martin: well we had context menu for right click...

Dan: in some web applications, context menu is over-ridden.

Martin: e.g. in Google docs...

Dan: just noting that there are examples of a default behaviour and an ability to override the behaviour.

Matthew: I'm sympathetic to this use case ... especially for people who are browsing on mobile this could save users time... E.g. checking the status on a github issue...

Martin: My view is that in this example this is something GitHub could provide you. On sarari a long press already gives you a preview of the page that's at the other end.

Matthew: for me with a vsion impairment that preview isn't of use to me... So I'm sympathetic to the bounderies but also enthusiastic for the use case.

Matthew: the popup is useful because the key info is there .. the preview isn't useful because it's too small to see...

Martin: isn't that an implementation problem? The stylesheet of the

Dan: so it would be an extension of responsibe design...

Marcos: a design choice by GitHub (e.g.) ... other option: if you can identify a window... media query - this happens to be a preview - you could

Dan: so a new media query type --

Martin: of type preview and adapt the content accordingly.

Matthew: one of the pitfalls .. if you didn't have the ability to reliably establish you were in a preview you would load the important info first.. rather than limit it to the contents of what you would put in the popover... So the idea of having a special, reliable and simple way of loading as a preview here... I like it bcause it avoids that problem. I also like it because it could be generalized to other sorts of preview cards...

Dan: where does the info you're interested in come from?

Marcos: could be in the page, could be that you need to load it...

Matthew: presumably ... you get told the page is being loaded in a preview ... could do the same thing on desktop... I'm sure that involves more transfer of data... and on mobile transfering less data would be desirable.

Marcos: you could do a preview source if that was a concern...

Matthew: we could say "interest target and interest target source"...

Marcos: there are other ways of solving this problem... for example considering using a media query, loading an alternative document, etc...

Martin: if your list contains everything you need to display the preview fine, but in some cases it doesn't... if the goal is to use the preview as a stepping stone it makes sense to load and prepare to render the page... so having it be a different type of content... might be a bad thing. The savings is... having a bootstrap but doesn't cost a bunch extra until we load it...

Matthew: this is about avoiding the need to load the other page... I think I will rephrase the draft comment.

Matthew: definitely the use case is a good one... I will have more of a comment by breakout C.

Jeffrey: this is an interesting one. Martin and Tess don't like the way OpenUI are proposing this... The issue is that hover on a touchscreen is really difficult ... originally they proposed that you would express interest in a platform-defined way. They tried to provide that direction... long-press... however long-press already shows a context menu / preview (on some platforms)... and Tess is unhappy with changing that behaviour (in Safari)... We could help ... They landed on normatively requiring long-press... Whereas we could say "it's a way"...

Matthew: it does seem unusual to be that proscriptve about UI in a spec...

Jeffrey: we say some similar things elsewhere... but e.g. VR headsets might need an entirely different UI for "expressing inetrest"

Yoav: one more thing about this general pattern... pattern that devs have already been implementing... some conflict there with intention to prefetch... looking at speculation rules... and this pattern. They are not 100% at odds but some conflict. This pattern encourages people to engage with links without necessarily visiting.

Jeffrey: that's a really good point that we should include.. Maybe interest target should turn off prefetching... or developers could specify how to prefetch the result...

bump to breakout C

• Previous discussions:
  • Want them to find new ways of thinking about this
  • From Slack discussion: Apple not interested in this use case, so suggesting that they find ways to make Apple happy might not make sense
• Continue discussion
  • There are some interesting and important boundaries here. Typically we shy away from specifying UI, have never attached specific things to long press. Doing so now encroaches on what browsers considers UI.
  • Draft comment: consider other ways to solve the problem of improving a review of the target page
  • If we take links out of the equation, it's far less of an issue
    • You could long press on stuff that doesn't encroach on exisiting UI. But there are no user affordances
• Open question: how requested is this feature? Sympathetic to use cases, but also need to let browsers control their own UI
• Original proposal was to leave it up to UAs. The implicit idea was that long press would show a context menu with an item to show the interesttarget. They suggested UI because Apple asked them to suggest UI. Apple didn't ask them to mandate UI, just asked to show what it looks like, so the proponents did more than was asked in mandating it.

Matthew: Discussed this, needed to comment … have concerns about possible alternative ways … put a revised comment in the brainstorming thread … want to make sure that Marcos is happy with it Hadley: Can we put a comment in the brainstorming issue so Marcos has a look? Matthew: Will ask Marcos and Jeffrey for comments. Hadley: Ideally, contact them via Slack

Wait for Martin and Marcos.

we discuss the draft comment that Matthew wrote up

Matthew: the "how" .. an href... and a phref for preview... (e.g.) the SHOULD for authors - or MUST - that it should be upgradable to the full version of the page...

DanA: Noting a meta issue: We've had substantive discussion in the private brainstorming. Should it have happened in the clear, where the implementers can see it? To make us more responsive. The actual issue doesn't have anything yet despite our invisible activity. Want to get the level of public vs private right.

meta point about how much deliberation we're doing in a private thread vs exposing to the requstor

Matthew: we could reply and say "thanks for this and it's nice to see this... " but there is lack of consensus in TAG.

Jeffrey: I do think that the amount of internal lack of consensus means it's appropriate, however there is indication we do have consensus for the current comment from matthew. The signal that you're being previewed could be a useful feature for IOS users... If Apple were willing to send a signal, that would be useful...

Matthew: I can draft such a comment - I will do it in the private thread and ping internall and see where we get.

Matthew: we discussed and there wasn't consensus .. but we wanted to get back to the group. I drafted a comment... We've given some suggestions for avenues... Also asked them to flesh out the use cases... demonstrate the developer needs. Also back them off making specific UI suggestions... Added the prefetch issue that Yoav raised...

Hadley: What do you want to do with this issue, close it? Keep it open to continue the discussion?

Matthew: i think we keep it open for discussion, pending external feedback... also asking them specifically to consider prefetch...

Marcos: I've been giving it more thought. I think we should oppose this as over-engineered. Encroaches on so many things... use case on the model is legit but the approach is way over-complicated. Encroaches on UI and OS conventions ... Don't agree with the suggestions. Requests for data... not appropriate... Maybe drop just that part? There is a sense people want this... Doesn't go back to first principles..

Martin: What this really is is people want to make long presses available to web sites. Not about link previews. I don't think we're going to get consensus here.

Also, we don't need to offer a solution. Sometimes we can't do that. It's opaque. What Matthew suggests works for me.

Xiaocheng: This is related to my project when I was working at Google. Re developer interest: they included a list of issues that openUI does not count.

Marcos: i don't think it's representative. openUI is a community in the US, but I don't think they are sufficiently representative.

DanA: can we agree on a comment to post? We are falling into this antipattern when people say "TAG doesn't respond!"

Marcos: we could say that architecturually this doesn't work because of the related features on the web, mouse clicks etc. I agree we should not provide a solution. We are just evaluating a solution, and that's what we don't have consensus on.

Matthew: to us this is long press on the web, and to them it's pop-ups.

Matthew: I did draft something...

Jeffrey: I think it's ready to send but yes should check with Martin and Marcos.

(Martin) Marcos is good with Matthew's response; let's post that.

Xiaocheng: I'm ok with Matthew's comment... but it's on a technical level that's scoped to this proposal itself... One question I've been asked is "what's the current trend is there anything related to AI agents" - this might be one of those. They define "interest event" - which is not bound to user action.. This is the first event that is not bound to user action, but directly characterized by a user intent. In some dicussions in Huawei, we think a distinguishing point of an AI agent is that it processes "intent" as opposed to actions... This could be a first step. Marcos raised a concern as this doesn't match any user action but I feel this is the ... Do we want more such proposals that try to characterize user intent instead of actions.

Martin: I think I side with Marcos on this one... the way it's manifesting is trying to get access to the long press event ... but some have said it's abstract back to an abstract concept... Xiaocheng is bringing it one abstraction step back.. To e.g. an AI agent "looking at" a particular thing ... taking action. I'm not sure we should be building a web for machines like that. Also I don't want eye tracking on the web.

Hadley: I feel like the eye tracking gives me a headache...

Dan: Black Mirror episode like this. If you're watching something an advertisement comes on and you close your eyes, the ad stops and says "you must open your eyes for this advertisement".

Hadley: sounds like we don't have consensus...

Martin: It's not even clear that this was the intent of the proponents.

Xiaocheng: I explained some of my thoughts... but I can go back to a technical level. 2 things : event and how we trigger it... Can they be orthogonal: define the event, but allow authors to decide how it is triggered. Eyetracking would then be a choice of authors. Then we no longer have the issue about long press or that. Maybe you can ask sites to experiment with different options. Whatever wins wins.

Hadley: Wild thought. Not only would that be very difficult for those with sight issues, but eye tracking would potentially reveal the use of AT. Which we've worked hard to obscure from websites.

Martin: suggest we post Matthew's comment and Xiaocheng post a comment about [what he said above]... We should post [as it's been a long timne]...

Hadley: agree - good to post what has TAG consensus and Xiaocheng can also post comments not flagged as TAG consensus...

agree to post comment and mark as pending external feedback

Jeffrey: Matthew sent a draft; Marcos sent a counter-draft. I think we should send Matthew's.

Marcos: I'm ok sending Matthew's if you think it's better.

Jeffrey: I'll send that comment to Matthew, and he can post his draft.

Xiaocheng: we received a response and I think ... first they provided data about how common the triggering is... data is 94% of top web sites use this form... pretty solid proof of the use cases... And then discussed the clash of triggering and speculation rules... seems like this is a fixable issue. For discussion: we are focusing too much on using triggering for link preview... but could also be used for showing a "tool tip" which is not link preview. Focusing too much about conflict with another feature in link preview scenario might be not focusing on the most important stuff... So my opinion is that we may express a concern about clash but we should not make it a very strong concern...

... other thoughts?

Marcos: concerns around long pres behaviour

Dan: also standardizing the long press function... might be inappropriate.

Marcos: can you cancel a default behaviour? An example might be right click... what happens when you right click is different one ach platform. When you do a long press, is the default behaviour cancellable? Do we believe as the TAG that ... this should be a cancellable action...?

Dan: some web sites do override the right click behaviour...

Marcos: But this wrecks the UX in so many ways... e.g. you have a password field that doesn't allow you to paste... that's why there's resistence on the webkit side... But there is precedent for this ... e.g. clicks, mouse swipes, etc... it's whether it will harm the UX... We've seen in the past that these UXs are harmed... E.g. not being able to click the right click menu...

Dan: feels like the UX should be up to the "marketplace"... Proposing a satisfied with cocnerns with some guidance about how it could be harmful if not implemented correctly...

Marcos: for webkit it doesn't feel like something we would like to change... but that could change... I don't know what the default behaviour in chrome... "would preventing the default do more harm than good?"

Xiaocheng: it shoes a context menu... and highlights the text...

Xiaocheng; I think UX consistency with the platform is important but we should not disallow overriding because developers might want to ensure consistenty within their ecosystem.

Christian: I tend to agree with Marcos that ... bothers me if people block right-clicks or provide their own search interface... But ... I think it would still make sense to do it... they are proposing this to auto-open popups on web sites... on desktop the signal is hovering... What they try to look for is a signal on mobile... it would be broken if that would only work on desktop and not on mobile... it maay make sense to have it. There was force touch ... on IOS side ... it was made available to web sites... was exposed to develoeprs... https://developer.mozilla.org/de/docs/Web/API/Force_Touch_events

Marcos the proposal is so large... if they strip it back to just that event ... but they have over-engineered this so much... The crux of it is... is this really just about long press or not? In the brainstorm ... we asked "can we get this back to the fundamentals" ...

Dan: overriding a long press could be a "primiative"...

Dan: do we need them to do this work in order to...

debate about whether we should ask them to possibly split this proposal to "override long press" and everything else

Xiaocheng: difficult to find a meaningful way to split it... if any part is missing... if only have the interesttaeget attribute without default triggering behaviour... but if we say "we're going to override the default behaviour of longpress" but we don't say what the new behaviour is... similar if we split the popover from this proposal then it's incomplete... splitting it doesn't introduce a complete behaviour...

Marcos: could we have a high bandwidth discussion - get them on a call?

Dan: Next week's plenary? or breakout A...

Xiaocheng: it's about the scope of CSS in general.. should it just control the presentation or should it control user interaction on elements. There is a companion propsal in CSS for the "delay" to trigger that ...

Marcos: it's a good question....

Xiaocheng: this also came up regarding carousels...

Jeffrey: chair hat off ...: marcos, have you read the points about why this isn't long press?

Marcos: maaaaybe

Jeffrey: Looking for the semantic meaning of "hover". Long press showed up because they needed a proposal. They overdid it perhaps. The original proposal was a context menu option that you selected.

Marcos: Interest is a bit more difficult as a thing. On the vision pro, if I look at an item, then it potentially looks like interest, similar to having that behavior, but it's a bit more vague, but it doesn't fit the patterns of other things. That's why I ended up with long press. "Interest" is a bit vague. There is no interest concept that applies everywhere. On a tablet, is a long press really showing interest?

Jeffrey: Samsung tablets with pens have a gesture where you hover the pen over the surface.

Marcos: iPads with pens also have the same sort of hover.

Jeffrey: Only works with pen.

Marcos: Hover is already covered then, with pointing devices. This would conflict with that, given that it is supported in those cases.

Jeffrey: This would also work with keyboard input or eye tracking.

Marcos: If you tab to the thing, you can ...

Jeffrey: That requires separate code, whereas this is unified across input modality.

Marcos: This is the part that isn't clearly right. It overgeneralizes the interaction model. This is a larger discussion, with a11y. If I tab around a page, that doesn't mean I'm interested, unless I do something specific.

Jeffrey: They have done some work on that. We could ask them to validate some of these things with a11y people.

Marcos: Without it being wrapped in the interest part, but is what we have in the platform enough or do we need this extra event?

Jeffrey: You can polyfill, except perhaps for long press.

Marcos: If you can polyfill... I disagree iwth the other arguments in the explainer around complexity of implementation. Sure implementation is hard, but I'd like to see this broken down. Does hover fail? Even if you need two events for the same thing.

Jeffrey: OpenUI is working on the higher-level stuff, but they are working to put the common patterns into the platform, so that you don't need to reimplement controls themselves (and get a11y wrong).

Xiaocheng: Should we suggest first step. Can we split how to trigger the state from the specific user actions. So rather than defining the default behavior on every platform - hard work - keyboard, touch screen, pens, VR, ... It is infeasible for them to make a complete proposal. How about we define the interest event and default actions for that event. The triggering is decided by the browsers.

Marcos: I would sstrongly disagree with that. We might get there, but the thing that this improves is in identifying the problem. e.g., Popover gives you the right context while you jump around and manages keyboard focus. That's a clear solution to a real problem. Prove that it is too hard to do something in particular, if we can't fix those, then we should end up with a solution. They haven't made a case for why this is broken. It's hard to implement, sure, but why is it broken? From that agreement, we could potentially end up at interest. We will get a bunch of new problems if we do this without understanding what this is fixing. New things have significant costs, people will get excited, and we might realize that it creates new problems or doesn't address the problems we have. Not convinced that we need it. Sufficient primitives that we have had for some time. Was of the view that this is already something we have.

Jeffrey: Point is that you can polyfill, but developers don't. Are you looking for sites getting it wrong?

Marcos: Just want clear examples of where the current system falls apart and why. if this is polyfillable, why are developers fouling things up? If we did that, this is super over-engineered, is that too much?

Jeffrey: It links elements. Not sure if it does too much.

Marcos: I got the impression this was more complicated. Let's get together with them, so that they can convince us of the problem.

Martin: Challenges Marcos on the point of explainer vs. high bandwidth discussions.

...

Xiaocheng: Can we split the proposal by platform or input device? Can we make progress on hoverable interactions? According to their study, triggering interest is very common across the web. This might be low risk.

Jeffrey: Doing mouse-like triggering?

X: Y

Jeffrey: They would like to do keyboard, because it covers a lot of users and is easy.

Martin/Marcos: is it really?

Jeffrey: Tab to focus, keypress to show interest. https://open-ui.org/components/interest-invokers.explainer/#keyboard

Marcos: not sure how this addresses the a11y use case. You tab around and then the thing that pops up is inaccessible. Would be interested in using an iPad with hover.

Martin: What about loss of hover? When the pen leaves proximity to move it.

Jeffrey: Maybe you don't lose hover if you don't hover something else. By having this semantic thing, you can adjust for these differences. And you might also get it to work on alternative interaction modes where things are different. ...: Time to consider asking the proponents to come in and have a conversation. They are west coast. Might want this group involved, plus Matthew.

Jeffrey: I'll find a plenary time to invite everyone.

Matt: There's a lot of internal discussion. I like Xiaocheng's idea but there's still not consensus in TAG on what to do, Jeffery has shared Moz standards position. The proponent has been invited to July 31st Plenary. Nothing to do for now except catch up on brainstorming thread on the issue.

Matthew: We're seeing the proponents of this issue next week, we've invited them to the plenary call.

… Long discussion in the private brainstorming, we're uncertain about what the attribute tries to solve

… We struggle to agree on the questions we want to ask

… Maybe we should discuss this asynchronously with Martin and Marcos before we talk about it here

… There's much disagreement in the TAG about what the underlying problem is, and how to solve it.

Guests: Mason Freed, Chris Harrelson, Una Kravets, Penelope McLachlan

Mason: I will set the stage for some of the things that have been talked about. Mostly discussed has been touch screen. But most users will be mouse users. Many production websites use hovered content.

This is an accessibility API. Can do hover-triggered UI with JS today, but this leaves out keyboard users.

It's also true for hover triggering, keyboard, touchscreen, you can build today in JS. This was also true in popover. But had a11y issues, stacking issues...fixed with standardization.

This is similar. Try it on Wikipedia -- they spent lots of time on their hovercards. Try it with a keyboard, it's not great. E.g. can't close with Esc, can't turn off the gear icon to control them with keyboard.

Their native app with touchscreen has long-touch mostly implemented as preview, but sometimes uses the OS behavior. That's the background.

There are more use-cases.

API is pretty simple. Hoping we can find a way to move past the debate.

Marcos: Is there much to discuss? It's implemented in Webkit and what other engine?

Mason: ONly in Blink.

Marcos: I saw WebKit patches?

Mason: Maybe it was Luke? That would be great news though.

Marcos: Event and attr was landed. Maybe I'm wrong though? But saw patches landed. Looking...

Mason: Luke Warlow?

Jeffrey: Not asking if has been adopted by engines.

Marcos: What I'm getting at is it has a lot of eyes on it.

Mason: It's not shipped anywhere.

Marcos: It's had more eyes than the TAG's on it. I had questions around the event, similar qualities to longpress...is the event cancelable?

Mason: Yes. Two events, interest and loseinterest, both are cancelable.

Marcos: Doesn't interfere with longpress?

Mason: If you're using touch screen, you show interest by longpressing and choosing option from context menu. Or with button, no context menu. With link you get the contextmenu first, we'd add another "Show details" item to the context menu, which triggers interest.

Marcos: Links are contentious, you'd expect behavior is preview.

Mason: That'll still happen. This is iOS, with Safari, longpress a link, get 2 things: preview up top, context menu at bottom. Only change would be the menu has one more item, "show details".

Xiaocheng: If you longpress button, triggers text selection, trigger again, contextmenu.

Mason: In Chromium, solved by setting user-select:none on buttons with interestfor. It's a weird behavior anyway.

Jeffrey: I'm hearing mostly support. Is that right?

Lola: I'd like to hear from Matt and Mason about a11y considerations. If issues come up with ARIA semantics, does this integrate well with AT use?

Mason: I have open a11y review to make sure of what I'm going to say. I believe most of the a11y connections come from the popover. When you set up button and popover today, the right a11y semantics get set up by the platform. We'd reuse the same ideas. If there are other things we'd like to know.

Matthew: For the reasons Mason mentioned at start, seems we're moving common pattern to a more standard place. It's simpler than popover. From a11y perspective we're crossing t's dotting i's. Overall use case is positive one to move into platform natively.

My recollection of TAG's discussions is there's been broad support. Areas of concern were about how it affects current UA behavior. You've talked about that already.

Github example is good. We were looking for more examples. Maybe fleshing out those more to further justify is good idea. But in terms of a11y this seems a win.

Mason: Section at top of explainer covers 10-14 production sites.

Matthew: Haven't looked in a while.

Marcos: Other main concern was whether it interferes with common UI patterns on mobile, like if it prevented preview. Looking at other things concsidered cancelable, like right click or paste, frustrating to users. Should be mindful of that when can cancel an event. Looks like this doesn't interfere.

Mason: That's crux of the touchscreen example. So often broken; sites are face with the choice of either giving access to context menu or the hovercard. This lets them have both.

Marcos: I get positive aspect, but always unintended side-effects. Trying to look ahead to those. What might be negatives?

Mason: Assume you're talking mostly about touch screen.

Marcos: In general.

Mason: I think we've mitigated them. Most tricky is touch screen. Were proposing for a while showing both popover and context menu, and some other ideas...the one we landed on of adding context menu item feels lowest risk. I'll mention keyboard too, had more complicated set of behaviors, stripped that out too. Feels like where we landed is lowest risk.

Marcos: I think one of the original proposals had HTML loading stuff, that's all gone?

Jeffrey: Preloading?

Mason: Was question about speculationrules, whether it interacts with that. If you're hovering link, should affect how you prefetch? General feedback was it's unclear. Maybe they're less likely to click if you show them all the info. So better for dev to control.

Lola: I'm making assumption here. This doesn't increase fingerprinting surface. Not making changes to links on pages that reveal anything about user. It's codifying a way for devs to do context previews. No overreaching to make changes to actual page content or following users through journey.

Mason: That's correct assumption. Don't change anything about how links work. Interesting bit is revealing their input modality, but that's probably available anyway. Doesn't show whether they use keyboard or not.

Matthew: That's the go-to could be the bad thing. Reassuring. THe fact the event fires is fingerprinting risk. But you're not saying how it was triggered, that's reasonable. Seems like fingerprinting risk is small and being managed. Classic example: make it so it's not possible to detect AT, but really have ways to check. Don't think you'll fall into that pitfall because not saying how interest expressed.

Other negative things, trying to think of some. Dev could implement in a way that causes user surprise, too many dialogs. But can do that now. "Worst" is b/c of difference between buttons and links, will be difference in how come to the info in links vs buttons. If only affects touch interfaces, maybe OK. Inconsistency probably unavoidable. Interesting general design challenge around discoverability. Not proposing we somehow highlight all interestable things. Only thing I can thnk of is surprising user too much, and inconsistency between buttons and links, but not much can be done about that.

Mason: Broadly agree. One upside with shipping is if websites use it, by browser having control, we can add a setting to never show interest.

Xiaocheng: re fingerprinting, this reduces fingerprinting surface. Reveals user intent without revealing actions. For websites to implement same behavior, only listen to this event instead of caring about mouse vs keyboard focus.

Jeffrey: Don't think we can say it is reducing because the other stuff is still there. Maybe reduces what's used in practice.

Marcos: Say you're moving around with AT or touch screen. Do roles/landmarks change? How identified by AT?

Matthew: AT can give hints about stuff. E.g. if you're on something with click handler can say clickable. The fact these attrs exist, certain semantics and roles will be applied that AT can pick up on. E.g. already can identify buttons with popups. AT user might get more info that someone with no AT.

Mason: That's correct. Way it's done is with aria-details, and with an expanded state.

Jeffrey: Other thoughts?

Xiaocheng: I replied in thread with thoughts about generalizing this pattern. Diverse opinions. Do you want to generalize this pattern?

Mason: I like this idea in spirit. Complicated today because need to consider all the ways to express interest. There are probably other such patterns to make easier. Don't want to include all that in this, but I like the idea. Click is kind of like that today, really means activation. Another effort could keep going with that.

Marcos: I saw the PR landed in HTML.

Mason: Up for review, not landed. https://github.com/whatwg/html/pull/11006

<confirms still open> Command and commandfor are landing.

Marcos: That answers my question.

Jeffrey: Are we satisfied?

Marcos: Mainly wanted to give foresight of potential badness. Be mindful of that. Not to be negative about it. All tech gets misued in some way. Could say that.

Matthew: +1 to Marcos. One thing we could do is ask about details of what device can be given to devs to use responsibly. Most of the time with new CSS or HTML stuff, valuable to include rough outline of what to say to authors. Lots covered in WCAG already. But if they're going to docs of new feature, helpful to have awareness of new stuff there.

Marcos: Someone like Mason is more likely to catch issues here -- looking at Digital credentials, people think defensively. It's great to paint in positive light, but with all cool tech, things go bad.

Mason: I agree, open to other things. Have been working on this for >=1 year, found a lot of those bad things that we took out already.

Matthew: You had alternatives considered in explainer -- it's really useful for people to know tradeoffs that have been made. Not asking for too much detail because you already have, could talk more about fingerprinting, what could go wrong...heplful for reviewers and for future reference.

Dan: There was some recent discussion on the design review from Lea about whether this should be combined with commandfor.

Matthew: Good question, but I think that was addressed in the explainer.

Mason: It's how we started the API too. But as you pull the thread, find it's not the best idea. We had lots of discussion in OpenUI. I have strong opinion that it'd be the wrong thing to do, full of footguns.

Jeffrey: Does proposed closing comment look good?

<general approval from the room>

Marcos: Don't just throw it on us to find problems -- but comment looks good.

Proposed closing comment:

Thank you for coming to us with this review. We think this is a good feature, and we're looking forward to its addition to the web. We looked, and we think you've looked for ways that this might come back to bite us in the future, and we didn't find any (though we leave it to the WHATWG community to consider). It would be ideal to include that fact in the explainer. We also note that the explainer doesn't have an explicit alternatives considered section, even though you did explore many other options. But overall, we're satisfied with this API.