Skip to content
This repository has been archived by the owner on Jul 10, 2020. It is now read-only.

The Future of "Button inside input" #441

Open
mistergone opened this issue Sep 21, 2016 · 5 comments
Open

The Future of "Button inside input" #441

mistergone opened this issue Sep 21, 2016 · 5 comments
Assignees
Labels

Comments

@mistergone
Copy link
Member

mistergone commented Sep 21, 2016

If you check out the current version of our cf-forms portion of Capital Framework, you will find our "Button Inside Input" style:

screen shot 2016-09-16 at 12 03 06 pm

But @KimberlyMunoz rightfully pointed out that the spacing of this element is very precarious, and translations may break it. I'm only fluent in English, so I won't take a stab at "Clear" in another language, but here's the Klingon terms for "remove words":

screen shot 2016-09-16 at 12 09 11 pm

Translations are a problem, but also any text other than "Clear X" would break our current implementation - so "Clear text" would also break it.

While moving this code into atomic design, I attempted to make the button variable length. I was able to implement this, but the design broke when the input received focus. My attempts to fix the focus issue eventually ended with success, but only in a few browsers. After a lot of trying, I still wasn't able to make it work in Internet Explorer. (Some of my failures can be found in the discussion of the PR here).

For now, we've stopped trying to fix this problem for our next release. However, this problem will come back to us when we try internationalization for certain. So I'd like to propose the following:

  • If someone knows of a working implementation of a design like this, we could review it and see if it would work for us. Our limited research has show working implementations like this design use JavaScript to shore everything up (which is not something we want to do).
  • We consider removing the "Clear" text from the button and go simply with an "X" icon. The "X" icon is always a fixed width and thus removes the need for the button to be of a variable width.
  • We consider moving the "Clear" button outside of the input. That is, the input could receive focus (the border and outline included) and other states, but the "Clear" button would exist outside of that input box. This should allow the "Clear" button to be a variable width.
  • Someone proposes a solution aside from the ones I've suggested above. 😄

I'm all too happy to answer questions, go over each solution I tried, and otherwise get or give feedback about the intractable problems we've encountered trying to implement this design in a way that allows the "Clear" text to be variable width!

@caheberer
Copy link
Member

@mistergone where were you trying to implement this? I'm unfamiliar with us using this convention. Is a clear even necessary?

@jimmynotjim
Copy link
Contributor

@mistergone didn't we end up resolving this during the move to v4?

@jimmynotjim
Copy link
Contributor

@mistergone is this still a concern or can we close it?

@caheberer I should have mentioned, this is used in the search bar on cfgov-refresh and is documented in Capital Framework, but I can't find it in the Design Manual. It should probably be added under Form Fields, but I'm not sure

@nataliafitzgerald
Copy link
Contributor

nataliafitzgerald commented Oct 16, 2017

@jimmynotjim - Do we only use this for global search?

Following up on @caheberer's comment - Do we think that clear is necessary?

@jimmynotjim
Copy link
Contributor

@nataliafitzgerald Yes, as far as I know it's only been used for the global search.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants