Migrate ‘Reply’ placeholder button to GlButton

Background

The reply button is currently styled like a text input, and includes a text cursor on hover. These styles (.btn-text-field) don’t exist as part of the button migration. In !41430 (merged) there was discussion that led to a decision to have the button be styled as a primary success button, similar to other comment buttons. This MR was merged and then reverted due to varied opinions about its effectiveness.

Here’s a breakdown of pros and cons for each approach as laid out in the original MR and following discussion.

Button styled as input

Pros

• Styling like an input infers entering text.
• Perception of a quick action, even though behavior is no different that styled as a button.
• Familiar pattern in other competitive applications.

Cons

• Visible affordances should indicate what a thing is, what action can be taken, what the result of the action will be, but this does none of these things. As it relates to accessibility, this can be bad for some users. For example, Dragon Naturally Speaking has different commands for “click text field/edit box” vs. “click button,” so the visual presentation as a text field could trick users who visually see a text field. (Related: Intro to UX: the Norman door) (Notes, examples, and references here were pulled from a separate conversation on the subject in web-a11y.slack.com.)
• This style of a button doesn’t align with other buttons in the migration and sets a precedent for this particular button to be unique, and tied to any text input visual updates.

Button styled as button

Pros

• Semantically this is a button that performs an action, visually styling like a button aligns with the behavior.
• Consistent with the rest of the issuable page actions, including commenting.
• Aligns with accessibility best practices.

Cons

• Changes familiar perceived behavior.
• Smaller click target. On its own this is irrelevant as we support buttons much smaller, but in the context of familiar behavior it has merit.
• Even though no actual behavior changed — this is still a button that opens the reply form — the perception of an additional action is there, and thus perceived slower behavior.

Proposal

• Use an actual textarea that is styled to be one line at rest, and expands to multiple lines when focused.
• Reveal controls when textarea is focused.
  • Controls persist while focus remains in the controls or textarea.
  • Controls persist and textarea remains visible and expanded if content has been entered.
• Canceling or moving focus when no content has been entered places focus back on the previously focused element or the newly focused one, and returns the textarea to a single line with no visible controls.

This option includes new development, but the net result would be a stronger pattern that is more seamless behind-the-scenes where only one element is required, instead of a button that moves focus to a new element.

Alternate proposal (archived)

• Use a default button with block width and left-aligned text (Cursor would be hand on hover).
• Ensure that sighted and screen reader users understand that clicking the button will move focus to a newly visible textarea with surrounding controls.
• Canceling closes the textarea and places focus back on the reply button.

This is a relatively low-cost option where the only need is to ensure that the styles exist for the button (left-aligned text, block-level, etc.).

---

Instructions

For instructions about how to replace Bootstrap button with GlButton, see the epic &3914 (closed).