Meeting minutes
github-bot, take up openui/
Alternative HTML-only version of the `::interest-hint` feature, via command invokers
<github-bot> OK, I'll post this discussion to https://
masonf: this is the issue related to interest invokers proposal
masonf: there has been a proposal for a new pseudo element primarily for touch screen usecases
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
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
masonf: benefit is that none of it is magic, it's still declarative, etc
masonf: it side-steps some of the serious issues with the pseudo element
masonf: you can put interest for on a button and you end up with focus issues, etc and this seems to side step them
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
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
masonf: that's an open question I guess
masonf: the naming is also open
masonf: show interest and toggle interest
masonf: I prefer toggle as that's what you're doing
masonf: but show-interest better implies the task you're trying to do
flackr: if this is just a command attached to a button I think it would be odd to change its focus due to that
masonf: no, this is a bit special though as it has two invokers on it
masonf: two questions here
masonf: what should the browser do and what do the developers do?
flackr: if we were going to not have focus due to modalities you can
flackr: do we show focus on keyboards?
masonf: yes
flackr: do you get in traps?
masonf: no
una: I think this is a better solution than the psuedo element and they can opt-in using coarse pointer
una: I don't know regarding the automatic focus, but this is not something we would want the user to enter "like a button"
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
sarah: apologies if this is a dumb question
sarah: is this specific only to interest targets
masonf: this has only been open for 24 hours, so no concern
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
sarah: ahh, to differentiate in the action of the primary action
sarah: there are still a11y issues with the button; it's better than psuedo
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"
sarah: my hope with interest is that platforms and ATs would be able to show it without needing additional UI and affordances
sarah: that isn't a strongly held opinion since platforms haven't done this yet
masonf: for mouse and keyboard there are ways to show interest, a11y tech will need extra affordance
masonf: touchscreen has the long press, this is different that gives you a bit more control
masonf: some sites don't want a bunch of different little buttons to allow this but maybe they do. This is an opt-in
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?
sarah: kind of part of it, I don't think you want ATs to see the button at all?
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
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
sarah: this does seem to be something that is very specific to touch, maybe we should have a universal button of some form?
masonf: on your first comment, it seems that we should *not* put it in the accessibility tree
masonf: my one statement is that this occurs on desktop today and you'll have two tab stops
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?
sarah: yeah, the a11y relations are related to the popup and you need the trigger and the popup
sarah: if you should be able to invoke it from your AT you kind of only want it for touch
una: to masonf example with the tooltip after the form field, that would just be a button with an interest invoker on it
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
una: +1 that this would only really be on touch events
masonf: you only want this on touch devices?
una: I'm just saying that you can just use interest-for affordance which is a visual affordance on touch devices
flackr: just wanted to respond to sarah's thought on it not being in a11y tree which I do generally agree with
flackr: if you're using talk back or cursor other things and you'll want it to respond
sarah: I actually don't think you want it to talk back or in VO via actions
flackr: if they're not fully blind but they're not able to fully see it then you may want it
sarah: if this were a CSS pseudo element it would be already in the focus
una: add a little cons of the psuedo element
una: people want interactive icons
una: there's only so much you can do with a psuedo element
una: it's definately limited
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
masonf: maybe remove it from the a11y tree
masonf: is that a good solution?
sarah: would you automatically remove the button with this value except for touch devices?
sarah: there are touch enabled computers
keithamus: touch enable computers there are MS surface that is course pointer
keithamus: a conclusion I get from this is that this is better than the pseudo element and it's a low level primitive
keithamus: that we can confidently come up with an answer to some of these questions the developers would have the same questions
keithamus: I worry a little bit, it's not a solution in a box but a primitive on how to make it work
<Bret> it's easy to mis-wire it
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
masonf: I don't want to ship the bare bones MVP and do a default Good
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"
una: is there a way to show/hint that it's available on touch devices
una: are there other UA styles that have these types of conditionals
una: I'm seeing people head shake "no" which will be odd
una: can you have a coarse or fine pointers on the same device
flackr: coarse means that you have any device applied that is coarse
masonf: even if you use a device that supports both; I think we would still show it
masonf: there are no existing styles that do this
masonf: the discussion we had around media queries for the select and we wouldn't include them
flackr: there is a primary pointer in the media query
una: we should have some defaults and maybe the media queries can get added by the dev
<masonf> w3c/
sarah: can we get the list of issues with the pseudo elements for review
sarah: we shouldn't push these discussions on to the developers
sarah: this could go on a new value for interest-for and would only show up on coarse pointer by default
masonf: oh, an actual new element
<Bret> that feels more semantic, even if more complex
sarah: yeah, similar to <selected-value>
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.
<frehner> gregwhitworth: With UI toolkits, it's somewhat common to have another element that wires things up for you for these cases
<Bret> button of new type?
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)
sarah: it's not a BUTTON!!!!!!!
sarah: this reads to me like the X at the end of an input that clear the input
<Bret> that feels pseudo
sarah: you can't click that with a screen reader and delete them their own way
sarah: it's conditionally rendered and I think you don't want it to be the accessibiltiy tree
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
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
masonf: that is definately the primary use case, there may be a few but they may not be good ones
sarah: non AT screen-reader touch screen
masonf: if it's on a touch screen would you want to paint on it?
sarah: it should say "has actions" and I would expect that to occur
keithamus: I think Sarah is getting close to something; if it's like an input affordance then maybe it's a psuedo element
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
sarah: the X thing is what we've done at the end of the input
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
<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
<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" 😬
<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
<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
<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
<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!"