remove 100% width on input so that input width can be styled by class

[jonathanconway]

No description provided.

[klepas]

@petronbot What’s your take here? I’d rather we come up with some more styling for how <form> should function to hold these inputs than remove the 100% width styling from sub items themselves? Thoughts?

[jonathanconway]

@klepas @petronbot Thanks for looking at this.

Perhaps we have a <div> element for wrapping fields (labels, inputs) which can then have its width set individually or according to a few pre-sets (e.g. "mobile number", "verification code", "first name", etc, etc)?

I dunno, what do you's think? 😄

[jonathanconway]

Also, a note about making field widths responsive. A general rule I'm sticking with, which seems to cover most bases is:

1. Hard-code the field width as a static em.
   However, if the value is > 20 em (i.e. 480 px, which is mobile max-width, minus 10 em for general screen padding), then...
2. Make it 100% on mobile, by nesting it in a media-query: @media(max-width: 480px) {...}.

[TrebBrennan]

Curious what need we're addressing here? It might help inform the solution if we can get a use-case?

Flipping the convo on it's head; do we run with a sensible default (full width) and add a class to change that? -- Mostly so that inputs look nice without any thought?

[jonathanconway]

Curious what need we're addressing here? It might help inform the solution if we can get a use-case?

Yes sure @TrebBrennan.

In my case, the designers on Identity have asked me to make all the field widths across the application correspond as closely as possible to their expected inputs.

So for example, they want a mobile phone number field to be exactly wide enough to accommodate the maximum number of digits anyone use to enter a mobile number and no more.

This is, as I understand, to serve as additional visual re-inforcement to the user of what type of data can/should be entered, thus making the interface more usable.

Flipping the convo on it's head; do we run with a sensible default (full width) and add a class to change that?

I like that idea of erring on the side of bigger, as a default.

So perhaps we should keep the 100% in there, but just apply it to input, textarea, thus making it easier to override. I.e. rather than: form input[type='text'].sms-code {...}, you can just have: input.sms-code {...}.

[petronbot]

@jonathanconway I like the idea of making the default style less prescriptive - I agree that the appearance of the fields is probably specific to their type or their context.

I'm happy to merge in this change if you are @klepas.

@TrebBrennan do you think that the browser default width for inputs is sensible enough? Or should we create a .form-container that sets a width on its child inputs?

[hannah-ustwo]

[STATUS UPDATE] Popping this into UI-kit's esky. We may get to this, but with newly-established priorities on testing and removing custom CSS from platform for August 30th, this will have to move down in priority after those things are sorted first.

[klepas]

If we do go with the proposed change… it’s well, 1 line, and done for us.

@hannah-ustwo with some of the small items like this one it might be more worthwhile to just deal with it and either merge/close than adding tix in Jira, cross-ref’ing, and then getting back to this several sprints down the road, which also has an overhead of re-familiarisation.

0.2¢. (:

[klepas]

@petronbot Hey, let’s make a decision on this today? I feel grumpy over a 12-day old PR with a delta of 1 line of code. :)

[hannah-ustwo]

From my understanding, even if it's a simple line of code this will be making a larger impact across many things - should have some further consideration! Not priority for Aug 30, so confirming that we'll have this in the esky until we have more specificity on what else this will affect, what needs to be done, etc.