cdata
commented
9 years ago Native buttons do this by simulating a click when the appropriate keyboard event (enter or space) occurs while the element is focused. paper-button/paper-icon-button could do this...
This is what IronButtonState gives to those elements. That is, IronButtonState bestows implementing elements with responses to keyboard input that attempt to mirror what happens with a native button as closely as possible.
Right now, keyboard event handling is up to the user of the element...
Per the above explanation, this is incorrect. IronButtonState handles keyboard interaction for the user, and simulates clicks when the appropriate input is received.
Is the proposed problem that the user shouldn't have to set up a listener for the click event to be notified of what happened?
Are you perhaps asking for a further abstracted notion of activation that doesn't simulate a click on behalf of the user?
As an aside: active has a very specific meaning (by subjective design choice) for our button-like elements. Polymer's usage of active does not necessarily align well with any particular web platform usage of the term. Our usage of active, IIRC, is most similar to the web platform notion of checked.
alice
notwaldorf
Native buttons do this by simulating a click when the appropriate keyboard event (enter or space) occurs while the element is focused. paper-button/paper-icon-button could do this, or alternatively could provide an
activateevent or similar, to be fired under whatever circumstances the element feels like it.Right now, keyboard event handling is up to the user of the element, who would need to either subclass it to use
IronA11yKeysBehavioror else implement their own event listening.It seems like
IronButtonStatealmost does this, inasmuch as it has a_userActivatemethod which is fired from tap, click and keyboard events, but this doesn't seem to be part of the API.