[Invokers] InterestTarget support on more elements

[lukewarlow]

Based on https://developer.mozilla.org/en-US/docs/Web/HTML/Content_categories#interactive_content there's a few elements left that are defined as interactive but aren't currently noted as supported for interest events.

<embed> and <object> I think can be disregarded. <img> is handled by virtue of the fact <area> is supported.

But <label> and <iframe> particularly I think are interesting.

<label> isn't on its own focusable but I could maybe see people wanting hover tooltips for it, To extend the target area compared to just putting it on say an checkbox input.

Just raising this issue to see if there's anything else missing to add to ensure the spec is complete.

[lukewarlow]

<label> especially could be useful for elements such as <meter> which aren't interactive so can't be used currently. But then you get the same issue that it wouldn't be keyboard navigable?

[keithamus]

Given the current set of tags requires InterestMixin to be defined on HTMLElement, we could instead use some heuristics for when interestTargetElement applies; for example it could simply return null on an element which cannot receive focus - so all the existing elements plus anything with a tabindex attribute other than -1 would apply. That, however, might be a little too broad. Thoughts?

[lukewarlow]

If we could work out the accessibility semantics of interest. It's possible that we could do 1 of 2 things, either automagically make the element with interesttarget attribute fully accessible apply tabindex etc OR we could require that the element have all those things manually applied (or be one of the existing interactive elements).

I'm guessing it would be more than just tabindex required but I'm certainly no accessiblity expert so potentially Scott could provide some guidance on that front. POtentially something to bring up in an Open UI meeting?

[lukewarlow]

#815 FWIW in the discussion we had in that issue it was deemed anchor would be fine but we can see people wanting other elements, so I think the more broad support we can have while also being accessible is good.

[lukewarlow]

One thought for the <label> case is that if it's wired to an element using for or the element is within it, we should maybe special case it.

So I'm thinking the interesttarget would still be on the input/select/textarea/etc

If the label is correctly linked to the above elements it's special cased in implementations (and spec) so hovering it and long pressing it counts as interest? That way you avoid the need to declare things twice, you also avoid the issues with label not being focusable.

That doesn't solve for <meter> and <progress> but if we allowed interesttarget on elements with tabindex="0" then that should also solve it for them too.

[keithamus]

I do like the idea that adding interesttarget on an element makes it part of the focus flow, a sort of implicit tabindex=0.

Going to /cc @scottaohara on this topic.

[lukewarlow]

I've also requested to add it to tomorrows Open UI agenda to see if the group in general has any other thoughts on it

[scottaohara]

short version: this is a thorny topic and while i think there are some use cases where extending to other elements could help improve developers create better user experiences, doing so also has the high risk of making it a lot easier for design/development to create "valid HTML" anti-patterns that would degrade the UX for anyone who needs to use more than a mouse to interact with web pages.

i'm going to think more on this for the larger group discussion. But I'm of the opinion we shouldn't be in a rush to extend support to any/all elements because of a perceived need - which may be a knee-jerk reaction to other existing alternatives / potential pathways forward.

:: deletes/saves all the additional stuff I wrote because I started this comment with 'short version' and i'm barely keeping true to that statement as it is ::

[lukewarlow]

@keithamus would you be willing and interested to bring work on this invoker and interest proposal into OpenUI?

It seems a perfect candidate for something to discuss specifics inside Open UI before eventually moving into WhatWG.

if you've not already joined here's the discord: https://discord.gg/6WZzVZrg

[keithamus]

@scottaohara it's always a delightful education reading your comments to please don't hold back 😄

This is an area I feel where we need to get the balance right. I feel strongly about invokertarget only being on buttons but I can see usecases for interesttarget on many more.

@lukewarlow yes I'm somewhat involved in openui, I'll attend todays meeting and we can discuss this.

[keithamus]

Another consideration here is the interaction with custom elements. If we have a fixed list of tags this can apply to, how do web authors integrate this into their custom elements? We have the usual routines of setting something in elementInternals() or otherwise delegating to an element in the shadowdom but then we're also stepping into the as-yet-unsolved realm of cross-shadowroot idrefs.

Having a heuristic which could also apply to custom elements may alleviate some of the complexity there.

[lukewarlow]

Ooh that's a very good point. I feel like we would need some sort of backdoor to allow this to work with web components because afaik cross root idref isn't a thing yet.

That could be as simple as we allow X elements along with any custom elements? But potentially we need a heuristic more than that

[scottaohara]

@keithamus @lukewarlow - if either of you are free to hop on a call tomorrow I'd be very glad to elongate on my 'no' (which was more to be 'funny' than being entirely accurate to my thoughts on the matter). or we can wait till next thursday. i just don't have it in me to write a blog post in a comment at this time, when we could probably get to the point a lot quicker with a chat (of indeterminate length but still probably way quicker than it takes me to write).

[lukewarlow]

I'm not free until next week sometime unfortunately. Happy to wait till next Thursday or you chat with Keith and put a TLDR on here.

Fwiw if the answer is a flat no that's absolutely fine with me.

The label bit specifically would be interesting to get your thoughts on.

As would the meter and progress. But again the answer might just be to put a tooltip Button in the label and that's also fine.

[lukewarlow]

One thing that might be worth considering is splitting the invoke and interest into separate proposals or at least marking interest as a follow up, because while the defaults still need discussion invoke seems a lot less contentious. So it'd be nice to get invoke without delaying it for the exacts of interest?

[keithamus]

That’s definitely the plan. This proposal can continue to exist in this form while shipping the small slices

[scottaohara]

the label bit (specifically making it focusable) is the biggest no. auto-making things focusable with this would lead to various issues, least of which is inserting things into the keyboard focus order that one would not generally expect to be in the focus order (and unless browsers would be willing to create an opt out for this, ugh... that could get really annoying/problematic for someone who needs to keyboard navigate through a page)

a lot of the underlying 'need' for things like this (show more information on hover) unfortunately stems from not particularly-inclusive design patterns. re: the above/some stuff covered on the call today, making things "focusable" doesn't necessarily make them 'accessible'. opinions aside on apple's decision to make only certain elements tabbable by default (because they're still focusable - not tabbable, that's an important difference), it is based in good intentions - reduce blockers to access important content but still allow access to that 'less important' content (if i recall correctly, hold option + tab and hey, now you can get to all that stuff).

so that all sorta circles back around to what i was saying in the meeting today. do we really need to make it easy to make problematic UI by extending an attribute onto everything (tabindex=0 can go on everything - which is in and of itself a decision that was made and we're now stuck with for better and worse, so this is essentially saying "what if we allow this on everything") or is something people can do with JS and we take a slower approach with extending the attributes to other elements - if at all. cause maybe what people need is full fledged elements, rather than partial behaviors of an element that they then need to still do a bunch of work to make fully usable - but probably stop short cause lol now i can hover my div and get a styled popup :)

so... still not really digging into everything, but looks like i was able to write something kind of succinct here. good on me for not completely drowning you with boring words.

[lukewarlow]

Ah yeah to clarify on the label front rather than make it focusable, have some sort of speccing so that if an element on hover, on long press etc dispatched an interest signal then a corresponding label would aswell to increase the target region effectively.

Your points though make perfect sense.

Its all about getting this right so on my part feel free to write away! Always good to learn

[scottaohara]

yah, i do want to acknowledge i did see where the topic of the label/form field went. there might be something to that and having the browser extend the hover are to the associated label from the form field. So, again, not digging into it all - there are some good things to consider here. i think my primary concerns are at least mentioned at a high level now.

[tomByrer]

I'm interested in adding invokers for checkboxes & radio inputs; with some CSS you could have a working video UI for example.

[keithamus]

@tomByrer could you elaborate on your example? From the issue you referenced:

<input type="checkbox" invoketarget="my-video" invokeaction="playpause" >Play/Pause</button>
<input type="checkbox" invoketarget="my-video" invokeaction="mute">Mute</button>

<video id="my-video"></video>

This would not be possible as checkboxes already have an intrinsic behaviour, these would need to be buttons.

[lukewarlow]

See #857 for a request for interest support on abbr elements.

[scottaohara]

abbr is a bit of a weird one and i would submit is no more important in rushing a solution than allowing interest targets on span elements.

[bkardell]

Not sure I would agree it is weird, but I do agree that we shouldn't rush a solution and that the other characteristics are approximately like span anyway.

[scottaohara]

@bkardell not sure why you wouldn't agree, tbh. abbr[title] have their own special semantics that are different than just a normal "tooltip" (the visual treatment being the same is yet another example of how 'tooltip' is a bastardized term for "small(ish) popup of content that could represent a variety of different semantics)"

swapping that element/attribute pairing out with another attribute would provide someone with a similar visual treatment, but wouldn't produce the same semantic connection / a11y api exposure. Unless there was to be another one-off 'special semantics' treatment for these popover/interesttarget attributes specifically with abbr - and one-off special behaviors is weird. or at least, so i assumed?

[lukewarlow]

Continue this discussion in #839