[interest invokers] Touch inputs

[lukewarlow]

We've discussed this before but I don't think there's a dedicated issue to talk about what could constitute interest on a touch device (e.g. phone, tablet, certain laptops).

We should also discuss what potential issues there are with this and potential work arounds.

[lukewarlow]

So far I think we've been talking about a long press as a touch input interest mechanism.

Pros:

• This isn't a complete new behaviour, touch devices already use long press for some secondary actions (e.g. text selection, copy, paste, and showing tooltips in the case of Android)

Potential issues to overcome:

• Potentially overloaded because it's already used for other things
• Might interfere with text selection
• Might not be possible to trigger for users with certain conditions
• Might need to handle focus differently on touch so it doesn't count as a trigger
• Hard to polyfil due to lack of "long press" event.

[lukewarlow]

Potentially overloaded because it's already used for other things

Might interfere with text selection

Potential solutions are to encourage Devs to add user-select: none to interesttarget buttons (perhaps apply automatically but less keen on this)

For elements that already trigger a context menu on long press we can add this trigger action to that context menu just like copy link is already an option.

Might not be possible to trigger for users with certain conditions

Hopefully those users will be able to use TalkBack and that will be able to trigger this. Needs confirming.

Might need to handle focus differently on touch so it doesn't count as a trigger

Unfortunate but not impossible.

Hard to polyfil due to lack of "long press" event.

This will just have to be accepted, but perhaps we should add this to the platform too.

[mfreed7]

It might be controversial to say this, but I think it might be necessary to leave some parts of the concept of "interest" to user agents to define. For example, in a Vision Pro like platform, with eye-tracking and a distinctly non-keyboard, non-mouse user interface, it likely needs to be up to the platform to decide when a user is "interested" in an element. I don't think we should (or need to) write down exactly how this works. In contrast, keyboard users and mouse users have fairly standard ways to indicate "interest", namely focusing or hovering the element. These, I feel, should be standardized so they behave in the same way across browsers and platforms. Somewhere in the middle is touch. Perhaps touch is standardized enough that we can specify it, but perhaps not? What's important, to me at least, is that the standard says, normatively, that the user must have a way to "indicate interest" in an element, no matter their input modality.

Stepping back off the soap-box, per your questions about touch:

Potentially overloaded because it's already used for other things

In chromium at least, I could see just adding an item to the existing context menu.

Might interfere with text selection

I agree this might be an issue, but I would see it as an implementation issue maybe? It must be possible for the user to do both, somehow.

Might not be possible to trigger for users with certain conditions

I might need more context on this one. But again, the UA should provide an accessible way to indicate interest.

Might need to handle focus differently on touch so it doesn't count as a trigger

Agree completely.

Hard to polyfill due to lack of "long press" event.

Agree. But it's not a requirement that new features be polyfillable. Definitely nice to have though.

[css-meeting-bot]

The Open UI Community Group just discussed [interest invokers] Touch inputs.

The full IRC log of that discussion

<jarhar> Luke: we've discussed before the idea of interest invokers is that theyre somewhat agnostic to the input method. if its mouse you have hover, keyboard is focus, eye tracking you get whatever
<jarhar> Luke: one of the input modalities is touch screens, we've discussed various ideas how that should work
<jarhar> Luke: this is really to get the ball rolling on approaches to it, what we envisage seeing
<jarhar> Luke: is this even something that we want to do? it might be that on touch screens that its up to the ua to decide how it works
<jarhar> Luke: the two proposed resolutions i want are - do we think that intreest invokers should always be able to be used?
<jarhar> Luke: if youre on a touch screen, does the ua have to provide some mechanism? we could say its optional, and up to the ua
<jarhar> Luke: for hover invokers we could require it
<gregwhitworth> q+
<jarhar> Luke: or, as mason pointed out, the ua must provide this in some mechanism depending on the input
<jarhar> Luke: or we could spec some kind of how this should actually work
<jarhar> Luke: personally i would like to require it for mouse keyboard and touch
<jarhar> Luke: i think touch might be difficult to spec because it depends on platform specifics
<jarhar> Luke: long press is a thing on android to show tooltips, if you have an icon button. i dont know if this is a generic thing, but you long press and get a description
<jarhar> Luke: pro of that is that it at least matches one platform, but there are issues to overcome, it coudl be overloaded or mess with text selection
<jarhar> Luke: buttons in some uas dont even have text selection enabled, links you can text select from a link very well because it loads the context menu
<jarhar> Luke: some users might not be able to do long press so we need to figure out at story as well
<jarhar> Luke: we could hook it into talkback somehow
<jarhar> Luke: or if its a thing in ats
<jarhar> Luke: we would have to handle focus differently, on mobile the prototype is a bit weird
<jarhar> Luke: and the other bit thats not too big a deal is that its hard to polyfill because theres no longpress event
<jarhar> Luke: you would have to impelentnt that yourself
<jarhar> q?
<keithamus> q+
<jarhar> gregwhitworth: i missed the last discussion. the interest invokers statement, what is the actual job to be done? i conceptually understand it with the long press
<jarhar> gregwhitworth: im making an assumption that its going to occur. i guess that is an interest in the popup
<jarhar> gregwhitworth: are you able to give me a one sentence heres the job its trying to fulfill
<jarhar> gregwhitworth: how long its held down to invoke a popover
<jarhar> keithamus: i think there are two strong use cases for the application of interest invokers
<jarhar> keithamus: one is tooltips, and another is page previews, like wikipedia or github
<jarhar> keithamus: on any input devices, the idea is that it should be an at a glance discovery of the element youre showing interest on
<jarhar> keithamus: users avatar on twitter or facebook or whatever,
<jarhar> gregwhitworth: that gives me the use case
<jarhar> gregwhitworth: i guess my - i agree that if you go down this road it should be a must. you've called out the problem that the devils in the details, how do we get everyone to agree
<jarhar> gregwhitworth: im curious if we're not able to - pointerevents is very generic, is doesn't define behaviors on certain elements
<jarhar> gregwhitworth: if that was the resolution i would +1 it, but the devils in the details
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack keithamus
<jarhar> keithamus: my general feelings on this is that its potentially hard or impossible to spec
<jarhar> keithamus: i do think its easier with mouse and keyboard
<jarhar> keithamus: then it gets very difficult when we talk about touch screens because there are many applications and they treat ui differently
<sanketj_> q+
<jarhar> keithamus: keyboard and mouse are standardized, mice have 2 buttons
<jarhar> keithamus: keyboard universally have a tab key
<jarhar> keithamus: as luke points out, long press on android is different from ios
<gregwhitworth> q+
<jarhar> keithamus: i cant imagine us being able to spec or suggest something that would fucntion idiomatically that apple would be satisfied with
<jarhar> keithamus: i dont know how much leverage we would have to add some verbage in the spec that says you gotta do this
<jarhar> keithamus: yeah sure they gotta do everything
<jarhar> keithamus: tail call recursions in the ecmascript spec but 2/3 browsers dont do it
<jarhar> keithamus: we can say it, but the rubber has to meet the road somewhere
<jarhar> keithamus: not that we shouldn't do it, but whats the tractable part of this
<gregwhitworth> ack sanketj_
<jarhar> sanketj_: i want to +1 what others have said. theres a lot of behaviors that are different on different platforms when it comes to touch. i dont think the ecosystem is going to get to a point where theyre consistent
<jarhar> sanketj_: ipads have this feature called tap to hover, when you tap on something you get a hover preview
<jarhar> sanketj_: bringint that to other touch devices has been problematic
<keithamus> q+
<jarhar> sanketj_: i dont think theres going to be a standardized way to say that this kind of touch input should do this everywhere
<jarhar> sanketj_: maybe theres no other way than to say its up to the ua, or we dont say anything, which feels worse
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack keithamus
<jarhar> keithamus: theres other things to think about to spark some imagination, tvs have a very different mechanism for focus and stuff
<jarhar> keithamus: usually you have a dpad, and i dont think we want to have focus follow interest in that example because the only way to navigate is with focus, and it exposes more than a tv user would want
<jarhar> keithamus: and of course eye tracking - you cant have interest land on wherever the user is looking at
<jarhar> keithamus: so theres a whole world of considerations there. is it a delay, a visual indicator that youre about to expose that your einterested in this element
<jarhar> keithamus: theyre in the camp of this - its like mason, its an unsolved problem. if it was solved then it would be consistent, but we dont even have consistency within one as sanket points out
<jarhar> Luke: question 1: do we want to want to require touch devices to have some mechanism to show interest?
<jarhar> Luke: while that may seem slihgtly unimportant, the key thing is that im building an interface and im using interesst target, can i use it knowing that it wont show on all platforms?
<zcorpan> q+
<keithamus> q+
<jarhar> Luke: could it be on mobile devices like wikipedias preview it doesn't show and thats ok?
<jarhar> Luke: or do we want a mechanism on those platforms
<jarhar> Luke: it could be like mason points out that we dont require it for keyboard or mouse, up to the ua to decide what they want to do
<jarhar> Luke: they should say that you should provide interst nomatter the modality
<bkardell_> "you should no matter the modality" makes sense
<jarhar> Luke: i dont want to end up in a situation where its only implemented for mouse and keybard
<jarhar> Luke: i want to see long pressing on a button do something
<jarhar> Luke: but at the same time i dont want to put too much emphasis on uas to do stuff and delay the whole thing
<gregwhitworth> ack zcorpan
<jarhar> zcorpan: one possible user interface for touch devices would be to render another button next to the thing and you would touch that to get the popover
<jarhar> zcorpan: maybe that could be an opt in
<jarhar> zcorpan: if the author feels that its important and needs to be availble everywhere
<scotto8> q+
<jarhar> zcorpan: please make it available and show another button
<jarhar> zcorpan: with mouse and keyboard, its more discoverable because you hover or focus before click/enter
<jarhar> zcorpan: with touch you just touch and theres no opportunity for discovering
<jarhar> zcorpan: but if you have a questionmark button next to it then you have something to tap
<gregwhitworth> ack keithamus
<jarhar> keithamus: i think that sounds good, i would want that to be a pseudo element so its configurable for design system
<jarhar> keithamus: i wonder if we could map it to existing heuristics
<jarhar> keithamus: whenever focus visible is applied, then it should or must show an invoker. maybe that covers some use cases?
<gregwhitworth> ack scotto
<jarhar> scotto8: i was going to +1 simons idea
<gregwhitworth> s/scotto8/scotto
<jarhar> scotto8: dont make it an opt in, because if someone sees a bunch of these buttons show up everywhere maybe they'll rethink their life choices, and then they design it in a way where they dont have all these things showing up on touch
<jarhar> scotto8: i think it makes sense to have that be the way that it does represent itself
<jarhar> scotto8: if someones not happy with how that renders, then they can change their ui and make it something more consistent across devices
<jarhar> Luke: alternative to that is we dont do it auitomatically at all and they can implement it themselves
<jarhar> Luke: we have css media queries for input modalities, so you could hide your interest invoker and use a real invoker instead - or prevent it from doing what you want
<jarhar> Luke: good ideas
<jarhar> scotto8: to coutner that, if there was also a pseudo element then someone could use css media queries and then add their own and then best of both worlds
<jarhar> scotto8: i just worry about not doing it by default, gives people false belief that thjey dont have to do anything
<jarhar> scotto8: when working with developers, html allows you to do this, that doesnt mean you should
<jarhar> gregwhitworth: we are at time, we will have to pick this up again
<gregwhitworth> Zakim, end meeting

[flackr]

Hard to polyfill due to lack of "long press" event.

Agree. But it's not a requirement that new features be polyfillable. Definitely nice to have though.

On Chrome / Firefox, contextmenu is a long press event. You can check that the event's pointerType is touch to filter out right clicks.

[flackr]

Might interfere with text selection

I agree this might be an issue, but I would see it as an implementation issue maybe? It must be possible for the user to do both, somehow.

And drag and drop, and contextmenu of course. You can have all of these things defined and they already get in the way of each other, this is one more thing but seems fine.

Some platforms have a shorter timeout plus haptic feedback for one action and a longer long press timeout for a different action. E.g. The homescreen on iOS picks up the icon for dragging before showing the menu. This is something we could explore to disambiguate.

[css-meeting-bot]

The Open UI Community Group just discussed [interest invokers] Touch inputs, and agreed to the following:

• RESOLVED: the spec should say that any user "must" be able to show interest via some input modality.

The full IRC log of that discussion

<hdv> Luke: we didn't get to a resolution on this last time
<masonf> q+
<flackr> q+
<hdv> Luke: will we require invokers to always be invokable, try our best to make it work for all modalities, or do we accept it's not necessarily possible in all modalities?
<hdv> Luke: at least on Android there's buttons you can long press to show tooltips, not sure if there's similar mechanisms on other platforms like iOS
<hdv> Luke: one issue around this is that interest should naturally be before invoking… if you have the long press, that's naturally more of an invokation than showing interestg
<hdv> s/interestg/interest
<keithamus> q+
<hdv> Luke: there's also the issue that longpress on some elements already does stuff, eg on links. So can we spec this, would UAs actually be able to implement that?
<hdv> Luke: or would people get a separate toggle?
<hdv> Luke: personally feel we'd rather have something buitl in if anything
<hdv> ack mason
<hdv> masonf: my opinion is that for keyboard and for mouse, the standard should dictate how it works
<hdv> masonf: the spec should also say for other input modalities, like touch and others, there should 'be a way' to show interest
<hdv> masonf: that way being up to the UA, because of the many differences between platforms today
<hdv> masonf: what's most important is that all users can do the thing
<hdv> masonf: and probably should be specced that interest is before invoke
<masonf> ack flackr
<keithamus> q-
<hdv> flackr: I agree, we should have a way to access these with touch. these features should work with the standard modality of the device, on some devices maybe you have something like gaze… but on some devices you might only have touch and that should be supported
<hdv> flackr: there are lots of ways people have talked about this… there are a lot of overloaded actions
<hdv> flackr: there's menu actions, drag and drop… many ways this has been done in native UIs
<hdv> flackr: could see this working if interest is nondestructive, you could probably do thisif the finger lingered long enough without scroll
<masonf> q?
<hdv> flackr: there are a lot of details around how this interacts with other featueres
<hdv> s/featueres/features
<hdv> flackr: another issue is disembiguating between different actions, eg you could have drag and drop and context menu at the same time that doesn't conflict
<hdv> Luke: as in HTML drag and drop? does that support touch devices?
<hdv> flackr: yes on iOS, there's work underway for Android too
<hdv> masonf: how standardised is this?
<hdv> flackr: that's literally the homescreen behaviour on iOS and Android… but on the web it's not standardised
<hdv> masonf: my fear is how it is supported
<hdv> flackr: even if we don't spec it you would still get a contextmenu on longpress
<hdv> flackr: iOS supports this and I think Android does in some contexts
<hdv> masonf: I don't know if there is a standard for contextmenu, I think there isn't detail in the spec on long press vs hard press
<masonf> q?
<hdv> flackr: for 3d press could look at maximum pressure or something like that
<hdv> Luke: we could resolve that we should make it a MUST, for any given device/set of modalities, at least one of them should be available to show interest?
<masonf> Proposed resolution: the spec should say that UAs "must" support showing interest via any input modality.
<hdv> Luke: any input modality seems ambiguous
<hdv> dbaron: kind of like 'any user must be able to'?
<masonf> Proposed resolution: the spec should say that any user "must" be able to show interest via some input modality.
<Luke> +1
<keithamus> +1
<hdv> +1
<flackr> +1
<masonf> RESOLVED: the spec should say that any user "must" be able to show interest via some input modality.
<dbaron> +1
<brecht_dr> +1

[mfreed7]

Here's a new idea for touch, from an internal discussion (credit to @b1tr0t):

On touch platforms (or potentially any platform where the UA determines that there's no mouse/keyboard?) the UA adds a pseudo-element button (such as ℹ️) next to the interesttarget source element. That button can then be invoked in the normal way to indicate interest in the source element. And the pseudo element should be available for custom styling via CSS. Perhaps the button can be a popover=manual anchor-positioned to the source element? Just to avoid layout shift on touch platforms.

This idea gets around the problems of using long-touch, and is actually a cow-path paved by several design systems.

Agenda+ to discuss.

[b1tr0t]

Adding in here that this is a pattern that is a fairly common pattern, for example commerce checkout flows. Smashing Mag did a writeup a few years ago that covers tooltip patterns, including this one.

https://www.smashingmagazine.com/2021/02/designing-tooltips-mobile-user-interfaces/

[css-meeting-bot]

The Open UI Community Group just discussed [interest invokers] Touch inputs.

The full IRC log of that discussion

<hdv> masonf: this is about interesttarget and interest invokers
<hdv> masonf: webkit folks are against this feature because it is not well defined on toch
<hdv> s/toch/touch
<hdv> masonf: there are solutions for touch and keyboard
<gregwhitworth> q+
<hdv> masonf: we actually resolved the spec for interesttarget would say it should cover touch but doesn't say how
<hdv> masonf: it's kind of nebulous which understandably the webkit folks don't particularly like
<hdv> masonf: so we're looking for something that works across the board. Touch is very overloaded. When you try to set target on something that is not a button, eg to provide a definition for the text in a <span> … there is a couple of things that could happen on touch, you could long touch to copy paste, also to show a context menu…
<hdv> masonf: now if we add interesttargets and devs start using them everywhere, then copy pasting and context menus are harder to use
<hdv> masonf: idea: on some platforms, an extra button shows up when there is an interest target, then when you click on that button that indicates you have interest in that target
<hdv> masonf: this would be a lot more discoverable and a lot more out of the way… and it could have a pseudo element that is fully stylable
<hdv> masonf: could also be a popover=manual that is anchor positioned
<una> q?
<una> q=
<una> q+
<hdv> masonf: curious what use cases would be broken by that
<gregwhitworth> ack una
<sanketj_> q+
<hdv> una: very interesting approach that I really like…  but it seems like this means there would be different use cases in mobile vs desktop, which authors would need to separately author
<hdv> una: could use a pointer media query that checks for touch input
<hdv> una: you wouldnt want that on desktop if you had a pointer device, you wouldn't want that on mobile (using mobile as shorthand for no pointer)
<scott> q+
<hdv> masonf: yes idea would be this button only shows up when you have a coarse pointer
<hdv> una: really like the idea of handling this with some kind of click handler on certain pointer devices
<hdv> una: a developer should have the ownership on when and how it appears
<hdv> una: eg the github preview repo might look differrent than a preview card on social media… should prob be up to the author
<hdv> masonf: agree it should be author styleable but with default that it shows up
<hdv> masonf: does it sound reasonable to make it show up by default?
<hdv> una: worry that developers might get things they are not expecting
<hdv> masonf: if we make it a popover that is anchor positioned, that probably doesn't have weird side effects as it doesn't affect flow layout and positioning
<hdv> una: still think it obscuring content would be a problem
<hdv> una: can see it get really messy really quickly
<hdv> gregwhitworth: is there historical precedence we can lean on with touch events moving to pointer events…  as we don't know every form factor now and in the future
<una> ^especially if there is a dense layout with interest invokers
<una> ^people use the interest modality to help with data visualization on dense layouts
<hdv> gregwhitworth: what we put forward solves the problem, but worry that setting vision aside would cause problems along the way
<hdv> gregwhitworth: if we start defining what happens on hover by user agents I think we'll get pushback
<hdv> gregwhitworth: I agree with una, we could end with issues
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack sanketj_
<hdv> gregwhitworth: you could probably not either/or any of this, eg lots of users would use touch and then also mouse, I used to on Surface
<hdv> sanketj_: yes there are devices that have keyboard, mouse and touch, not just Microsoft's… so the risk of getting heuristics wrong is real
<hdv> sanketj_: I know Chrome, on desktop touch, has a menu that shows up on touch, that has compat concerns
<hdv> sanketj_: I too worry side effects could happen, not sure if there is a good interoperable option we could decide on
<gregwhitworth> +1 to what Sanket just said
<hdv> sanketj_: can we define, if interesttarget is set and long touch is done, can we define that other actions like context menu and copy/paste just aren't available
<gregwhitworth> q?
<hdv> masonf: I think users would find that annoying
<hdv> q+
<hdv> masonf: on my iOS device, if I long press a link I want to copy/paste it, instead I get a giant preview… I don't like that… and also developers, you're removing a previous capability they had
<hdv> sanketj_: I see… probably not as much as issue for a button, but would be for additional things
<hdv> masonf: agree, button is prob not a problem here
<masonf> q?
<gregwhitworth> ack scott
<hdv> scott: I like the idea, it's interesting
<hdv> q-
<una> q+
<hdv> scott: would be curious to see what other browsers come up with… would be interesting to allow developers to style it, but not sure if developers should be able to decide whether to show/hide it
<hdv> scott: because it's ultimately about the user, they are first in everything we do
<brecht_dr> q+
<hdv> scott: could imagine a bare bones user agent representation of it while we ensure users can get to the content
<gregwhitworth> ack hdv
<gregwhitworth> ack una
<hdv> una: want to respectfully disagree with an example… am looking at an example right now that I think would be a worse user experience if automate
<hdv> s/automate/automated
<hdv> una: [shows GitHub home page, hovering over links where each individual link to a name of a repo as well as an image, each of these shows a popover on hover]
<hdv> una: if we add an extra button to show these on mobile, there would be a lot of buttons
<Penny> q+
<hdv> una: I think we'd degrade the user experience if we cluttered up the UI with lots of buttons, especially in this example where all these are links
<hdv> scott: actually I agree authors should be able to turn this off but users should be able to override
<hdv> una: do you envision the user control to be display settings for the user where they could force interest els to show?
<hdv> scott: yes
<gregwhitworth> ack brecht_dr
<hdv> una: I think that'd be a good way to do it, gives the user control and allows them to see if it makes things better
<hdv> brecht_dr: +1 to not wanting too much clutter
<hdv> brecht_dr: as a user I don't want to think about the difference between desktop and mobile…
<gregwhitworth> ack Penny
<sanketj_> q+
<hdv> Penny: I think it'd be good if there is a global and a per case setting, and a user pref that overrides everything
<masonf> q+
<hdv> Penny: maybe with the right combination of settings we can overcome the challenges
<gregwhitworth> ack sanketj_
<sanketj_> I'll type in my question.
<gregwhitworth> q+
<hdv> gregwhitworth: is there a preference for something that we are going to standardise as a user preference?
<gregwhitworth> ack gregwhitworth
<hdv> gregwhitworth: users and developers would have to be able to rely on the setting existing
<hdv> masonf: I don't think we've ever standarised on a setting like that
<hdv> s/we've/we can or have
<hdv> s/standarised/standardised
<bkardell_> q+ to say I suggested this for tabs
<hdv> gregwhitworth: looks like no webkit folks here… if I put their hat on… they'd probably expect this to be on by default?
<sanketj_> The unavailability of hover on touch is a general problem. Should we think about having recommending/mandating UAs to provide a option (ex. contextmenu option) to view the invoker target on long press?
<hdv> masonf: that is kind of the backup plan I think
<hdv> masonf: I did here some pushback on that too
<hdv> masonf: feedback I heard was it would be a lot of clicks to show interest
<gregwhitworth> ack masonf
<hdv> masonf: thanks all for the feedback today… some of this changed my opinion on things. Global on/off seems to be the right thing, not per platform
<hdv> masonf: little icon should be on or off across the board and developer can change this
<hdv> masonf: we can show a little i-icon when folks use interest and make it very easy to turn it off
<bkardell_> s/is there a preference for something/is there a precedent for something
<brecht_dr> q+
<hdv> masonf: was pushing for popover to keep it out of flow before but not sure on that now
<gregwhitworth> ack bkardell_
<Zakim> bkardell_, you wanted to say I suggested this for tabs
<sanketj_> I think I like the "backup plan" option better. Maybe the requirement would be that the UA needs to provide some type of UI to view interest - what that looks like may vary. Agree that the context menu has its limitations.
<hdv> bkardell_: it's come up a few times over the years… I don't think we have ever done that but it does keep coming up
<chrishtr> I really like the idea of showing the pseudo element icon by default on every platform; developers can then remove it / restyle it as needed.
<hdv> bkardell_: maybe there isn't a good answer… and UA nor author can provide it, it's really a user preference thing
<hdv> bkardell_: so maybe the best thing we can do is to make it very easy… if it's not observable that's probably easy, if not it's a bit harder
<gregwhitworth> ack brecht_dr
<hdv> brecht_dr: to masonf's earlier point… I think if we go that route we should be able to style the icon as well. And then there could be some other solutions on touch devices
<hdv> masonf: proposal definitely was that it would be a pseudo element that could be styled in all the ways pseudo els can
<hdv> una: curious to hear feedback from Apple on this
<hdv> una: I think it's a very interesting path forward
<hdv> masonf: I think next step would be to write out the proposal and maybe have the discusson on the webkit thread that already exists on this and has a lot of discussion already
<gregwhitworth> Zakim, end meeting

[mfreed7]

Great discussion just now, thanks all. So I'm coming down to a more concrete proposal:

<button interesttarget=foo>Button</button>
<span interesttarget=bar>some text</span>

The idea would be that both of those elements (the button and span) would generate pseudo elements that could be targeted like:

[interesttarget]::interest-target-icon {
  content: "?";
  background-color: linen;
  border: 0;
}

which would be presented as:

Clicking those ? buttons would trigger the interesttarget target element. The buttons could be made fully accessible, they would be part of the sequential focus navigation, etc.

To address the concerns raised in the meeting:

1. The ::interest-target-icon pseudo element would always be generated for any element that has an interesttarget attribute. This would not be dependent on pointer event precision, etc.
2. The pseudo element could be used to disable or control the visibility of the icons, as well as style them to fit the page.
3. The pseudo element would come after the element with interesttarget, but would be styled (by default) as position:static so that no content would be obscured. However, developers could change that to position:fixed and anchor-position them, if desired.
4. Hovering (with a mouse) the originating element (e.g. the button and span in the example) would also trigger interest.
5. Focusing (with a keyboard) the originating element would not trigger interest, since the preferred way to do that would be tabbing to the ? icon and activating it. This also removes the need to make <span interesttarget> keyboard focusable.
6. We should (strongly?) recommend that UA's have a user setting that allows three things: 1) the default behavior, 2) always show the ::interest-target-icon (even when developers have hidden it), and 3) never show those.

[mfreed7]

(Let's keep this marked with Agenda+ so we can discuss again next week, please.)

[jakearchibald]

I don't agree with this direction, for the same reasons :hover doesn't do any of this. interesttarget is for hover/focus. commandfor is for activation. Don't make interesttarget also kinda activation. If developers want this behaviour, they can add a commandfor element wherever they want.

<button interesttarget=foo>Button</button>
<button commandfor=foo>?</button>

3. The pseudo element would come after the element with interesttarget, but would be styled (by default) as position:static so that no content would be obscured. However, developers could change that to position:fixed and anchor-position them, if desired.

This is a really unusual default. <button>hi</button> takes up one cell in your grid layout. <button interesttarget="foo">hi</button> takes up two because of a sibling pseudo element??? I can't think of anything else in HTML that works like this.

5. Focusing (with a keyboard) the originating element would not trigger interest, since the preferred way to do that would be tabbing to the ? icon and activating it. This also removes the need to make <span interesttarget> keyboard focusable.

What if a developer wants the interest to be triggered on focus? I think that's what most folks will want.

6. We should (strongly?) recommend that UA's have a user setting that allows three things: 1) the default behavior, 2) always show the ::interest-target-icon (even when developers have hidden it), and 3) never show those.

I doubt browsers will add this, as it's extremely hard to describe to a user.

---

Folks thinking about this should consider how they'd implement something as common as the toolbar in Google Docs. I guess they'd have to:

1. Hide all these pseudo-elements.
2. Make 'interest' somehow work on focus (is this even possible?).
3. Pray that no one activates this layout-breaking browser option that the user almost certainly doesn't understand.

If I was on that team, I'd say it sounds easier just implementing it manually with JS, rather than having to fight the browser's default behaviour.

[scottaohara]

@jakearchibald just double checking you are aware this (edit: latest) conversation / proposal was being had for what to do for mobile/touch (dare i say even voice) scenarios where hover/focus may not even be something the user could do / easily do.

just asking because i am not disagreeing with any of your comments in regard to a traditional desktop experience, but they aren't reading, to me, as acknowledging the use case this was trying to solve for or what to potentially do instead.

[jakearchibald]

I formally acknowledge the mobile use-case 😄, but I'm pointing out that the proposals in #1052 (comment) make the API hard to use in cases it was designed for, and the result will be that people will avoid this API and do what they actually want with JS instead. That seems like a bad outcome for this API.

In cases where folks want a way to activate interest targets on click, that's what commandfor is for. This allows the developer to choose when and where the additional element appears.

[scottaohara]

thanks for the acknowledgement / expansion on your thoughts, @jakearchibald, they are appreciated :)

hope to see you in open ui meetings again, someday

[mfreed7]

I formally acknowledge the mobile use-case 😄, but I'm pointing out that the proposals in #1052 (comment) make the API hard to use in cases it was designed for, and the result will be that people will avoid this API and do what they actually want with JS instead. That seems like a bad outcome for this API.

I'm glad you're supportive of mobile/touch. Sounds like you're also supportive of an API that tries to address these use cases (hover-triggered popovers, menus, etc.)? If so, and if you're against this recent suggestion, do you have an alternative idea? Without a concrete (and explicit) solution for touch users, WebKit is against this API. (Yes, that's a standards position for popover=hint, but their objection is only about this proposal for interesttarget). And I'd want to ship something interoperable.

This is a really unusual default. <button>hi</button> takes up one cell in your grid layout. <button interesttarget="foo">hi</button> takes up two because of a sibling pseudo element??? I can't think of anything else in HTML that works like this.

This is a very good point. I wonder if the pseudo element could somehow be a child of the element, rather than a sibling, to avoid the problem?

What if a developer wants the interest to be triggered on focus? I think that's what most folks will want.

Yeah, perhaps it could still be triggered on hover and focus. That was, in fact, the original proposal before the meeting. I think the hard part is providing developers a good hook to turn these extra buttons on only when the user needs them, i.e. when there's no keyboard or mouse present. Is there a good media query that will do that correctly?

I doubt browsers will add this, as it's extremely hard to describe to a user.

I can speak for one browser that would be willing to try to describe this in a sentence or two. 😄

Folks thinking about this should consider how they'd implement something as common as the toolbar in Google Docs. I guess they'd have to:

1. Hide all these pseudo-elements.
2. Make 'interest' somehow work on focus (is this even possible?).
3. Pray that no one activates this layout-breaking browser option that the user almost certainly doesn't understand.

If I was on that team, I'd say it sounds easier just implementing it manually with JS, rather than having to fight the browser's default behaviour.

The last sentence is interesting to me - what would that JS do? Whatever it is, that's the behavior we're trying to build into the platform. Unless, of course, it's just to say "too bad about those touch users - they'll just have to be in the dark about what all these toolbar buttons do. Adding affordances for them would make things 'ugly'." And my fear is that this is exactly what most design systems do today, precisely because they don't have a standardized way to handle this.

[flackr]

The last sentence is interesting to me - what would that JS do? Whatever it is, that's the behavior we're trying to build into the platform. Unless, of course, it's just to say "too bad about those touch users - they'll just have to be in the dark about what all these toolbar buttons do. Adding affordances for them would make things 'ugly'." And my fear is that this is exactly what most design systems do today, precisely because they don't have a standardized way to handle this.

In terms of what the expected platform behavior is, on Android it is long press to show tips. On iOS where long press doesn't work I also haven't seen ℹ️ icons to tell me what buttons do so I'm not sure if iOS has a pattern other than ensuring that your interface has text or is reversible? I would prefer to see us aligning with native toolkits if possible.

We do have to wrestle with the fact that this is an overloaded interaction. I think an acceptable way to deal with this might be to warn developers when they have a tooltip on an element that is also draggable or also has a contextmenu listener.

[flackr]

One concern I'd have with having additional icons is that this is typically on devices where screen real-estate is far more restricted and so is likely to result in things no longer fitting if you add this.

[jakearchibald]

@mfreed7

I'm glad you're supportive of mobile/touch.

Have I done or said anything in the past that gave you the impression that I'm not, or that I wasn't?

Sounds like you're also supportive of an API that tries to address these use cases (hover-triggered popovers, menus, etc.)? If so, and if you're against this recent suggestion, do you have an alternative idea?

Yes, I already mentioned it in both of my previous comments:

<button interesttarget=foo>Button</button>
<button commandfor=foo>?</button>

This allows the developer to put the "command" alternative wherever they want. It also allows for things like a toolbar to have a single command alternative that covers the 'help' for that whole toolbar.

There are cases where you want the tooltip to appear on focus-visible style focus, or on hover. There are cases where you want the tooltip to appear on hover or activation. The API should be designed with these in mind.

Without a concrete (and explicit) solution for touch users, WebKit is against this API. (Yes, that's a standards position for popover=hint, but their objection is only about this proposal for interesttarget). And I'd want to ship something interoperable.

That's unfortunate. Lack of interoperability is a failure case. However, if Chromium and WebKit shake hands on an API that developers won't want to use, that's still a failure.

I think it's ok to have APIs that lean into advantages of a particular device. Safari released rel="ar", which is only really useful for devices with a rear-facing camera.

Information that's available on hover can be a nice enhancement for pointer users, but of course developers should provide an alternative way to access that information. There are many ways to do that, such as labels, and help buttons that cover multiple hover points. For example, you could have a toggle that adds labels to all or a subset of the icons, which would take up more space, but could be toggled back away.

If the content is fewer actions away on desktop vs mobile, I don't think that's an issue. Just as the Safari AR experience is enhanced on mobile. Just as many desktop sites place content in-view that's a tap away on mobile, due to the space available.

I don't understand why we're looking for a lowest-common-denominator approach.

I wonder if the pseudo element could somehow be a child of the element, rather than a sibling, to avoid the problem?

That's how ::before and ::after work in CSS (yes, they're badly named). However, many elements in HTML cannot have children, such as inputs and images.

Yeah, perhaps it could still be triggered on hover and focus. That was, in fact, the original proposal before the meeting.

I know, that's why I was complaining about the new direction. I think it's important to have use-cases in mind, and if there's a big change in direction, write down or at least think about how developers would hit those use-cases with the changes proposed.

I think the hard part is providing developers a good hook to turn these extra buttons on only when the user needs them, i.e. when there's no keyboard or mouse present. Is there a good media query that will do that correctly?

There's any-pointer. But again, my issue here is that the 'solution' presented here is too restrictive and footguny.

I doubt browsers will add this, as it's extremely hard to describe to a user.

I can speak for one browser that would be willing to try to describe this in a sentence or two. 😄

I'm sceptical, but I've been surprised before. What's the draft wording so far?

…If I was on that team, I'd say it sounds easier just implementing it manually with JS, rather than having to fight the browser's default behaviour.

The last sentence is interesting to me - what would that JS do?

It would try to provide the best UX for all users. A lot of developers might get that wrong, but if you push developers away from your 'ideal' API by making it unsuitable for a number of use-cases, or make it feel unreliable due to footguns, then that's the consequence.

This is well documented. OpenUI has a whole customisable select effort because developers badly recreate <select> from scratch because it doesn't work for a number of use-cases.

Whatever it is, that's the behavior we're trying to build into the platform.

I assumed that was still the goal. Which is why I voiced my concerns, because the goal is being missed with this new direction.

Unless, of course, it's just to say "too bad about those touch users - they'll just have to be in the dark about what all these toolbar buttons do. Adding affordances for them would make things 'ugly'."

I hope this group remains a safe place to discuss and debate API changes. Specifically, I don't want to see alternative viewpoints shouted down as "you don't care about [some section of users]" when that clearly isn't the case.

Also, visual design is a key factor in the user experience of any user that consumes the web visually. Web design is a major part of what makes the web work, and folks who do it well are highly skilled. Please don't dismiss it as pretty vs ugly.

[mfreed7]

Yes, I already mentioned it in both of my previous comments:

<button interesttarget=foo>Button</button>
<button commandfor=foo>?</button>

This allows the developer to put the "command" alternative wherever they want. It also allows for things like a toolbar to have a single command alternative that covers the 'help' for that whole toolbar.

Right - that can work, but it's manual. The same for monitoring touch start/end to detect long-press. I'm hoping we can find the best and most common pattern for touch and provide an easy declarative API for that. It is starting to sound like the "add (i) buttons to everything" approach is not that common pattern. 😄

Without a concrete (and explicit) solution for touch users, WebKit is against this API. (Yes, that's a standards position for popover=hint, but their objection is only about this proposal for interesttarget). And I'd want to ship something interoperable.

That's unfortunate. Lack of interoperability is a failure case. However, if Chromium and WebKit shake hands on an API that developers won't want to use, that's still a failure.

Agreed, for sure. Hence this discussion.

Information that's available on hover can be a nice enhancement for pointer users, but of course developers should provide an alternative way to access that information. There are many ways to do that, such as labels, and help buttons that cover multiple hover points. For example, you could have a toggle that adds labels to all or a subset of the icons, which would take up more space, but could be toggled back away.

I think the issue is that since this is such a tricky thing to implement (get it right for mouse, keyboard, touch, AT, hook up a11y mappings correctly, etc.) many design systems simply "punt" all but the hover interaction. They ensure the information in the hovercard isn't "necessary" for the user to see, and then just don't show it to those users. Which I see as unfortunate.

If the content is fewer actions away on desktop vs mobile, I don't think that's an issue. Just as the Safari AR experience is enhanced on mobile. Just as many desktop sites place content in-view that's a tap away on mobile, due to the space available.

Good to hear. That's still one contender - add a "show interest" item to the UA-provided long-press menu. It's more difficult to do, but at least it's available.

I don't understand why we're looking for a lowest-common-denominator approach.

Welcome to web standards. 😄

I know, that's why I was complaining about the new direction. I think it's important to have use-cases in mind, and if there's a big change in direction, write down or at least think about how developers would hit those use-cases with the changes proposed.

Yeah, thanks for the comments. Based on your responses and a bunch of others, it does seem like the "automatically add a (i) button to everything" approach is likely not the right one. I'd like to have a discussion about this at TPAC, and I'll try to put together a presentation with use cases and potential approaches.

I can speak for one browser that would be willing to try to describe this in a sentence or two. 😄

I'm sceptical, but I've been surprised before. What's the draft wording so far?

I don't think we can write the wording for a feature that controls something that isn't defined yet.

It would try to provide the best UX for all users. A lot of developers might get that wrong, but if you push developers away from your 'ideal' API by making it unsuitable for a number of use-cases, or make it feel unreliable due to footguns, then that's the consequence.

Agreed.

Unless, of course, it's just to say "too bad about those touch users - they'll just have to be in the dark about what all these toolbar buttons do. Adding affordances for them would make things 'ugly'."

I hope this group remains a safe place to discuss and debate API changes. Specifically, I don't want to see alternative viewpoints shouted down as "you don't care about [some section of users]" when that clearly isn't the case.

Sorry if you felt that way! I honestly didn't intend it as trying to shout anything down. (Perhaps be a little provocative?) On the contrary, your response (plus many others) have lead me to conclude that this approach is likely the wrong direction. This discussion, plus the live one we had last week, has been exactly what I was looking for. So thanks! And I hope you can keep contributing your ideas so we can find a good solution. My motivation is simply to make sure we've heard all of the ideas so that we can pick the best one. This feature is like an open field: the cows go a number of different directions, so the paths aren't well worn. But they're all trying to go in a general direction, so we need to find the best of those faint paths to pave.

[css-meeting-bot]

The Open UI Community Group just discussed [interest invokers] Touch inputs.

The full IRC log of that discussion

<jarhar> masonf: the question is how to support touch for interest target
<jarhar> masonf: one suggestion we dug into was what if we make a button pop up next to everything with an interest target and touch users can tap it
<jarhar> masonf: that was viewed as a not good way to do it because theres visual clutter
<jarhar> masonf: and extra tab stops for keyboard users
<jarhar> masonf: conclusion was that this is not the right approach
<jarhar> masonf: the one approach i keep hearing is long press
<jarhar> masonf: it seems like long press is the standard mechanism for this kind of thing
<jarhar> masonf: the problem is that theres no easy api for that that isnt overriden by what current browsers already do for things like links
<jarhar> masonf: maybe the best way forward is to spec interest target on touch screens as long press - then a context menu shows up, and the first item in that context menu should be to show interest in this element
<jarhar> masonf: why is that a terrible idea?
<jarhar> q?
<masonf> q?
<flackr> q+
<jarhar> flackr: if we don't already have something that we're doing on long press, i feel like we shouldn't be showing an unecessary menu
<jarhar> flackr: it is already the case that buttons on android, long press shows your interest based thing in native android
<jarhar> flackr: i think we should do the same for buttons because there is no long press menu for buttons on mobile
<jarhar> flackr: where this gets challenging is cases where we do have some sort of menu for links or images
<keithamus> q+
<jarhar> flackr: it might be a good idea. trying to think of what the alterantive could be. could you long press and then move your finger to indicate that you didnt want to open the menu or timers
<jarhar> flackr: maybe what you proposed is the best we could do
<jarhar> masonf: there has to be a way for the user to know to do this. if theyre used to doing long press and the context menu shows interest its discoverable
<masonf> ack flackr
<jarhar> flackr: if the timer was different, like the fact that something happened before the menu showed, that would be an indicator to the user to do something there
<jarhar> flackr: timer based things are tricky
<jarhar> masonf: the key thing for me is that its discoverable somehow. either it gives them a clue or some way for the user agent to tell
<masonf> ack keith
<jarhar> keithamus: the main use case for interest is showing some kind of popup. we can lean into that pattern a bit. i would make the case of why not show both the context menu and the popup?
<jarhar> keithamus: if i long press on a link, i get a context menu and a page preview. there is nothing blocking us from taking the popover element and putting that in the page preview
<jarhar> keithamus: native applications give you the same kind of thing
<jarhar> keithamus: you could envisage a popup next to the context menu showing the additional stuff for a long press
<flackr> +1
<jarhar> masonf: there may be issues with that. that preview on ios is the actual preview of the actual site. there may be some spoofing issues where you show a fake version of a site that you might get that isn't the same as the one if you tap on it
<jarhar> keithamus: there would need to be some visual treatment to disambiguate
<scott> q+
<jarhar> keithamus: to me, this is the central thing that i would like to take to a broader audience to challenge the idea that we cannot do this. the main pushback being that we can't coopt long press because of existing ui
<flackr> +1
<una> +1 also
<jarhar> keithamus: if we're aiming to have the web platform operate with the same power as native apps, this is functionality that native apps can handle, so its not outside the realm of possibility
<una> q?
<jarhar> keithamus: theres a ton of options that we can explore, thats the direction i would like to take this
<jarhar> masonf: i think the pushback isn't that we can't touch long press, although i tmight be, i heard that theres no paved cowpath on the web
<jarhar> masonf: no design system handles touch users, therefore we don't need to
<jarhar> flackr: we did implement legacy behavior to support hover and active target on touch, so websites using hover are possible to navigate with touch because the browser says that if you touch something youre also hovering it
<jarhar> masonf: links are the thing that have a very special behavior on one os which would have to be changed to support this
<jarhar> flackr: i want to put this in the native ui, preview plus info thing
<masonf> q?
<jarhar> flackr: the ua should be able to preserve the ability to preserve the preview but also show this thing
<sanketj_> q+
<masonf> ack scott
<una> q+
<flackr> q+
<jarhar> scott: if we cant add things to the context menu, then it still holds some water. if they still dont like it anyway, then it sounds like theyre giving up
<jarhar> masonf: the button idea didn't sound very popular
<masonf> ack sanket
<jarhar> sanketj_: are there touch surfaces where there is no context menu?
<jarhar> flackr: what do you mean? on phones there is no context menu on most long presses except links and pictures
<jarhar> masonf: there is kind of one on selection of text
<jarhar> flackr: yeah that depends on selection, its sort of a context menui
<jarhar> sanketj_: im not sure either. my intuition is that there is no context menu for interest targets. with lack of a concrete example its hard to have a discussion, but if there is, then do we have a proposal that works in that case?
<jarhar> masonf: robs suggestions was good. if there would have been a context menu then do a special thing. if there would not have been a context menu, then just show the popover
<jarhar> sanketj_: that makes sense. about the context menu: if the contextmenu event is preventdefaulted, would we still show the preview in that case?
<jarhar> masonf: that seems like a case where you would fire the interest immediately because theres no context menu to show up
<jarhar> sanketj_: we would have to handle that case
<jarhar> flackr: in that case the context menu is interest, and the developer wants to do something else. ios also doesn't fire this
<Penny> q+
<jarhar> masonf: if youve preventdefaulted the contextmenu event then we shouldn't do interest?
<jarhar> masonf: what if they want to do their own thing with an interest invoker?
<jarhar> sanketj_: whatever we choose here, contextmenu is going to fire for touch and non touch
<jarhar> flackr: the default action for contextmenu for touch would be to show interest. for mouse we woulnd't say that it is to show intere3st
<jarhar> sanketj_: what about some future type of input thats not mouse or touch?
<masonf> q?
<jarhar> keithamus: eye tracking would need an explicit gesture. we discussed this at tpac last year
<jarhar> keithamus: theres a variety of different devices, each would need their own gesture. a playstation dpad moves to the nearest focusable element but its not like a cursor pointer, its more like an assistive cursor. doesn't change focus but makes it so you can
<jarhar> keithamus: all these devices are already built around this notion of focus being the central modality for interest for that input devices
<jarhar> keithamus: controller has roaming cursor that you emit focus with, visual devices woudl be the same
<jarhar> keithamus: for new technologies, interest would be the same as focus, and we would think of hover as being legacy interest
<jarhar> flackr: if you roam to the button, you want to know what the button will do if you activate it
<jarhar> masonf: i think keith is saying that focusing the button is showing interest
<jarhar> keithamus: theres an explicit action to focus the element by pressing the circle button, which is separte from click
<jarhar> flackr: we need separate things for interest
<masonf> ack una
<jarhar> una: ive been looking at hover cards on apps and sites. facebook on safari prevent default long press and has a custom menu that pops up, and some other custom links in there
<jarhar> una: its not a common pattern, its just hard to do that. other sites with hover cards dont take advantage of that, it takes a lot of scripting. its the most natural behavior, long press, which we could spec, and have that be a part of how you access interest target
<jarhar> una: with apps, its a lot easier to access the long press behavior. on mobile web its harder. it highlights a gap
<jarhar> una: i agree that the most seamless user experience would be long press. cool to see that theres some precedence for it on a website
<masonf> ack flackr
<jarhar> flackr: the two options arent exclusive - adding a button and having hover show interest
<keithamus> q+
<jarhar> flackr: you could image a pseudo class that would allow for creating a button to show interest. if we cant do context menu, then we could have an interest button
<jarhar> flackr: solves use cases in issue where we cant put things in toolbars, but text has more room for buttons
<masonf> ack Penny
<jarhar> Penny: we're saying that its up to the developer to indicate that there is something to explore via long press by coloring differently etc.
<jarhar> masonf: rather than have one built in?
<jarhar> Penny: have one built in, or any sort of indicator like a pseudo element or a color or anything else
<jarhar> una: that should be up to the author
<jarhar> masonf: you find this on your own by seeing what can be long pressed
<masonf> q?
<jarhar> flackr: if we make it focusable, then its better than hover today
<brecht_dr> q+
<jarhar> keithamus: if its just for links and buttons then they would be focusable anyway
<jarhar> keithamus: what if you did tabindex=-1? thats an author error right?
<masonf> ack keith
<masonf> ack brecht
<jarhar> brecht_dr: +1 on long press idea
<jarhar> brecht_dr: a thing that came to mind is that ive had situations where people would prevent right click on a website which is evil and has been done in the past
<jarhar> brecht_dr: what if people add everything inside a button, then choose to use invokers so that context menu cannot be opened?
<jarhar> brecht_dr: just want to throw that out there. its something we should think about
<jarhar> masonf: they can already do that today right? by preventdefaulting the contextmenu event
<jarhar> masonf: people are going to be evil
<masonf> q?
<scott> q+
<jarhar> masonf: what other problems would this cause? good question to ask
<jarhar> masonf: seems like support is for long press being the thing, and when appropriate showing it in the context menu
<masonf> ack scott
<jarhar> scott: i heard something about making elements focusable, and that made me wonder what was going on. would people be putting this on otherwise not focusable elements?
<jarhar> scott: that would destroy keyboard navigation
<brecht_dr> q+
<jarhar> masonf: that ones still an open question. current proposal is that this only works on links and buttons, and i think that covers the majority use case ive seen. definitely use cases for non link invokers, but that needs more thought
<jarhar> masonf: if we were to allow it on any element then we should make it focusable or find a way to let keyboard users find it
<jarhar> masonf: the v1 thing is buttons and links. for now it doesn't work - its the kind of thing we can expand to later if we need to
<jarhar> scott: maybe this can be solved in the general api for long press, but i know that for people with motor disabilities long press is not easy for them. if you have voiceover or talkback running, long press requires both someone long pressing to send their press through the screenreader and then another thing to make the long press actually work, its
<jarhar> complicated
<jarhar> scott: ive spoken to people about this and they hate it. if they have an actions available context menu, then that would be a way to surface that to talkback users at least
<jarhar> scott: this may come up in further conversations that people have prlblems with long press
<jarhar> flackr: does selecting something with talk back - could that show interest?
<jarhar> scott: that would be bad. touching anything means that youre trying to read it but not that youre showing interest in it
<jarhar> masonf: how does this interact with aria details? doesn't it tell you theres soemthing else you can do here?
<jarhar> scott: that is a good question and is up to the screenreader. on desktop, its not always even exposed if you are using the virtual cursor to navigate. it is consistently exposed on windows
<jarhar> scott: on ios and android, swiping - i think that ios doesn't fully support aria details at this point
<masonf> q?
<masonf> ack brecht
<jarhar> brecht_dr: for input type submit, and certainly image maps, there might be something where people want to create an interest target. out of scope right now, but we should keep it in mind
<jarhar> masonf: button-like things counted
<jarhar> keithamus: invokers is just the button element, not input type button
<jarhar> masonf: image maps also not supported?
<jarhar> masonf: custom elements are even harder because we have the issue of making them button like
<scott> clarification for minutes above: 'consistently exposed on windows if navigating using the tab key'
<jarhar> sanketj_: that is one thing we've heard with popover
<jarhar> keithamus: theres a big looming discussion about custom elements and these mixins
<jarhar> keithamus: right now the only way to do a custom element is with scripting. what does a declarative custom element look like? that might unlock some of these. a lot of desire but not a lot of concrete suggestions
<jarhar> masonf: the currently fully supported way is to do a button
<jarhar> keithamus: theres semantic delegate which could forward all things to that button
<masonf> q?
<jarhar> masonf: im happy to leave it here with no resolutions

[mfreed7]

I'd like to keep this on the agenda again for next week, to potentially discuss a keyboard-support idea. (Yes, this issue is called "touch inputs" but it's likely better titled "non-mouse inputs", since that's what we've been discussing here.)

A common complaint I've heard about simply showing interest based on keyboard focus (either immediately or after a delay) is that it's noisy and distracting. Simply navigating the site via keyboard should not indicate interest in anything.

A common pattern (used on Github actually!) is to use a special hotkey combination (Alt-ArrowUp for Github) to show interest and get hovercards to show up. The issue with that is that a) the hotkey isn't standardized, and b) it isn't very discoverable.

For a UA-provided solution, what if the UA, after an element with interesttarget has been focused for a period of time, showed its own "tooltip" that contained the hotkey needed to show the full hovercard. For example:

Thoughts?

[jakearchibald]

I know there's some push-back on putting stuff into top-layer with CSS, but if there was a CSS way to activate popovers, would that solve (or at least sidestep) the issues here?

.some-parent:has(.some-button:hover) .some-popover {
  appearance: show-popover; /* I'm sure there's a better syntax for this */
}

/* Or in many cases just: */
.some-button:hover .some-popover {
  appearance: show-popover;
}

Developers could choose if they want to activate the popover on hover, focus-visible, focus, and they could also set transition delays on those things depending on the method.

This means there isn't a feature being added specifically for hover, it's just a CSS way of activating popovers.

[mfreed7]

I know there's some push-back on putting stuff into top-layer with CSS, but if there was a CSS way to activate popovers, would that solve (or at least sidestep) the issues here?

So I don't think it sidesteps the issues, does it? Or more accurately, it sidesteps them and leaves them as problems. This would make the the keyboard case (still) only doable via focus (and not something else), and would provide no solution for touchscreen. Is that right? Or perhaps I missed something about the proposal.

[smhigley]

Just to muddy the waters a bit, there are a number of assistive tech input alternatives that function a lot like touch, but don't have things like long press. Some specific examples include:

• voice control
• switch access
• eye tracking

Similar to touch, they also lack both hover and direct focus movement (usually). I think they often don't get brought up in discussions like these because usually if things work for touch, they'll work for these. But if the solution relies on a specific platform / device, or if it relies on something like long press, these will need a separate affordance.

I do think that having interesttarget could help AT vendors implement built-in solutions into their software (e.g. a specific voice command or conditionally rendering a specific visual overlay displaying interest targets), but that shouldn't absolve us of needing to think about how the large range of alternative inputs can access this.

(Also re the mobile thing -- would focus with an external keyboard do the same thing as long press?)

[css-meeting-bot]

The Open UI Community Group just discussed [interest invokers] Touch inputs, and agreed to the following:

• RESOLVED: The activation mode for touch needs to be long-press, not single-tap.

The full IRC log of that discussion

<nmn> masonf: resolved!
<nmn> masonf: moving on to interest-target.
<masonf> scribenick: keithamus
<keithamus> masonf: We've talked about this lots; to set the stage - this is about interesttarget, and how it should work on touch screens. There are separate issues for hovering (straightforward) and keyboard (straightforward-ish)
<keithamus> masonf: the main issue I have heard is that on touch screens there is a limited set of interactions patterns - tapping, and long pressing
<keithamus> masonf: the issue is we have 3 things, tab to activiate, long press to show the context menu, and the new third thing to show interest
<flackr> also, text selection and drag and drop
<keithamus> masonf: so the question is how do you build this feature while keeping the pre-existing 2 user interaction patterns, or is there a magical third pattern we can use?
<keithamus> masonf: I feel biased that users are used to the two, and training a new third one will be tricky
<keithamus> masonf: the last we left this was "this was solvable but we need a way ???"
<keithamus> masonf: I worked with folks at google on some mockups, and shared those in the issue
<keithamus> masonf: 2 of the ideas are: re-using the single tap to show the hovercard, with additional actions for context menu or going back
<keithamus> masonf: the other idea is long press context menu
<keithamus> q+ nmn
<sorvell> q+
<masonf> ack nmn
<keithamus> nmn: I didn't see the most recent comments, but first I want to clarify why long press is the valuable thing
<keithamus> nmn: if we wanted to show something on a tap - thats click on every other platform
<keithamus> nmn: its a tap on touch screens, but we already have many ways to show menus or popovers on click
<masonf> q+
<keithamus> nmn: tying interesttarget to click doesnt add any value
<keithamus> nmn: if its the most doable version, and it still triggers on hover with mouse pointers but tap on touch screens, the question becomes: is that a risk?
<keithamus> nmn: I think it's a risk, adding the additional friction for users who want to tap and go is not desirable
<keithamus> nmn: the thing on facebook is: the hovercards are always shortcuts, preview + shortcuts.
<keithamus> nmn: my argument has always been that the right click menu, for lack of better term, is already a pattern used for shortcuts on all platforms
<keithamus> nmn: and preview+shortcuts on ios
<keithamus> nmn: as we want to add custom preview + shortcuts, my general thinking is we should reuse this
<keithamus> nmn: if this always triggers on right click instead of hover with mouse, that would be preferable to on tap
<keithamus> masonf: just to clarify that pattern would be to tap on mobile and hover on desktop
<keithamus> nmn: yes, understood, I think for us we would have to turn it off for touch screens on mobile due to the added friction on tap
<keithamus> nmn: it sounds like a loophole to only turn it on for hover, as we discussed in the past
<keithamus> masonf: just to understand, the two taps is why you'd turn it off for mobile?
<masonf> ack sorvell
<keithamus> sorvell: Im starting to see a general solution. I think masonf's summary is good; there are two things you can do on desktop: hover and right click, but touch has 1 - long press
<masonf> s/starting/struggling
<keithamus> sorvell: the solution today is: never show on mobile or always show on mobile or just _totally_ redesign the whole thing, like bottom sheets
<flackr> q+
<keithamus> sorvell: shoehorning long press... I have concerns. The menu action.. the page isn't involved there. I right click an image I get save actions, a link I get link options. Conflating that with custom UI is concerning
<keithamus> sorvell: as we're pointing out the common use case is that this will be a link
<keithamus> sorvell: messing with a link is really bad, I have specific ideas of how this should work... how many times have we run into links that aren't links? It's frustrating
<nmn> q+
<keithamus> sorvell: on ios, with site previews, which is _almost exactly what we want_ is good and bad. its good because it points us in a direction of what we want, but it's bad because it has trained users that it is not interactive
<keithamus> sorvell: if we suddenly make it non interactive then it's going to be new and problematic
<keithamus> sorvell: I want to be talking to apple hig people or material design people to talk through this, it's a fundemental feature to be adding that you _just- cannot mess up
<keithamus> q+
<keithamus> masonf: I want to point out - my initial reaction to single tap was that maybe it's not the right pattern. Since we've heard that a few times maybe we focus on the long press, where you get a preview. For many reasons you cannot make that interactive. Spoofing for example
<keithamus> masonf: but it seems to address the rest of what I've heard - users are used to it, it fulfills most of what is wanted for the hovercard, it shows the preview. The only unsolved problem is the interaction - sorvell makes a good point about interactivity. So what happens when you tap on the hovercard or the buttons specifically?
<keithamus> masonf: maybe we could store what they tapped and replay it with JS
<masonf> ack mason
<masonf> ack flackr
<keithamus> masonf: but the simpler solution is to have the menu disappear and the hovercard is still showing, interactable.
<keithamus> flackr: my weekly callout that long press is already heavily overloaded, it's not just one thing.
<keithamus> flackr: drag and drop, text selection are both long press triggered
<keithamus> flackr: this also shows up in native contexts like ios home screen
<keithamus> flackr: there are use cases for this feature where we dont have a context menu
<keithamus> flackr: if you're not long pressing on a link, can we show the thing we'd show on hover without this preview UI?
<keithamus> masonf: the proposal right now is buttons and links, which always have a context menu
<keithamus> flackr: button does not have a context menu at all
<keithamus> masonf: I dont think there's a problem with long press showing the hovercard...
<keithamus> flackr: having the disambiguation UI for links sounds like its great more generally
<sorvell> q+
<masonf> ack nmn
<keithamus> masonf: it doesnt add confusion to the user.. if its one thing they see the one thing they're kind of used to, otherwise they see a mneu
<keithamus> s/mneu/menu
<keithamus> nmn: a system tap target essentially, it opens the hovercard, essentially a dialog
<keithamus> nmn: it could be useful to break this down, I think there are use cases to show a hovercard on long press for elements other than links, but the specific challenge is with links. We don't want the contextual menu to be affected in any way but also break existing behaviours
<keithamus> nmn: the second problem that this would be solving is the a11y question - hovercards today even on desktop aren't accessible. We should solve those two problems to start... the a11y and how they work on links
<keithamus> nmn: the rest can be solved with JS today, but we can extend to non-link scenarios. Link is the final boss, the most difficult use case, we can simplify as needed
<keithamus> flackr: yeah I don't want to focus on just non-links, but it would be nice for developers to use the same nice thing for non-links that we already but the thought into
<masonf> ack keith
<masonf> keithamus: current pattern on ios is that a preview is shown, and tap anywhere navigates to the link.
<nmn> q+
<masonf> keithamus: there's a way to inject items into the context menu, right? Is that a thing to bring back?
<masonf> keithamus: I did a mockup that you get the menu items but under them, with a horizontal divider, you get site specific stuff. E.g. custom site links.
<masonf> keithamus: I don't know why the menu doesn't have the same thing?
<masonf> ack sorvell
<keithamus> masonf: internally I discussed with the designer who said "let's just pull out the interactive buttons", but that is hard to do
<keithamus> sorvell: if I, as a user, take the time to long press to bring up the UI, I don't want any additional friction! I think additional items in the context menu is problematic because the UI should be rich.
<masonf> q+
<keithamus> sorvell: I don't think apple will accept changing the existing popup previews, but a visually distinct paradigm could be used. So we know its not the canonical preview UI
<keithamus> sorvell: as a user I am satisfied because after taking the time to long press I still get to interact
<keithamus> masonf: so the preview is interactive?
<flackr> qq+
<keithamus> sorvell: on ios right now, in this scenario, you get a preview window with the context menu below; both are interactive. Clicking anywhere in the preview window will click the link. There's also a "hide preview" button which allows you to customise the preview. Perhaps theres another mode which is "make it interactive"
<keithamus> sorvell: so maybe it now has a special border around it and the preview is now interactive
<keithamus> sorvell: but we do it with some visual design to differentiate
<keithamus> masonf: one issue; users are trained to understand it's a preview. Tapping somewhere would not be a link... the smaller of the two. The other is the security issue - if I can make something that looks just like it, then I can spoof the UI and make the site interactive
<keithamus> flackr: the key is the very recognisable different UI, for example blurring the UI, providing clear system interface. Maybe the menu is the only system popup, the page isn't blurred at all, or something. I don't know what it looks like
<keithamus> masonf: this is already a complicated area and teaching users to know which is the secure part or non secure part is difficult
<masonf> ack flackr
<Zakim> flackr, you wanted to react to sorvell
<masonf> ack nmn
<keithamus> nmn: thinking about both proposals; another one to add to the pile: if there's a new system menu option, always, so the context menu gets one extra option which is provided by the system and it opens the interactive version of the preview
<keithamus> nmn: otherwise you get to customise the preview shown
<keithamus> nmn: today safari has the preview of the page you would go to, but you're allowed to give custom preview in ios native. This is a custom preview with "I also have shortcuts"
<keithamus> masonf: so if you long press on something, one additional item says "show me the hovercard"?
<keithamus> nmn: the long press still shows the inert preview
<keithamus> masonf: oh so it's the last mockup, in the issue, but a new menu item to tap on the preview?
<scott2> q+
<keithamus> nmn: no the menu item would be a new mode to show the interactive hovercard
<keithamus> masonf: correct me if I am wrong but we've decided that single tap is out? Long press is the only way
<masonf> Proposed resolution: The activation mode for touch needs to be long-press, not single-tap.
<keithamus> +1
<bkardell_> sure
<sorvell> q+
<masonf> ack mason
<masonf> ack scott
<keithamus> scott2: I liked the proposal. If we could get ios to do this - the ability to change the preview - it would be really great if websites like github where if I logged in, if I accidentally long pressed I dont get another preview because I already know where I am
<masonf> ack sorvell
<keithamus> sorvell: my concern is that if there is any additional friction, i might be inclined to say screw that whole design and have an i button next to my link
<keithamus> q+
<keithamus> sorvell: it feels troublesome to me to say that we can standardise this
<scott2> adding the extra I icon also being the thing people were getting all miffed about :D
<masonf> ack keith
<keithamus> masonf: so can we resolve to single tap being out?
<masonf> RESOLVED: The activation mode for touch needs to be long-press, not single-tap.
<scott2> (and for valid reasons - as keith mentioned, it can be done now)

[mfreed7]

Great discussion just now, thank you all. Things I heard:

• The resolution, which is that single-tap needs to stay as-is, e.g. navigating directly to links. Long press needs to be the way users get to this additional functionality.
• For long press, I think most of the discussion implicitly "agreed" with the very bottom image in [interest invokers] Touch inputs #1052 (comment), which shows an inert preview of the hovercard, plus the context menu. The disagreement was all around the interaction pattern. I heard several concepts:
  • Since the preview is inert, tapping anywhere on the preview should return to the page and show the hovercard in the page, which is interactive. This aligns with the mental model that the preview is indeed a "preview" and tapping on it makes it "real".
  • Since the preview is inert, tapping anywhere on the preview should navigate to the link (assuming interesttarget is on a link in this case). There should be an additional item added to the context menu in this case called "show hovercard" or similar, which allows the user to return to the page and show the hovercard in the page.
  • For things that don't already show a context menu, there's no need to show one now. Just directly show the hovercard in this case.
• There was an overall sentiment that we definitely need to get the a11y right in all of these scenarios, which is clearly true. But I think we probably first need to decide upon a rough interaction pattern, so we know what that even means.

[sorvell]

The disagreement was all around the interaction pattern. I heard several concepts:

Concerns

1. Since long-press is already a cumbersome activation mechanism, I think it would be extremely unfortunate if the user couldn't complete the actual desired action with a single additional click. My concern is that if this isn't possible, the feature may end up not being used much if at all.
2. The current iOS behavior has trained users that page previews are only holistically interactive, a click anywhere is a navigation to previewed page.
3. Making the preview interactive while showing the context menu may be a security issue.

Proposal

Option 1: The preview and the context menu are both interactive, and the preview is given an obvious different visual treatment than the default iOS preview to help make it clear it's fully interactive. This option requires convincing ourselves this doesn't present a security risk and is otherwise feasible to implement.

Option 2: The preview is displayed and is fully interactive. Along with it, there is a toggle button to show the context menu. Clicking this makes the UI match the existing iOS preview with the context menu interactive and the preview window only holistically interactive. Clicking the toggle button again hides the context menu and makes the preview fully interactive.

[nmn]

Making the preview interactive while showing the context menu may be a security issue.

This has been stated many time but I don't think we've ever talked about what these issues are. Having an interactive preview is probably the ideal solution. So I think we should find out what the possible security concerns are and if we can solve them somehow.

My concern is that if this isn't possible, the feature may end up not being used much if at all.

I agree that "long-press + tap" is a lot of steps to get to something that is essentially "shortcuts". However, I think it still adds a lot of value:

1. Regardless of the interaction pattern, just being able to provide custom previews is quite useful. Instead of a generic preview of an entire page, we can show just the key information.
2. Even for interactions, it is often useful to be able to take small actions, (such as following someone, or starring a repo, etc.), without being forced to do a full page navigation. A long-press is already a slower interaction method than a simple tap. Shortcuts bring enough value that users will spend more time and taps on them when it makes sense.

Option 2: The preview is displayed and is fully interactive. Along with it, there is a toggle button to show the context menu.

I don't agree with this behaviour, specially if it's the only behaviour available. It is important to ensure that getting to the normal context menu doesn't get any harder.

[keithamus]

Excusing the terrible job at doctoring the mockup, here's what I mentioned in the meeting:

So the preview could be non-interactive but expose a series of links that get rendered into the context menu (the "Follow" and "Chat" options), below the most common actions. How those links are exposed in HTML is of course a different story.

[mfreed7]

Making the preview interactive while showing the context menu may be a security issue.

This has been stated many time but I don't think we've ever talked about what these issues are. Having an interactive preview is probably the ideal solution. So I think we should find out what the possible security concerns are and if we can solve them somehow.

There is, I believe, a general fear of mixing UA-provided UI with developer-provided UI. For example, the customizable-<select> is not allowed to pop up outside the renderer bounds, for fear of things that spoof browser UI. In the exact same way, allowing custom interactive content within the existing UA-provided context menu is "scary". What if, e.g., the site provides their own widget that looks just like the UA-provided menu, and offers some of the same choices. So the developer provides another "Share" item, which the user can't tell came from the site instead of the browser. When the user clicks that developer-provided "Share" button, the site provides a fake "share" screen with a Facebook icon, and if you click that, it asks you for your Facebook credentials, etc... You can imagine many bad scenarios stemming from the ability to co-opt a previously-trusted UI.

For the same reasons, I'm afraid the idea just above (with "Follow" and "Chat" that come from the site) might not fly either.

I don't agree with this behaviour, specially if it's the only behaviour available. It is important to ensure that getting to the normal context menu doesn't get any harder.

I don't think the latest proposal makes getting to the existing context menu harder, does it? A Long-press brings up the exact same context menu, just with an additional preview showing. Any existing context menu action is still right there. Perhaps some of them now need a scroll-down to see, because the preview took some room?

---

I think it's important to recognize, in all of this, the alternative:

• Today, long press cannot be used for showing hovercards. So on almost 100% of sites that use hovercards, they simply never show up on touchscreens.
• The above point means that almost by definition, seeing or interacting with the hovercard would be a new capability. We'd be moving from "impossible" to "possible with perhaps one extra click", which seems positive, not negative.
• The much more important use cases, of desktop hover and keyboard activation, would be made trivial to construct and declarative, and would handle the a11y connections. In the bargain, touch users would get a way to access the same hovercards, which they lack today.

I just want to keep that in perspective, since the alternative to interesttarget is "status quo" which is kind of where this issue is trending.

[nmn]

@mfreed7 Thanks for the explanation!

I see the phishing concerns, but I think the concerns are a bit misplaced. A website can already hijack the long-press action and spoof the entire UA-provided UI. I don't think allowing developers to provide arbitrary interactive UI along side the context menu increases the attack surface. If anything, if the preview is always contained in the given bounds, it might actually be harder to use for phishing as it will always exist alongside the actual native UI and will always have a border around preview making it look not legitimate. We can already do a lot worse without this feature at all.

On the other hand, the "Follow" and "Click" being part of the context menu actually does seem a bit riskier.

I don't think the latest #1052 (comment) makes getting to the existing context menu harder, does it?

You're right. My comment was specific to a small part of @sorvell's comment.

---

I think it's important to recognize, in all of this, the alternative:

Thank you for summarizing! This is a very important note.

[sorvell]

@mfreed7

There is, I believe, a general fear of mixing UA-provided UI with developer-provided UI.

I agree with @nmn for similar reasons that this concern may be misplaced. Can we try to get a security review for the idea?

The current iOS UI actually does mix UA and developer provided UI, but the preview window is clearly separated from the context menu. As I mentioned In my Option 1 proposal, giving an interactive preview window a clear visual distinction along perhaps with a label could help indicate that it is obviously distinct from the context menu displayed with it.

[mfreed7]

Ok, checking back in here. I ran this set of proposals by some security/privacy folks within Chrome (thanks @arturjanc and @estark37), and their general feeling was that my concerns about mixing content into the UA-provided context menu aren't exactly real concerns. Generally, they agreed with some of the viewpoints on this thread, that since it's currently possible to spoof the entire context menu, it shouldn't be a new risk to add items to the existing menu. There are small caveats to that, such as that the UA-provided context menu often does things that a spoof cannot, like blurring the entire background (including browser UI) when it shows. See, e.g., the (doctored) screenshot in #1052 (comment). But the chances are small that this small distinction actually provides any real guidance to the user about where the menu comes from.

With that out of the way (for me at least), it sounds from this thread like the strongest candidate behavior is the one listed in #1052 (comment)? I.e. a non-interactive "preview" of the hovercard, presented within the context menu. Plus a way (perhaps a different API?) to add custom buttons with custom actions to the list of options below.

Does that sound right? If so, there are still some open questions:

1. How to define the contents of the hovercard. This will be either a popover or a dialog, and it'll have to be rendered within the page first, and then its contents (within the element's border rect, not including ::backdrop) "copied" up to the context menu. So it'll exist in both places. Does that sound right? I'm guessing it doesn't matter, since the page contents are typically blurred by the UA context menu.
2. How to define the new text menu items added to the context menu. A new attribute on buttons and links, maybe? E.g. <button contextmenutext="Follow">Follow</button> or something? Is the placement of those new buttons guaranteed by spec? Or up to the UA to just place somewhere in the menu? It likely has to be the latter - is that ok?
3. The exact spec behavior for what happens when you choose one of those menu items. My guess would be that a) the UA context menu first closes, then b) the selected button receives a (trusted) click event.

What else?

[nmn]

it sounds from this thread like the strongest candidate behavior is the one listed in #1052 (comment)?

I would say this is the second-most ideal solution. The most ideal being the ability to have the preview itself be interactive.

---

Assuming we have to go with an inert preview with custom context menu, let me try to answer the questions.

This will be either a popover or a dialog

Ideally it should be a popover with a new role for such "previews".

it'll have to be rendered within the page first, and then its contents "copied" up to the context menu.

Is this necessary? Could the UA not make a custom viewport for the Top Layer for such scenarios instead? On Desktop, it can be the actual viewport. On mobile it can be the area available to the "preview" alongside the context menu. I'm probably missing some important context on why the copying might be necessary.

A new attribute on buttons and links, maybe?

This could work. We'd also need a new CSS pseudo class to detect when a button/link has been "hoisted" out to the context menu so we can hide it from the inert preview.

Or up to the UA to just place somewhere in the menu? It likely has to be the latter - is that ok?

This should be OK.

a) the UA context menu first closes, then b) the selected button receives a (trusted) click event.

Perfect. I don't see why the same couldn't be done with an interactive preview as well.

---

I think the biggest challenge with this API will be to remember that this UI will appear on hover on platforms with a mouse pointer and we have to come up with APIs that are generic enough that they can work in both scenarios.

Did the security/privacy folks from Chrome chime in on the possibility of making the preview itself clickable?

[keithamus]

@mfreed7

2. How to define the new text menu items added to the context menu. A new attribute on buttons and links, maybe? E.g. Follow or something? Is the placement of those new buttons guaranteed by spec? Or up to the UA to just place somewhere in the menu? It likely has to be the latter - is that ok?

Yes this, but to expand and tweak slightly, I don't think the attribute should need a value, instead use either textcontent or accname computation right? Also to confirm, I think choosing one of the menu items should use the regular machinery e.g. dispatch a click event and trigger activation behaviour.

@nmn

We'd also need a new CSS pseudo class to detect when a button/link has been "hoisted" out to the context menu so we can hide it from the inert preview.

Presumably you'd hide all interactive controls in the preview right? So I think a pseudo class to know that the container has been used as a preview card would be useful, so that all controls can be hidden.

[scottaohara]

This will be either a popover or a dialog

Ideally it should be a popover with a new role for such "previews".

A popover dialog with a localized name probably. Not sure the value in a new role. Particularly if it’s to behave very similarly to a dialog anyway.

“Maybe” the role description could be modified by browsers? But unless there would be larger plans for this popup outside of this use case, I’m not sure it’d be something that should get its own role that authors could then use willy nilly?

[nmn]

Presumably you'd hide all interactive controls in the preview right? So I think a pseudo class to know that the container has been used as a preview card would be useful, so that all controls can be hidden.

Yes, this could be an at-rule as well. We just need to detect if the preview is interactive (like on desktop) or not.

Particularly if it’s to behave very similarly to a dialog anyway.

It does behave like a dialog on touchscreens, but if we remember that this proposal is a "hovercard" it works very differently than dialogs on desktop. The "dialog" role might still be the correct role, but I think we need to have a discussion about it because it's not a typical interaction model. Perhaps, it's a "non-modal" dialog which is not very well defined in the specification. (FWIW, I just worked on a new more accessible hovercard implementation and used the "dialog" role today to make it work and it does mostly work.)

But unless there would be larger plans for this popup outside of this use case, I’m not sure it’d be something that should get its own role that authors could then use willy nilly?

💯. I don't think the new role need to exist as something that authors should be able to use, but just a new role behind the scenes that the UA can control.

[mfreed7]

Ok, after a bit of internal discussion (thanks @argyleink and @chrishtr), here's another proposal. My hope is that this one satisfies most of the requests on this thread:

1. Follow the mockup provided in [interest invokers] Touch inputs #1052 (comment), which will be shown when the user long-presses the element with interesttarget.
2. There are two regions in that mockup, the top "hovercard" part, and the lower "UA provided menu" part.
   a. The site will continue to be rendered, importantly unblurred, underneath the UA provided menu.
   b. The UA will place the UA-provided menu somewhere on-screen, attempting to leave as much of the physical screen area un-obscured. For example, toward the bottom of the screen, leaving the top available.
   c. New CSS env() values will be added (subject to bikeshedding) for context-menu-inset-top, context-menu-inset-right, context-menu-inset-bottom, and context-menu-inset-left. These will allow a hovercard to be positioned safely within the still-visible space left on screen, so that both the hovercard and UA menu can co-exist.
3. Taps on the menu will perform the selected menu item. Taps outside the menu will "fall through" to the rendered page, and will also close the UA menu. I.e. interactive elements rendered on the hovercard can still be tapped, which will simultaneously activate the tapped element and close the UA-provided menu (without performing any menu actions).

With the above system, the mockup should be able to look just like #1052 (comment), but that will require more work on the part of the developer, to be sure to position the hovercard appropriately, and likely blur the rest of the screen to avoid visual clutter? That last thing might even require that the hovercard is a modal <dialog> rather than a popover, but that should also be do-able via interesttarget.

Open questions:

• What happens if the hovercard has an element with interesttarget? What's the behavior?
• Are the developer ergonomics easy enough to make this work cleanly on touch and also on desktop? I.e. what's the "hook" to determine if the hovercard should render using context-menu-inset-top, etc?
• On OS's that provide link previews in this area, is it "ok" to replace that link preview with a hovercard? I.e. what happens when long-pressing <a href=foo interesttarget=bar>? It would seem to me that interesttarget should take precedence, since it's likely providing a "better" link preview, customized to the site.

[nmn]

@mfreed7 No notes. Perfect!

What happens if the hovercard has an element with interesttarget? What's the behavior?

I think disallowing interesttarget within hovercards is an acceptable solution for now. Although it should be possible to open a second dialog within a dialog and make this work if needed.

[sorvell]

@mfreed7 #1052 (comment) seems good and similar to my option 1.

interactive elements rendered on the hovercard can still be tapped, which will simultaneously activate the tapped element and close the UA-provided menu

My understanding is that you raised this as a security issue. Was that resolved?

[mfreed7]

My understanding is that you raised this as a security issue. Was that resolved?

I asked some experts and they (also) told me my concerns were misplaced. See the comment here: #1052 (comment)

I think disallowing interesttarget within hovercards is an acceptable solution for now. Although it should be possible to open a second dialog within a dialog and make this work if needed.

Good to know that you think this would be ok. I also think it might be possible to support it, which I'd like to do, because on desktop environments, it would make complete sense to have nested interest targets. (Facebook has these already 😄 .) Perhaps when in long-press mode, and you long-press an interesttarget element on a showing hovercard, it just "works"? I.e. the new nested hovercard is shown, which (with developer styling taking care of this) takes the place of the first hovercard, and the UA menu continues to show?

[css-meeting-bot]

The Open UI Community Group just discussed [interest invokers] Touch inputs.

The full IRC log of that discussion

<bkardell_> masonf: both of these next two are about interest invokers - this one is about touch input patterns
<bkardell_> masonf: I posted a new idea for this one, which I think gets everythingI heard/enables all of the use cases
<bkardell_> masonf: on touchscreen you have an element with interest target, and you long press it - two things happen simultaneously- the target gets invoked a thing shows up and the user agent menu shows up - the new thing is that the menu shows up more like an onscreen keyboard, not covering the whole thing
<bkardell_> masonf: the idea is that the developers positions it in the free area - we provide some css env variables that let the developer see where is the free space - what are the boundaries. I think you get the best of all worlds, you can have the hover card and the user agent can show the menu
<bkardell_> masonf: I think it even enables nested hover cards
<brecht_dr> q+
<masonf> ack brecht
<bkardell_> masonf: there are some open questions - main question is what is not solveable
<bkardell_> brecht_dr: how does it work with interactive elements inside the carrd
<bkardell_> masonf: the beauty is I think it just works... it is just part of the page.
<bkardell_> brecht_dr: I am assuming that that space automatically has some overflow so that if it gets screwed up you can get to it
<bkardell_> masonf: the key thing here is that it is up to the developer - I am telling you where will not be obscured
<bkardell_> q+
<masonf> bkardell_: to brecht's point, why would that area not be scrollable? Or have overflow? You don't want to clip it.
<bkardell_> masonf: it's like layout viewport, visual viewport - it just shows you where to lay it out... you can fix position stuff - the way I see you using is you can fix position using those offsets...
<bkardell_> masonf: I don't think any of that can or should be automatic
<masonf> ack bkardell
<bkardell_> brecht_dr: the only concern I have is that this is another thing you'll have to learn, if you don't you might wind up with a thing you don't want - in those cases you'll have to test it on a device to see it happening which is complicated
<bkardell_> masonf: I agree, I share that concern - the biggest concern is that you just develop on desktop and then you don't know what happens on mobile and someone can't get to it all of the sudden
<bkardell_> masonf: we ran into similar concerns with customizable select
<bkardell_> masonf: we explicitly went against UA defaults bc that made it harder. We can't have both, so if we try to make it perfect by default it's harder
<scott2> q+
<bkardell_> brecht_dr: I feel like this is different - In this case I wish there would be a good default
<bkardell_> masonf: the thing that needs styling is the hover card - a popover or a dialog - I think what you are suggesting is a UA default that in _some_ situations would solve this
<masonf> ack scott
<bkardell_> scott2: I would be very happy if there was some level of default ua styling - to at least account for any thing invoked by an interest target at least remained within the confines of the viewport. I have never encountered a situation where a developer would want a thing like this to be obscured/half off screen and just unable to get to it
<bkardell_> masonf: I am only hesitating at "How?" and looking back to what we tried with <select>
<bkardell_> masonf: I think that was kind of roundly rejected because devs would want to undo too much.
<bkardell_> scott2: I don't want to speak too broadly but people.... don't always do that... or even often
<bkardell_> masonf: I would need to give it some thought. I think, but I could be wrong, that you need some pseudo class that tells you when a popover has been invoked by one - and we don't have that right now
<bkardell_> +1
<masonf> bkardell_: let's just make it easy by default, if I haven't thought about it.
<bkardell_> scott2: if it wouldn't be in the UA sheet by default, that makes sense, give them a pseudo class - kick the can down the road a little bit, but make it really easy
<bkardell_> masonf: so the very specific thing is that we'd ask for a pseudo class for this very specific situation
<masonf> q?
<bkardell_> masonf: let me think about it a little, it was a good discussion, but I don't want to resolve on that just yet

[nmn]

because on desktop environments, it would make complete sense to have nested interest targets. (Facebook has these already 😄 .)

💯 it's a nice to have but we would totally ok with removing nested hovercards. We might do that soon anyway as we are trying to make the current implementation as accessible as possible and nested hovercards are a challenge.