[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