Alternative HTML-only version of the `::interest-hint` feature, via command invokers

[mfreed7]

Here's a new idea (thanks @chrishtr!) to meet the same use case as ::interest-hint (see explainer and CSSWG issue):

<a href=# interestfor=popover id=link>Some link with a hovercard</a>
<button id=interest-hint commandfor=link command="toggle-interest"> (i) </button>
<div popover id=popover>The hovercard</div>

Essentially, add a command called "toggle-interest" which (when targeted at an element with interestfor) shows interest in that target element when the button is activated (and loses interest if the popover is already showing). This achieves roughly the same developer experience and capabilities as the ::interest-hint proposal, and side-steps a lot of questions such as accessibility (buttons inside buttons), focusability, arbitrary content, etc.

Because one of the use cases is to only show this extra button on touchscreen devices, here's how that would be done, in a very similar way to ::interest-hint:

#interest-hint {
  display:none;
}
@media (any-pointer: coarse) {
  /* On touch devices, show the extra button */
  #interest-hint {
    display:inline-block;
  }
}

One question is about the name: I chose "toggle-interest" here because I think tapping the button twice should lose interest. We could call it "show-interest" but it might be a little less clear that this will actually toggle. Or I guess you could only show interest, and use other things like tapping elsewhere on the page to lose interest. But it feels nice to have the button toggle, right?

Thoughts? Things you can't do with this version?

[mfreed7]

We discussed this idea, and the ::interest-hint pseudo, today at the CSSWG. The prevailing sentiment (and resolution) is that this feature belongs in HTML. So let's discuss here to get the details right.

[lukewarlow]

Ooh I really like this idea! Avoids all of the downsides that come with a CSS pseudo element. Means people can decide to show or hide this button using whatever conditionals they choose (coarse pointer being an obvious one). I guess it does also leave questions of focusability etc up to the developer so I think we should still do the heavy thinking on what good defaults should be and guide developers to that (Like this should probably be tabindex=-1 right?)

One question I have, should the commandfor point at the link or should it actually point at the interestfor target? Feels like maybe an unnecessary level of indirection to go via the link but I've not thought out the implementation too much. Be good to hear more on that.

[mfreed7]

Ooh I really like this idea! Avoids all of the downsides that come with a CSS pseudo element. Means people can decide to show or hide this button using whatever conditionals they choose (coarse pointer being an obvious one).

Glad it sounds good to you! I agree it's more flexible, and doesn't feel like significantly different (better or worse) from a DX point of view.

I guess it does also leave questions of focusability etc up to the developer so I think we should still do the heavy thinking on what good defaults should be and guide developers to that (Like this should probably be tabindex=-1 right?)

Great question for the a11y folks in the room. My knee-jerk was that it should just be a normal (focusable) button. But since it has this built-in semantic of just showing interest for the (already-focusable) interest invoker, perhaps that actually is the right thing to do. I often find myself annoyed at having to tab through the (?) icon next to form inputs and things.

I'm also curious if there are other ARIA relationships that should be set up between this invoker button and either the interest invoker or its target.

@scottaohara @smhigley in case you have opinions.

One question I have, should the commandfor point at the link or should it actually point at the interestfor target? Feels like maybe an unnecessary level of indirection to go via the link but I've not thought out the implementation too much. Be good to hear more on that.

I think it should point at the element with interestfor. That's the thing that you "show interest" in, so all of the words make sense. I.e. command=show-interest commandfor=interest-invoker makes intuitive sense to me: clicking the button "shows interest in the invoker". And it happens that that action triggers a popover, but that's a secondary effect.

[mfreed7]

As I'm implementing this, I think I want to go back to command="show-interest". For the core popover use case, clicking on the command invoker button a second time (after the first click shows interest and shows the popover) will light dismiss the popover, which will automatically lose interest in the interest invoker. And then the command invoker logic will kick in and run, finding an interest invoker without interest, and will show interest again. So practically, there's no need for toggle behavior, since popovers already nicely handle that.

Plus, command="show-interest" is a lot easier to read and understand, I think.

[brechtDR]

The reason why I would like a pseudo-element is that it could be enforced to be visible by default. The reason I mention this because I still have some concerns about touch device accessibility as described in the explainer

With the pseudo-element, we could (potentially) enforce it to be visible by default and thus be the main trigger for touch devices, which is one of those solutions in the explainer.

Then, if an author were to get rid of it (e.g, display: none), it would be an author choice (there might also be more incentive to just re-style the thing), but at least by default, the content is accessible on all devices.

Even though this does not exclude this idea, I'd rather see this as an extra possibility to replace the pseudo-element if the author wants to, instead of a default replacement of the pseudo-element idea if the latter would be the "touch-device alternative".

So +1 on the idea as a capability/enhancement here, but not as a base touch-device solution.

[mfreed7]

One last comment - I finished implementing this, and I do think we have to tie it into popover light dismiss detection, such that clicking back on the <button> in the OP does not light dismiss the popover. That's not too bad though, so maybe it's ok. And that does mean the behavior of the button is to "toggle" interest.

I'm now ambivalent between command="show-interest" and command="toggle-interest". I think I prefer "show" since it lines up with interest invoker terminology, even if it technically "toggles".

[css-meeting-bot]

The Open UI Community Group just discussed Alternative HTML-only version of the `::interest-hint` feature, via command invokers.

The full IRC log of that discussion

<gregwhitworth> masonf: this is the issue related to interest invokers proposal
<gregwhitworth> masonf: there has been a proposal for a new pseudo element primarily for touch screen usecases
<gregwhitworth> masonf: it might be nice to have a button next to the link and it will show interest in the link and thus pop up a card or similar
<gregwhitworth> masonf: rather than the browser providing one for you this works a bit better you can provide your own UI and then use command for and when it's interest it will hook it up
<gregwhitworth> masonf: benefit is that none of it is magic, it's still declarative, etc
<gregwhitworth> masonf: it side-steps some of the serious issues with the pseudo element
<gregwhitworth> masonf: you can put interest for on a button and you end up with focus issues, etc and this seems to side step them
<gregwhitworth> masonf: one of the issues with psuedo is that you could only show it with media queries which you should still be able to do this
<gregwhitworth> masonf: I do want to discuss focus, it's a button so it should focus but it would be good to possibly only have a single focus
<gregwhitworth> masonf: that's an open question I guess
<gregwhitworth> masonf: the naming is also open
<gregwhitworth> masonf: show interest and toggle interest
<gregwhitworth> masonf: I prefer toggle as that's what you're doing
<masonf> q?
<flackr> q+
<una> q+
<gregwhitworth> masonf: but show-interest better implies the task you're trying to do
<gregwhitworth> ack flackr
<gregwhitworth> flackr: if this is just a command attached to a button I think it would be odd to change its focus due to that
<gregwhitworth> masonf: no, this is a bit special though as it has two invokers on it
<gregwhitworth> masonf: two questions here
<gregwhitworth> masonf: what should the browser do and what do the developers do?
<gregwhitworth> flackr: if we were going to not have focus due to modalities you can
<gregwhitworth> flackr: do we show focus on keyboards?
<gregwhitworth> masonf: yes
<gregwhitworth> flackr: do you get in traps?
<gregwhitworth> masonf: no
<gregwhitworth> ack una
<sarah2> q+
<gregwhitworth> una: I think this is a better solution than the psuedo element and they can opt-in using coarse pointer
<gregwhitworth> una: I don't know regarding the automatic focus, but this is not something we would want the user to enter "like a button"
<gregwhitworth> una: I guess my answer regarding the focus is "I don't know" but this solution is more elegant than the pseudo and the CSSWG agreed with this proposal
<gregwhitworth> q?
<gregwhitworth> ack sarah2
<gregwhitworth> ack sarah
<gregwhitworth> sarah: apologies if this is a dumb question
<gregwhitworth> sarah: is this specific only to interest targets
<gregwhitworth> masonf: this has only been open for 24 hours, so no concern
<gregwhitworth> masonf: this is a seperate other button that points to the thing with interest-for and be able to provide an extra button to be able "tap" to show interest
<gregwhitworth> sarah: ahh, to differentiate in the action of the primary action
<gregwhitworth> sarah: there are still a11y issues with the button; it's better than psuedo
<gregwhitworth> sarah: it should have focus as ATs will expect this. Where does focus go after you click the button and have it control a button that's somewhere else especially in scenarios like "zoom"
<gregwhitworth> sarah: my hope with interest is that platforms and ATs would be able to show it without needing additional UI and affordances
<gregwhitworth> sarah: that isn't a strongly held opinion since platforms haven't done this yet
<gregwhitworth> masonf: for mouse and keyboard there are ways to show interest, a11y tech will need extra affordance
<gregwhitworth> masonf: touchscreen has the long press, this is different that gives you a bit more control
<gregwhitworth> masonf: some sites don't want a bunch of different little buttons to allow this but maybe they do. This is an opt-in
<frehner> q+
<gregwhitworth> masonf: since this is a chained invoker and it has aria-details from the command. Should this one short circuit past the middle step and go directly to the final popover?
<gregwhitworth> sarah: kind of part of it, I don't think you want ATs to see the button at all?
<gregwhitworth> sarah: that doesn't seem like it would be a good experience. It would tell me that you have two adjacent elements that are bound to the popover
<gregwhitworth> sarah: if you have screen readers have to learn a new aspect of interest but then there are ones that seem the same but have a subtle difference
<gregwhitworth> sarah: this does seem to be something that is very specific to touch, maybe we should have a universal button of some form?
<gregwhitworth> masonf: on your first comment, it seems that we should *not* put it in the accessibility tree
<flackr> q+ about removing from AT regarding touch exploration
<flackr> q+
<gregwhitworth> masonf: my one statement is that this occurs on desktop today and you'll have two tab stops
<una> q+
<gregwhitworth> frehner: one usecase we have is if you have an acronym and defining that in the tooltip if you short circut the button going to the other invoker then do you short-circut and the button has that definition but what am I actually defining here? Do you have to duplicate the content?
<una> q?
<gregwhitworth> ack frehner
<gregwhitworth> sarah: yeah, the a11y relations are related to the popup and you need the trigger and the popup
<gregwhitworth> sarah: if you should be able to invoke it from your AT you kind of only want it for touch
<gregwhitworth> una: to masonf example with the tooltip after the form field, that would just be a button with an interest invoker on it
<gregwhitworth> sarah: I've done some research on this for disabled users and you want the focus on the button to invoke the popup and you don't want to set focus on another button that shows a popup on the input
<gregwhitworth> una: +1 that this would only really be on touch events
<gregwhitworth> masonf: you only want this on touch devices?
<gregwhitworth> una: I'm just saying that you can just use interest-for affordance which is a visual affordance on touch devices
<una> q-
<gregwhitworth> flackr: just wanted to respond to sarah's thought on it not being in a11y tree which I do generally agree with
<sarah2> q+
<gregwhitworth> flackr: if you're using talk back or cursor other things and you'll want it to respond
<gregwhitworth> sarah: I actually don't think you want it to talk back or in VO via actions
<gregwhitworth> flackr: if they're not fully blind but they're not able to fully see it then you may want it
<una> q+
<gregwhitworth> sarah: if this were a CSS pseudo element it would be already in the focus
<gregwhitworth> ack flackr
<sarah2> ack me
<gregwhitworth> ack sarah
<gregwhitworth> una: add a little cons of the psuedo element
<gregwhitworth> una: people want interactive icons
<gregwhitworth> una: there's only so much you can do with a psuedo element
<gregwhitworth> una: it's definately limited
<keithamus> q+
<gregwhitworth> ack una
<gregwhitworth> ack keithamus
<gregwhitworth> masonf: what if all of these are still capabilities and they can make them visible for non-coarse and the equivalent of tabindex=-1 but we provide the good behavior by default
<una> q+
<gregwhitworth> masonf: maybe remove it from the a11y tree
<gregwhitworth> masonf: is that a good solution?
<gregwhitworth> sarah: would you automatically remove the button with this value except for touch devices?
<gregwhitworth> sarah: there are touch enabled computers
<gregwhitworth> keithamus: touch enable computers there are MS surface that is course pointer
<gregwhitworth> keithamus: a conclusion I get from this is that this is better than the pseudo element and it's a low level primitive
<gregwhitworth> keithamus: that we can confidently come up with an answer to some of these questions the developers would have the same questions
<gregwhitworth> keithamus: I worry a little bit, it's not a solution in a box but a primitive on how to make it work
<gregwhitworth> q?
<Bret> it's easy to mis-wire it
<sarah2> q+
<gregwhitworth> keithamus: the button is better than a pseudo and it makes me wonder if we should solve this. Or maybe we do and something comes up in the web
<gregwhitworth> masonf: I don't want to ship the bare bones MVP and do a default Good
<gregwhitworth> ack una
<gregwhitworth> una: I find the idea of default styles interesting, I have a few questions. Developers may have expectations of "where is this button that I just added"
<gregwhitworth> una: is there a way to show/hint that it's available on touch devices
<gregwhitworth> una: are there other UA styles that have these types of conditionals
<gregwhitworth> una: I'm seeing people head shake "no" which will be odd
<gregwhitworth> una: can you have a coarse or fine pointers on the same device
<gregwhitworth> flackr: coarse means that you have any device applied that is coarse
<gregwhitworth> masonf: even if you use a device that supports both; I think we would still show it
<gregwhitworth> masonf: there are no existing styles that do this
<gregwhitworth> masonf: the discussion we had around media queries for the select and we wouldn't include them
<gregwhitworth> q?
<gregwhitworth> flackr: there is a primary pointer in the media query
<gregwhitworth> una: we should have some defaults and maybe the media queries can get added by the dev
<masonf> https://github.com/w3c/csswg-drafts/issues/12437
<gregwhitworth> sarah: can we get the list of issues with the pseudo elements for review
<gregwhitworth> sarah: we shouldn't push these discussions on to the developers
<gregwhitworth> sarah: this could go on a new value for interest-for and would only show up on coarse pointer by default
<gregwhitworth> masonf: oh, an actual new element
<Bret> that feels more semantic, even if more complex
<gregwhitworth> sarah: yeah, similar to <selected-value>
<gregwhitworth> Bret: if you're just thinking of someone that's new to this and doing this wiring up and I'm not sure why I'm doing it while there is an element that is semantic for why it's there
<frehner> gregwhitworth: Dominic said we shouldn't be too scared to introduce a new element.
<masonf> q+
<frehner> gregwhitworth: With UI toolkits, it's somewhat common to have another element that wires things up for you for these cases
<sarah2> ack me
<gregwhitworth> ack sarah
<gregwhitworth> ack masonf
<sarah2> q+
<Bret> button of new type?
<gregwhitworth> masonf: this is a button, and it's going to be hard to name this as the WHATWG was generally opposed to something that seems like a button
<una> (remember: they wouldnt even let us do a new selectmenu element)
<gregwhitworth> sarah: it's not a BUTTON!!!!!!!
<gregwhitworth> sarah: this reads to me like the X at the end of an input that clear the input
<Bret> that feels pseudo
<gregwhitworth> sarah: you can't click that with a screen reader and delete them their own way
<keithamus> q+
<gregwhitworth> sarah: it's conditionally rendered and I think you don't want it to be the accessibiltiy tree
<gregwhitworth> ack sarah
<Bret> q+
<gregwhitworth> masonf: the CSSWG has a lot of this content in there, you're saying it should look like a button but it isn't a button
<una> q+
<gregwhitworth> sarah: this is a touch affordance as touch users specifically don't have an affordance to show interest and not something you want in all scenarios
<gregwhitworth> masonf: that is definately the primary use case, there may be a few but they may not be good ones
<gregwhitworth> sarah: non AT screen-reader touch screen
<gregwhitworth> masonf: if it's on a touch screen would you want to paint on it?
<gregwhitworth> sarah: it should say "has actions" and I would expect that to occur
<gregwhitworth> ack keithamus
<gregwhitworth> keithamus: I think Sarah is getting close to something; if it's like an input affordance then maybe it's a psuedo element
<gregwhitworth> q+
<gregwhitworth> ack Bret
<gregwhitworth> Bret: what if we think about this a bit inversely that we have clickable/focusable elements that you don't want in the accessibility tree that aren't a button
<gregwhitworth> sarah: the X thing is what we've done at the end of the input
<gregwhitworth> Bret: so is that the solution then?
<frehner> masonf: with popovers you do still need to wait for a second. longpress you also don't know what it'll be until you try it
<frehner> masonf: all apps all over, even browsers, don't really have much discoverability here either. it's generally through trying it out
<una> q+
<frehner> gregwhitworth: passwordreveal "i" thing: the moment we tested this on e.g. amazon, it just didn't work once you got past the basic usecase
<frehner> ... maybe the pseudo element meets 70% usecases, but if browsers don't implement or if the 30% have to reimplement, then it's bad
<sarah2> q+
<frehner> ... we're doing that with styling pseudos in css-forms, and it covers 90%. but I don't see a silver bullet
<Bret> "my new element" 😬
<gregwhitworth> ack gregwhitworth
<frehner> una: with carousel, scroll-marker, the new way has so much more control. pseudos just aren't enough by default.
<frehner> flackr: there's also the "do both" approach
<frehner> una: could do that. both the pseudo and the higher-capacity thing that allows more customization
<frehner> masonf: we're finding accessibility issues with both, so maybe this doesn't work anyway with either
<Bret> q+
<frehner> sarah2: show/hide password example, not going to share an opinion on the 70% use-case, but in the case of greater customization with a button going directly may be ok
<Bret> button or span
<frehner> masonf: is that the solution? use the new command invoker to point to the tooltip?
<frehner> sarah2: but I don't want that to be the default
<frehner> ... could also show pseudo by default
<masonf> ack una
<sarah2> ack me
<masonf> ack sarah
<masonf> ack Bret
<sarah2> (showing a pseudo by default wasn't an entirely serious suggestion :D)
<frehner> Bret: simplist: use a span to avoid the accessibility tree. otherwise a button
<frehner> ... that doesn't hide thing out of the box on desktop
<sarah2> q+
<frehner> masonf: can't use these declarative attributes on the span
<frehner> sarah2: I see a war between devs doing shitty things and we're like "there's one valid use-case!"
<gregwhitworth> Zakim, end meeting

[mfreed7]

Alright, we had a good long discussion of this proposal. Here's what I heard:

• We really want a non-focusable, non-actual-button for this (i) icon thing. The actual interest invoker is already accessible (via AT, keyboard, mouse) and this is primarily (perhaps only?) useful for touchscreen users.
• So the ideal situation is that the (i) button isn't really a button, and instead it acts like <span onclick=showInterest()>. It just looks like a button to sighted users.
• It shouldn't be in the a11y tree. It shouldn't be focusable (on its own).
• We shouldn't/can't include the media query in the UA stylesheet, because that confuses developers. So this (still) needs to be a developer opt-in.
• There was talk of a new HTML element for this purpose, something like <interesthintbutton>, which would presumably be (only?) placed as a child of the element with interestfor. So something like this I guess: <button interestfor=foo>Button text goes here <interesthintbutton><svg>some logo</svg></interesthintbutton></button>. And then that would only get rendered (I guess?) on touchscreens? And it wouldn't really be a button, but would just be a pointer-clickable thing that looks like a button. I.e. not keyboard focusable and not in the a11y tree. I'm wary of the complexity of this solution for what seems like a smaller problem. And I'm guessing a huge pushback will be: what happens if you put that outside an interest invoker, on its own?

My tentative conclusion is that perhaps the ::interest-hint pseudo element really might have been the better solution. This discussion cleared up a bunch of the questions, e.g. how to make it focusable. One downside that was discussed today is that it isn't fully stylable, since it can't contain arbitrary content. But perhaps it covers the 80% use case, and we can invent something to cover the other 20% later, once we learn what's in the 20%?

Thoughts?

For the pseudo element, these are the (still) open questions:

• it needs a good name (always). Current ideas are ::interest-hint and ::interest-button.
• is there a more general feature here, that works for things other than interest invokers? I'm not sure what that would be, but it was brought up in the CSSWG discussion.
• Where does it live in the layout tree, relative to e.g. ::after and others? Feels like it belongs just before the ::after pseudo element.