[Popup] Triggering element support: buttons, text inputs, etc.

[zcorpan]

Similar to #409

https://open-ui.org/components/popup#the-popup-attribute

The popup attribute is supported on a subset of interactive elements:

(buttons...)
input in the email, number, search, tel, text, or url states

Is the omission of the Password state intentional?

[gregwhitworth]

@mfreed7 @melanierichards ^

[mfreed7]

I don't think the omission of password was intentional - I think the idea was to support any of the text-like inputs.

I'm still not 100% sure which action (focusing the control?) triggers the popup, in all of these cases.

[mfreed7]

I think this really is a general question: should the (now) togglepopup attribute be supported at all on text based inputs? I think the <button> use case is fairly clear and common - buttons trigger things. The use case for an <input> that triggers a popup via a default action like focusing it is much less clear to me. One example that comes to mind is a combobox, where there's a text field at the top, and a keyboard action such as the down-arrow triggering a listbox popup. However, is it common (i.e. the majority use case) that simply clicking in the combobox triggers the popup?

Perhaps the declarative triggering capability should be limited, for now at least, to just <button> (and equiv), until the use case emerges for other element types? This is something that would seem to be easily augmentable later.

[scottaohara]

@mfreed7 I was actually thinking about this yesterday, specifically because of the discussion around togglepopup.

A typeahead combobox (text field with a listbox popup) is rather common, and unfortunately often not built to work properly with assistive technologies. With native HTML the datalist element and list attribute on text fields allows for people to create this now, but similar to select, the listbox popup is not styleable

<label for=n>example</label>
<input id=n list=foo>
<datalist id=foo>
  <option>...</option>
  ...
</datalist>

Some date pickers work similarly, where the calendar picker pops up, but like with the type ahead combobox, focus remains in the text field. Typing into these text fields, or specifically pressing down arrow is the way to 'open' these popups. Esc or selection of an option being the way to close them (or dismissal by blurring the text field).

Would such a popup be covered by the default behavior? Or would this need another popup=newValue?

---

But more specifically to your question, do we need togglepopup on text inputs... I wonder if you're right and that should be limited to buttons, and maybe a different mechanism is used for popups for text fields – e.g., possibly reusing/expanding the list attribute?

Similarly, togglepopup is probably also not the right mechanism for invoking a "tooltip" / hint popup, nor a "toast". The former may need a new attribute similar to list, as tooltips should appear on hover/focus. The later may not need an attribute at all? But rather be tied to validation of forms, or specifically invoked with JavaScript tied to specific conditions that would require a 'toast' popup to be displayed.

[gregwhitworth]

@scottaohara this is a good usecase. I'd also note that a tooltip is normally a type of popup that wouldn't necessarily require an invocation like a button but possibly a mouseover for example. Granted from an AT perspective, it should be a focusable element so that they can invoke it via other methods so maybe a button still does make sense?

But I do agree that text input definitely needs to apply to text inputs. As a slight aside, @dandclark I think we should probably look somewhat into combobox as the focus scenarios also differ which will require thought and vary drastically to the current built in select.

[scottaohara]

Re: tooltip, you could very well have a button or combobox that has a tooltip and another popup associated with it.

[mfreed7]

Would such a popup be covered by the default behavior? Or would this need another popup=newValue?

I think it’s important to point out that there are two different behaviors here, controlled by two different attributes:

• popup=popup on the thing that pops up.
• togglepopup=id on the triggering element

In this issue, we’re only really talking about the second one, the triggering element. For that, as you rightly pointed out, a single trigger button could have both a popup (e.g. picker) and a tooltip.

Generally, I think more work would be needed to support a declarative trigger for tooltips. I’d like to make sure we nail down the behavior for the “general” declarative click trigger, triggerpopup. And then we can apply that learning to the tooltip declarative attribute. Does that sound reasonable?

For that, you pointed out that the “trigger” keystroke for a combo box is typically the down arrow. Do you think that’s a good general-purpose default for any text input that triggers a popup? If so, that would sound like what we should do for <input triggerpopup=id>. If not, then I don’t think we should support <input triggerpopup=id>. WDYT?

[scottaohara]

to expand on my previous 'thumbs up', i think focusing on one aspect at a time makes sense.

and to clarify further, yes pressing down arrow seems reasonable to me as a default expectation here, with the caveat that other platforms, like mobile, would have different expectations (if a blue tooth keyboard were not used) that we could discuss later as well.

[mfreed7]

Ok, here's a proposal, which includes the resolutions and discussion on #409.

For the element on the left, if it contains togglepopup, showpopup, or hidepopup, here are the methods for activation, and which attributes are supported:

Element	Supported Actions	Popup activation
<button>	toggle,show,hide	Button click (if button wouldn't otherwise submit a form)
<button type=[button|submit|reset]>	toggle,show,hide	Button click (if button wouldn't otherwise submit a form)
<input type=[button|submit|reset|image]>	toggle,show,hide	Button click (if button wouldn't otherwise submit a form)
<input type=[text|email|password|search|tel|url]>	show only	Activated by down arrow only
<input type={anything else}> (Include date/time, checkbox, file, etc.)	None	Not supported for popup activation

The mobile/non-keyboard activation question for text inputs still remains.

[mfreed7]

yes pressing down arrow seems reasonable to me as a default expectation here, with the caveat that other platforms, like mobile, would have different expectations (if a blue tooth keyboard were not used) that we could discuss later as well.

One question came up in the code review for this change (thanks @dbaron): is down-arrow still/always the right activation button when the control is in a vertical writing mode?

[scottaohara]

made a quick demo to check, and if an input is set to writing-mode: vertical-lr;, then the keys get swapped so left/right arrows open the listbox popup.... well in firefox. other browsers don't support.

however, if using with a select element, the keys don't change so up/down arrow (on macos) still open the listbox popup.

so... :: giant everlasting shrug emoji ::

[mfreed7]

made a quick demo to check, and if an input is set to writing-mode: vertical-lr;, then the keys get swapped so left/right arrows open the listbox popup.... well in firefox. other browsers don't support.

however, if using with a select element, the keys don't change so up/down arrow (on macos) still open the listbox popup.

so... :: giant everlasting shrug emoji ::

Thanks for the test page. So on Chromium, down-arrow is always the trigger, at least on Mac. Right? From an accessibility point of view, it would seem (naively to me at least) that having one consistent activation key would be the best, since the writing mode doesn't matter and isn't announced (right?) for AT users. But perhaps I'm missing a nuance. Would you agree @scottaohara?

[scottaohara]

on mac, yes.

on windows chromium down/up arrow are always the triggers for the type ahead combobox. up/down arrows cycle through the options for the collapsed <select> element, and alt + down/up arrow open the listbox popup. I realize we might want to just make everything behave the same with the new element, so only mentioning current behavior for the sake of completeness.

interestingly, on windows with firefox, and without a screen reader active, i need to press the ctrl key along with the left/right arrows. using the arrows alone won't show the listbox popup for the type ahead text field

but, chromium also doesn't support the writing mode CSS, so not sure it's a good comparison for what -should- happen here.

IMO, the change in arrow key behavior makes sense if the language of the page/form control is representative of a language where someone would expect to enter text in a vertical manner like this. CSS alone changing the behavior is an odd choice, as something that could be done for purely presentational purposes is resulting in a change in UX, and yes, there is no programmatic exposure of "this behaves differently".

sorry... tldr; i don't presently think it makes sense to swap keys especially based on only one browser implementing this feature and it being questionable if the changing in behavior via css alone is really the right choice to be making.

happy for someone to change my mind on that, so we'll see what others think per your agenda+ label

[css-meeting-bot]

The Open UI Community Group just discussed [Popup] popup attribute not supported on <input type=password> #420, and agreed to the following:

• RESOLVED: for invoking attributes that point to `popup=auto` popups, we should support the list of elements in this comment: https://github.com/openui/open-ui/issues/420#issuecomment-1135019013

The full IRC log of that discussion

<hdv> Topic: [Popup] popup attribute not supported on <input type=password> #420
<hdv> github: https://github.com//issues/420
<hdv> chair: hdv
<JonathanNeal> masonf: this issue is about the invoking attributes (toggle popup, show popup, etc), and when you do that, it allows that element to trigger a popup somewhere else in the dom
<JonathanNeal> masonf: this issue is about what elements can we use this on, and what happens when one uses it.
<JonathanNeal> masonf: you can use all 3 attributes on a button (toggle, show, hide) as long as that button would not submit a form. essentially, you can show a popup from an input. this is like the combobox behavior
<hdv> q?
<bkardell_> q+
<JonathanNeal> masonf: question is should the down arrow activate this? my opinion is yes.
<hdv> ack bk
<JonathanNeal> bkardell_: how would this work without a keyboard?
<flackr> q+
<JonathanNeal> bkardell_: on some sites, for example, the text that winds up in a page as the description of the requirements of the field — some people choose to show those as a popup.
<JonathanNeal> bkardell_: it would seem bad if the use case where someone was using a touch device would not be good.
<hdv> ack flackr
<JonathanNeal> masonf: I agree that this needs more definition for what happens for keyboard, mouse, touch, and what ever.
<JonathanNeal> flackr: for touch devices, there should be ways to activate these things. there ought to be some trigger that is either implicit or somehow related to interacting with the element.
<bkardell_> s/I agree that this needs more definition/There is some nuance here, that sounds more like popup=hint use case - but I agree that this needs more definition f
<JonathanNeal> masonf: the touch case is tricky. imagine you have an input box where tapping on it gives you a keyboard or gives you the options
<JonathanNeal> flackr: or expect to do both
<JonathanNeal> masonf: maybe a good model for this would be how inputs handle this with a datalist
<JonathanNeal> bkardell_: on a combo-box we had the main text field, and then we have some icon button that is internally attached to the text field that lets you pick if you want to pick.
<hdv> q?
<JonathanNeal> masonf: I believe mobile chromium does not let you type the text in, but instead you get the picker.
<JonathanNeal> masonf: I think it would be best if folks put their recommendations in the issue. I would like to get agreement on which kinds of (input/button) elements support the keyboard functionality.
<JonathanNeal> flackr: and hints would be activated with another mechanism?
<JonathanNeal> flackr then makes a very good point that the scribe fails to capture
<JonathanNeal> q+
<hdv> ack JonathanNeal
<masonf> Proposed resolution: for invoking attributes that point to `popup=auto` popups, we should support the list of elements in this comment: https://github.com//issues/420#issuecomment-1135019013
<JonathanNeal> the good point by flackr was effectively this resolution ☝️
<flackr> +1
<JonathanNeal> +1
<dandclark> +1
<masonf> RESOLVED: for invoking attributes that point to `popup=auto` popups, we should support the list of elements in this comment: https://github.com//issues/420#issuecomment-1135019013
<JonathanNeal> masonf: please go take a look at the issue and put what you think the behavior should be for non-keyboard issues. we could really use some help.
<JonathanNeal> masonf: and if anyone wants to share it on twitter, that would be lovely.

[mfreed7]

Ok, so the resolution above is somewhat limited, and just says that we agree that invoking attributes (togglepopup,showpopup,hidepopup) should be usable on buttons that don't submit forms, and text-only inputs. It also makes clear that we're talking about popup=auto, and not popup=hint, which has a different expectation.

The key missing detail from my comment above, in addition to the question about vertical writing modes, is what should the non-keyboard interaction pattern look like for text-based inputs? In the button case, I think it's fairly straightforward, and includes all of the existing ways that a button can be activated. For text inputs, it becomes less clear what a mouse or touch user expects. An example use case is a custom date picker implementation using a text input to display the date, but that supports opening a popup picker with the down-arrow. How should a mouse/touch user expect to open the picker?

Suggestions very much appreciated.

[hidde]

For text inputs, it becomes less clear what a mouse or touch user expects. An example use case is a custom date picker implementation using a text input to display the date, but that supports opening a popup picker with the down-arrow. How should a mouse/touch user expect to open the picker?

What if in this case user agents display an icon in the text input, like a down arrow or “kebab” icon, that does two things:

• indicates there is something that user can trigger to pop out with down arrow key
• can be clicked by mouse users / touched by touch users to open the associated popup

The icon could have a sensible default, like an arrow, that would work for any popup content, which could be replaced by authors to be more specific, like a calender icon or a password suggestion picker.

[scottaohara]

just noticing:

(togglepopup,showpopup,hidepopup) should be usable on buttons that don't submit forms, and text-only inputs

how would hidepopup work on a text input? or is this to imply that the popup could contain a control that has this attribute on it?

@hidde a text input with a list attribute that points to a proper datalist element is already rendering a down arrow with Chromium and Webkit browsers. Firefox isn't doing this, but they should. Seems to me it's probably a good idea to render an "open" icon button of some sort. The open icon could be exposed as a button and could be reachable by pointer/swiping with AT on touch devices. Arguably it should not be in the tab order (chromium has it's date picker buttons in the tab order, meaning someone has to hit tab at least 2x to get past one of those - even after they've already entered the date via the text input portions of the control).

Probably need a stipulation for how to handle a situation for an author using both a list attribute to open a datalist popup, as well as their own custom popup on a text field. It's super annoying that the browser default autocompletion usually gets in the way of author defined datalist popups... we don't also want author defined popups getting in the way of author defined popups which could then be obscured by autocomplete popups....

[css-meeting-bot]

The Open UI Community Group just discussed [Popup] popup attribute not supported on <input type=password>, and agreed to the following:

• RESOLVED: only support invoking attributes on buttons (as described in the issue).

The full IRC log of that discussion

<gregwhitworth> Topic: [Popup] popup attribute not supported on <input type=password>
<gregwhitworth> github: https://github.com//issues/420
<hdv> masonf: this one is more of a discussion… we support these attributes on text inputs. For buttons, when you click it, the popup gets invoked. For text inputs though, that's a bit more tricky, especially when it comes to how that would work for keyboard, mouse and touch users
<gregwhitworth> q+
<hdv> masonf: eg you probably don't want it to just always show
<hdv> masonf: the only suggestion in the issue currently would be to show an icon that could be clicked/touched by mouse/touch users
<bkardell_> q+
<hdv> gregwhitworth: I don't know if any of you use Edge, but they do auto invoke a popup, so that would be a use case
<scotto_> q+
<hdv> gregwhitworth: not necessarily a combobox, but I have seen it often, that the combobox doesn't require you to type in any text in order to already see suggestions
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack bkardell_
<hdv> bkardell_: I was going to mention the same thing as Greg but from the opposite angle… UAs are not really entirely consistent on some of this, but some of them do provide some kind of popup that might include a combobox-like thing
<hdv> bkardell_: so you get a key icon or something to select a password
<hdv> bkardell_: if we add this, does that end up conflicting with what things are doing now?
<hdv> masonf: I think you're asking if you have an input that has a datalist, you get an indication… what do we do when there's both… is that your question?
<hdv> bkardell_: my browsers remember past inputs, for example, or recognise a password field and give me a combobox kind of thing that I can click
<hdv> bkardell_: that is basically the same problem… but I think what Greg was saying is that browsers could use this tech to implement is
<gregwhitworth> q+
<hdv> bkardell_: so my question is… ok but it already exists, so how would we deal with conflicts here?
<hdv> masonf: autocomplete or autofill or anything the browser does for you… that's an issue even today
<hdv> [ I had this problem in a password field I built, that some browsers would show icons where our UI design needed an icon ]
<hdv> masonf: good questions for sure
<gregwhitworth> ack scotto_
<gregwhitworth> ack gregwhitworth
<hdv> scotto_: as I commented in the thread ends with popups upon popups upon popups… we get that a lot in Microsoft Edge, where the UA autocomplete takes precedent even when I use the autocomplete attribute
<gregwhitworth> delta.com is one such example that is annoying to me
<hdv> scotto_: so the only advice we can give to people is to turn off the Edge autocomplete option
<hdv> s/people/people now
<hdv> scotto_: so this would be hard to figure out, how it would work
<hdv> scotto_: this would allow people to build a popup without JavaScript, but they would need a lot of JavaScript to turn off to make it workable?
<hdv> scotto_: I don't know what anyone would put in a popup for a password? because that information should be private?
<hdv> gregwhitworth: to me the issue with this is, do we want to not allow it?
<hdv> gregwhitworth: currently this roughly works when you start typing, is that how it would work, masonf ?
<hdv> masonf: that's kind of the question for today, how it should happen. The one thing we have decided is when you use a keyboard and use a down arrow, it would work
<hdv> gregwhitworth: why are we prohibiting is, what would be the reason not to do it?
<hdv> scotto_: there is a strong reason not to want a custom listbox popup (maybe a hint)… but what you just described should be pretty helpful, but I woulnd't expect that on down arrow, wouldn't expect to find info there, would expect like a listbox on down arrow
<hdv> gregwhitworth: I basically don't see a strong reason to prohibit it
<hdv> masonf: maybe for now we could back off on supporting the attributes on type inputs, because we're not sure what the right behavior should be
<hdv> scotto_: it does seem there should likely be different behaviors based on what should be selected
<hdv> masonf: if I want to know what the restrictions of a password field would be, I would probably not press down arrow
<hdv> gregwhitworth: right, me neither, but why prohibit?
<hdv> gregwhitworth: btw, it should probably not be down arrow, but in block direction arrow of the keyboard, so that it depends on where it is popping directionally
<vmpstr> wouldn't you need to know where it will pop up? :P
<hdv> gregwhitworth: I gues it almost needs a research paper, not even sure if we can do it generically
<masonf> Proposed resolution: don't support invoking attributes on text inputs for now.
<hdv> gregwhitworth: the argument for prohibiting is probably that the use cases are so varied that we would need to research omre
<hdv> s/omre/more
<bkardell_> +1
<gregwhitworth> q?
<hdv> vicgutt: just a question to be sure… not against the proposed resolution, but to be clear… for the combobox use case, how would we handle that then, would we put the popup on the wrapper element and then figure it out with JavaScript?
<hdv> gregwhitworth: you would basically have a combobox wrapper and add a button to that to make it work
<hdv> gregwhitworth: but there are use cases in the wild, like adding a label in GitHub, there are comboboxes that don't have arrows
<hdv> gregwhitworth: so a web dev could just put in a button if you wanted to do it without JavaScript… but when we as Open UI will build a combobox, how will we do it?
<hdv> gregwhitworth: ultimately we would need to work on that, masonf
<hdv> vicgutt: I agree
<masonf> Proposed resolution: only support invoking attributes on buttons (as described in the issue).
<hdv> gregwhitworth: what about input type=submit btw?
<hdv> masonf: basically with button in this resolution would submit any button-like thing that doesn't submit a form
<scotto_> brian...
<bkardell_> lol
<masonf> RESOLVED: only support invoking attributes on buttons (as described in the issue).

[mfreed7]

Based on the resolution, I'll close this issue. We can re-open it in the future to possibly discuss adding support for <input type=text> and other elements.