[invokers] Can we add interesttarget support to more elements

[lukewarlow]

See https://github.com/keithamus/invoker-buttons-proposal/issues/14 for more details and that repo in general for full details.

TLDR: interesttarget attribute currently proposed to be supported on buttons and links. Could we add support to <area>, <input>, <textarea>, <select>, <summary>. (selectlist in future would be on this list) along with potentially other elements?

Are there extra elements we can/should add this too?

[css-meeting-bot]

The Open UI Community Group just discussed [interesttarget] Can we add interesttarget support to more elements.

The full IRC log of that discussion

<hdv> keithamus: it was decided that interest would probably need to be opened up to more elements
<hdv> keithamus: like to <area>
<hdv> keithamus: but then it would need to be a mixin to HTMLElement… why we create a list of tags, is there not a different heuristic we can think of, like 'element has tabindex'?
<hdv> keithamus: then Luke said what if it;'s the other way around, when interesttarget to anything automatically implies tabindex to that element?
<zcorpan_> q+
<gregwhitworth> ack gregwhitworth
<scotto> q+
<hdv> keithamus: I'm curtious if people think that's a good idea?
<Luke> q+
<gregwhitworth> ack zcorpan_
<hdv> zcorpan_: which elements are focusable is up to the user agent… if you specifcy tabidnex it must be focusable… so this would be a change on macOS for links and buttons
<hdv> zcorpan_: so if you imply tabindex it would change what the set of focusable elements is from the default. is that intentional? seems strange
<hdv> keithamus: for those use cases, can we capture those as part of this? so interesttarget implies focus if you have the preference on macOS otherwise it doesn't?
<hdv> keithamus: is that reasonable?
<hdv> Luke: we could specifically call out anchor and button?
<hdv> Luke: I get the feeling that implying focusability is not popualr
<hdv> s/popualr/popular
<gregwhitworth> q+
<keithamus> q+
<hdv> Luke: the other thing I would say… that buttons don't focus by default in macOS Safari, I think that fixes something that is currently broken today (my opinion, Apple may disagree)
<hdv> Luke: as Keith said, we've gone through a number of elements and then realised maybe it should be on all… like meter and progress, they can have labels but aren't form elements
<zcorpan_> q+
<hdv> Luke: so those elements wouldn't be able to get interest for people who only are able to hover
<hdv> Luke: I realise it's quite an open ended thing
<gregwhitworth> zakim, close the queue
<Zakim> ok, gregwhitworth, the speaker queue is closed
<gregwhitworth> ack gregwhitworth
<hdv> Luke: a checkbox is quite a small target area… maybe you wanted to trigger interest on the label as well as the checkbox?
<zcorpan_> I wanted to say: list elements + allow on tabindex also
<hdv> [only one minute left]
<hdv> scotto: I'll say 'no'
<gregwhitworth> Zakim, end meeting

[css-meeting-bot]

The Open UI Community Group just discussed [interesttarget] Can we add interesttarget support to more elements, and agreed to the following:

• RESOLVED: support interesttarget on buttons (<input type=button> or <button>) and links (<a>) only, and explore expanding to other element types in the future.

The full IRC log of that discussion

<jarhar> keith: theres a proposal on invoker buttons, like popovertarget where you put invoerktarget on a button and it will do the intuitive thing like a click action on the target
<jarhar> keith: auxillary part: interesttarget, an action that happens based on floating or hovering or focusing
<jarhar> keith: some kind of gesture to determine that youre interested in seeing some floating ui for the button that you are showing interest on
<jarhar> keith: use case is for tooltips. we have the title attribute but its problematic
<jarhar> keith: in github we have hover cards where you hover over someones name and you get their profile
<una> q+
<jarhar> keith: thats kind of like a rich tooltip
<masonf> q+
<jarhar> keith: throughout the process of writing the explainer for interesttarget, we realized the amount of interactive elements that exist means you have to apply the mixin on htmlelement
<jarhar> keith: is having an allowlist of elements the right thing to do, or derive some other heuristic?
<jarhar> keith: we could have a heuristic that the elmenet is focusable, or other heuristics
<jarhar> keith: thats what we want to discuss a bit further
<gregwhitworth> ack una
<jarhar> una: we see this across many interfaces
<jarhar> una: what you brought up is a concern, that is the invoker aspect of it
<jarhar> una: does popover=hint solve this?
<jarhar> masonf: no
<scotto_> q+
<jarhar> masonf: there are two parts that sound related
<jarhar> masonf: one is how you trigger a popover, and the other is what the behavior is after you open a popover
<jarhar> una: i thought the way that this worked is that you just target a popover=hint
<jarhar> masonf: the behavior you get from a popover is what happens when it opens and does it light dismiss
<jarhar> masonf: how you get the popover open is what we are talking about today
<jarhar> una: can we support a popover type that does this
<jarhar> una: then we can reuse some of these primitives
<jarhar> una: is there a way to reuse that primitive without having to introduce a new element
<jarhar> masonf: there is no new element
<jarhar> keith: that is the aim of this proposal
<jarhar> keith: this proposal is inspired by the popover work, and interesttarget is an attribute that will exist on button elements which existss for opening interest-style popovers
<jarhar> keith: the work has been a loose collaboration with the popover work
<masonf> want to say more
<jarhar> keith: my main intent was to get invokertarget so i can open dialogs like popovers
<jarhar> keith: i asked for dialogmodaltarget, and now this has expanded into invokertarget, which has expanded into interesttarget
<jarhar> una: i incorrectly skimmed the proposal doc and i fully support this because we need it
<jarhar> keith: the looming question is i feel like we have some valid use cases for interestartget, but can we do it in an accessible way
<jarhar> keith: for my use case, im happy to have <a> and <button>
<zcorpan> q+
<jarhar> keith: luke pointed out a use case for <area>
<jarhar> keith: and then what does a custom element look like
<jarhar> keith: custom element authors want to emulate a button, and this is going to have the same questions raised
<masonf> Mason is envious of Simon having a glass of wine.
<jarhar> keith: if we are applying interesttarget to every htmlelement, we need a heuristic to decide where it applies
<jarhar> keith: im seeking advice
<gregwhitworth> ack masonf
<jarhar> masonf: im supportive of this api, and it tackles popup and other use cases that have been around for a while
<jarhar> masonf: on interesttarget, the word interest is good and nebulous enough. the spec should say that interest is defined by the user agent
<una> +1 I like the word "interest" here
<jarhar> masonf: it varies across modalities a lot
<jarhar> masonf: we should spec it in a way that is accessible, and thats where focusability comes it
<jarhar> masonf: you should be able to show that youre interested in something without hovering it
<jarhar> masonf: any element that has interesttarget should be focusable
<jarhar> masonf: but should interesttarget apply focusability or should it be broken until you put tabindex on it?
<jarhar> masonf: i am supportive on putting it on all kinds of elements
<jarhar> masonf: a span is the thing you want to put this on, you have a word in the middle of text you want to define. thats a good idea, but means you have to make the span focusable
<gregwhitworth> ack scotto_
<keithamus> q?
<jarhar> scotto: last week i said no to putting this on everything
<jarhar> scotto: to everything mason just said i agree and disagree
<jarhar> scotto: it would be horrible to make everything focusable
<jarhar> scotto: random things put into the focus order for someone to determine if something was going to be in the focus order
<gregwhitworth> q+
<jarhar> scotto: if someone makes a random word in the sentence focusable ... you can put a title on everything right now, but thank god they arent focusable. they think its more accessible
<masonf> q+
<jarhar> scotto: now we have the filename showing up in the title attribute
<una> q+
<jarhar> scotto: totally on board with buttons. i had a similar issue with popovers and this solves those problems
<jarhar> scotto: i could see this on hyperlinks as a reasonable next step
<jarhar> scotto: i get really nervous for allowing this on anything
<keithamus> q+
<jarhar> scotto: i would question if we really need to do this
<jarhar> scotto: if someone defined a custom element, maybe they could do this with script. do we need a declaratrive way to do that?
<gregwhitworth> ack zcorpan
<jarhar> zcorpan: for focusable, on macos buttons arent focusable, but theres a pref for users
<jarhar> zcorpan: having a spec level requirement saying that this is only allowed on focusable elements doesnt really work for buttons or links because that depends on the user agent
<jarhar> zcorpan: that said, if we want to allow it on any focusable element, we can do that by having the idl in htmlelement and then having the attribute only do something if tabindex is specified or if its in a list of special elements like <a> and <button> and <area>
<jarhar> gregw: i dont see why this shouldnt be declarative. sure they can do it with js, but thats why we started this. we want to make the toolkit good
<jarhar> gregw: is there an AX capability that ATs understand thats a new hook for us to use that isnt quite focus but is interest?
<gregwhitworth> ack gregwhitworth
<jarhar> scotto: its not that im saying i want this to be the end goal, but i do think there should be a declarative way to do a lot of these things
<jarhar> scotto: is this the end goal? is defining these primitives the end goal? are we not going to make a tooltip element? just use this mishmash of attributes? theres still more you need to do for accessibility
<gregwhitworth> q?
<jarhar> scotto: is getting everything declarative in an attribute that doesnt know what the end goal of the developer?
<gregwhitworth> q+
<jarhar> scotto: or are we going to build stuff on top of this?
<jarhar> scotto: i do want a declarative way, but this it? or did we get together to make elements for people? or both?
<jarhar> jen: html is accessible by default, and you dont have to do anything extra to make anything accessible which is why we made the <search> element
<jarhar> jen: if youre proposing something to add to html thats not accessible and the dev has to add accessibility in, then it violates that principle of html
<gregwhitworth> ack masonf
<jarhar> masonf: we agree with that, the conversation is how do we make this accessible and focusability seems tied into that
<jarhar> masonf: i hear you on not wanting focusable everything, if we cant find a way to do this ...
<jarhar> masonf: the point i wanted to make is that the fear that i have is lets say you only allow this on buttons
<jarhar> masonf: people will then style their borders and making fake buttons everywhere that have the wrong stuff and are semantically weird
<jarhar> masonf: if we are going to do this then we want to put it in the api proper
<jarhar> masonf: the eventual goal is to make these things easier, the api were talking about here has many usecases. one of them is a tooltip, nested menus is another, there are probably many more
<jarhar> masonf: this api should be compoatible with a future world where we have a tooltip element
<jarhar> masonf: it has default behaviors that depend on the target element. if its a tooltip element then we can do that
<jarhar> masonf: this is future-proof
<gregwhitworth> q?
<jarhar> masonf: simon you mentioned that some browsers - buttons and links arent focusable
<jarhar> masonf: interesttarget needs to be specced in a way that not just mouse users can indicate interest, thats the point
<jarhar> masonf: if a button has the interesttarget attribute on it, we need a way for keyboard users to access it
<jarhar> masonf: the point of this api is to avoid folks implementing this themselves with js, because in those cases they are broken accessibility wise, they left out keyboard users
<jarhar> masonf: not doing this api is much worse
<gregwhitworth> ack una
<gregwhitworth> ack gregwhitworth
<jarhar> una: i agree that this is akin to popover and selectlist, it can be a primitive that gets us there
<jarhar> una: it will inform the component
<gregwhitworth> +1 to una
<jarhar> una: i have a question: it seems like there is a path forward to land this declaratively for linnks and buttons
<zcorpan> q+
<jarhar> una: its primarliy been links this is used on
<jarhar> una: are there any examples of something besides links and buttons
<jarhar> una: lets just land this for links and buttons
<gregwhitworth> ack keithamus
<jarhar> keith: i have some use cases: richer content than the title attribute allows for. we can do aria-labeledby and describedby to link to rich content in the moment as a kind of fallback from a title
<jarhar> keith: theres caveats there, but rich content is one use case
<jarhar> keith: an image for example, nested menus is a valid use case as well. both hover and focus are necessary
<jarhar> keith: links for page previews, like github and wikipedia
<jarhar> keith: form controls where registering you interest on a form control would show validation criteria, it shows password strength as a password bar
<jarhar> keith: one of the other issues is the interactive art thing like an image map. literally a map of the uk, and as you hover over some of the pins then supplementary stuff is shown on the side, which could be done with disclosure widgets
<jarhar> masonf: potentially in the list of valid use cases
<gregwhitworth> q?
<keithamus> ack keithamus
<jarhar> una: i definitely agree with the submenus, thats a clear example
<jarhar> una: rich content is itneresting, essentially making it easier to show some kind of alt
<jarhar> una: or is there more description or information about the image
<jarhar> una: you already have to add some kind of scripting to make a map rather than - youre already using scripting to make that work well
<jarhar> una: page previews: those are mostly links from what i could find on github
<jarhar> keith: imagemap exists today with areas that you can click on
<jarhar> keith: they are navigations so they are technically links
<jarhar> keith: arguably we should open those up
<jarhar> keith: if we concede that links are valid interesttargets, then we should consider areas
<jarhar> keith: that is one of the raised issues that led us to here
<jarhar> keith: if we do area, then it needs to be in htmlelement
<jarhar> keith: is that a valid use case to extend to interesttarget
<jarhar> keith: im on the fence because there are other ways to do it
<jarhar> keith: to implement an image map without navigation today, its like an accordion or tab panel but very different looking
<gregwhitworth> q?
<jarhar> keith: maybe scott has some ideas on what that would be
<gregwhitworth> ack zcorpan
<jarhar> zcorpan: the are element is valid and it has somewhat new features, or at least the things that a elements support
<masonf> q+
<jarhar> zcorpan: it wouldnt be out of line or anything to specify this for all kinds of hyperlinks that html has
<scotto_> q+
<gregwhitworth> A usecase in Salesforce is help text which ultimately uses a button. https://developer.salesforce.com/docs/component-library/bundle/lightning-helptext/example
<keithamus> q_
<keithamus> q+
<jarhar> zcorpan: but it sounded like there are other use cases like images and form controls, so we could still have a fixed set of elements i think rather than support them on any element
<jarhar> zcorpan: there was another question that i have: if its useful for images, would it be useful for svg elements also? if you have a graph in svg or something else
<jarhar> una: i think this is akin to the interactive map example: probably
<jarhar> una: NYT will have advanced infographics
<jarhar> zcorpan: maybe for the first version we can start small and have the most important elements
<masonf> q?
<jarhar> una: if you are doing something like an advanced infographics then are you already using script in some way. callout about area is an interesting one
<gregwhitworth> ack masonf
<jarhar> masonf: whether youre using scripting though - even if you require scripting today id want to take this out of your hand
<jarhar> masonf: were going to learn a lot from the api and theres things we need to fix and its expandable. we can start with only on buttons and allow more in the future, thats backwards compatible
<jarhar> masonf: we could limit to buttons and links or just buttons for now
<jarhar> masonf: this explainer is huge and we are talking about a small part of it
<zcorpan> Baby Steps
<gregwhitworth> ack scotto_
<jarhar> scotto: really just big +1 to what just simon and mason are getting towards, just limit it right now
<gregwhitworth> keithamus masonf can one of you put forward a proposed resolution?
<jarhar> scotto: thats what ive been saying. im not opposed to this, im just opposed to putting this on everything at once because were excited about it
<jarhar> scotto: we dont have all these things worked out. we can do it on buttons and we know that it works
<jarhar> scotto: the area thing isnt good, that should have been buttons
<jarhar> scotto: all the things we are talking about - it should be on form controls, but what is that thing thats opening? those are the pieces we are missing because we dont know what the developer is making
<jarhar> scotto: we did that with popovers because we dont know where its going to be in the dom
<jarhar> scotto: were not going to put an aria describedby on a hint because its probably a tooltip but we dont know that
<jarhar> scotto: we can make guesses but we just dont know because its all open ended
<masonf> q?
<masonf> q+
<jarhar> scotto: with buttons, we can get that hammered down pretty well, what states need to be exposed
<jarhar> scotto: whatever needs to be open or closed, we put that on the developer
<gregwhitworth> ack keithamus
<jarhar> scotto: for popover, the semantics are from the element you put it on
<jarhar> keith: for my use cases, button and links are the only concern i have
<jarhar> keith: i know that the web components community is not going to be happy with another thing being guarded against web components because they can be valid semantic buttons i guess
<jarhar> q+
<jarhar> keith: people sure try and people raise issues for these things
<jarhar> keith: invokertarget will have that i guess
<jarhar> keith: should interesttarget?
<gregwhitworth> ack masonf
<masonf> Proposed resolution: support interesttarget on buttons (<input type=button> or <button>) and links (<a>) only for now, and explore expanding to other element types in the future.
<jarhar> masonf: lets propose this as a resolution: lets allow this on buttons and links for now
<jarhar> masonf: we should talk about that
<jarhar> masonf: for the custom elements question, people will say thats an issue
<jarhar> masonf: but lump that in with spans
<gregwhitworth> ack jarhar
<jarhar> masonf: lets learn first and add those later
<gregwhitworth> jarhar: wanted to custom elements there is a big discussion on this with builtins
<gregwhitworth> jarhar: you want to extend the button element and then it seems like that won't be in webkit. I agree with masonf is saying and this is an open issue on that outside of interest and invokertarget
<masonf> Proposed Resolution: support interesttarget on buttons (<input type=button> or <button>) and links (<a>) only, and explore expanding to other element types in the future.
<scotto_> +1
<keithamus> +1
<una> +1+
<masonf> RESOLVED: support interesttarget on buttons (<input type=button> or <button>) and links (<a>) only, and explore expanding to other element types in the future.

[lukewarlow]

To clarify is there a specific reason against <area>?

[lukewarlow]

See https://github.com/openui/open-ui/issues/857 for a request for interest support on abbr elements.

[lukewarlow]

Just while I remember I thought I'd note it down one use case for interesttarget (at least the focus aspect) on inputs in general is the <input list="foo"> type scenario where you want to be able to trigger a popover of suggestions while focused on an input. Though potentially this is better off being a platform editable combobox type setup and we don't expose the capability beyond that at least initially.

Much the same way that selectlist will have focusgroup behaviour (afaik) but we don't expose focusgroup yet.

[adactio]

Could interestTarget be used to provide a declarative option for some JavaScript APIs? I'm thinking specifcally of JavaScript APIs that require a user interaction (and so most demos involve the creation of a button element anyway) and that don't currently have an equivalent HTML element.

For example:

• The Fullscreen API
• The Geolocation API
• The Web Share API

For that last one, the default behaviour could be sharing the current URL. I've been collecting use cases to inform a proposal for button type="share" but button interestarget="share" would achieve the same goal.

Likewise, button interesttartget="requestfullscreen" and button interesttarget="exitfullscreen could be directly equivalent to document.requestfullscreen and document.exitfullscreen but without the need to create a button with JavaScript (or write any JavaScript at all).

I'm not sure how the button interesttarget="geolocation" would work other than perhaps populating an input element using invoketarget.

I realise that this issue was asking specifically for HTML elements, not JavaScript APIs, so I apologize if this is off-topic.

[lukewarlow]

@adactio could you open a new issue for that discussion?

Fwiw it would be invoketarget rather than interesttarget (click vs hover), also fullscreen API is already included! Glad to get validation that others believe that would be useful!

[adactio]

@lukewarlow Done!

https://github.com/openui/open-ui/issues/972

I didn't realise that the fullscreen API was already included—that bodes very well!

[yisibl]

<input type=range> absolutely need it! Typically used to display a tooltip.

Demo: https://codepen.io/yisi/pen/jOJWLve

[lukewarlow]

Another thought is something like an input type file where it is at its core a button. We support buttons should we allow hovering and focus triggering for a file input? It'd almost be good if there was some way to target the file-selector-button part but obviously can't do that with attributes.

[Westbrook]

When this gets revisited, ensuring we can support #elementinternal.role="button" or event just role="button" content would be amazing!!

If I didn't think it would take forever, I'd say this was a great place for the browser to start shipping element behaviors that custom element developers could leverage to be a more natural part of the larger web platform...

[hunterloftis]

Yes, instead of trying to predetermine the canonical list of things that may sometimes behave similarly to buttons, being able to provide a role for interoperability between things like <x-button> and popovertarget would be elegant & powerful.

[keithamus]

When this gets revisited, ensuring we can support #elementinternal.role="button" or event just role="button" content would be amazing!!

I believe the HTML spec takes an architectural hard line that aria roles and attributes should not impact HTML features, and should only be used to map to accessibility information.

[scottaohara]

correct @keithamus. ARIA is not meant to have any functional or styling impact on HTML at all. merely a way to change the way an element is exposed to the a11y tree.

that said, i do think it'd make sense for this to work on custom elements that have been properly setup via element internals. but div role=button is still just a div at its core.

[chrisdholt]

correct @keithamus. ARIA is not meant to have any functional or styling impact on HTML at all. merely a way to change the way an element is exposed to the a11y tree.

that said, i do think it'd make sense for this to work on custom elements that have been properly setup via element internals. but div role=button is still just a div at its core.

Huge +1 for custom element support via ElementInternals.

[YummyBacon5]

I think that tabindex=0 should also be supported since I've seen sites have tooltips on elements which aren't buttons.

Or if not, then abbr could have it supported instead. Since this element is meant to use the title attribute for its expanded abbreviation, however, title isn't accessible to most browsers.