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.