-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Adjust padding and margins on Input #324
Comments
Removing margin makes sense because components shouldn't influence layout. |
A follow up question: |
Only show the message if there is a message value *and* the field is invalid. Move the margin for spacing between input and message to the message itself so the space is not there when the message is not. related #324
The 12px padding-right and padding-left to position the text entered inside the |
Re is there a doc, this repo is it for components. On layout, etc. we don't have anything completed as of now. |
Regarding the padding, yep exactly. Currently if you want a full width input, you need to remove the right padding, for example. What I have had success with in the past is to create a wrapper element ('input-group' for example), that handles the layout of input elements when there is more than one. You want to use an input straight up, no problem, it doesn't have any opinions about how it is spaced. |
Full width input - even if the text goes beyond the input width, it's still appropriate to have padding on the right. Additional inputs on the right - the padding shouldn't affect this. Can you give an example of where this is happening? |
Part of this tweaking and adjustment should include changing this 'padding' to |
Currently
Input
has padding and margins on the input itself which are really implementation details, and shouldn't be handled by theInput
itself.As a result I find myself manually removing/changing the margins/paddings in a lot of circumstances.
A
margin-bottom
for spacing makes sense, but having a top as well and relying on collapsing margins when the label is not there doesn't seem like the cleanest solution.We want to have an
Input
component that can be used universally without impacting its surroundings and with minimal overrides.I am unsure of why said padding/margins are all there so want to open the discussion around this.
Ideally we could also move all positional and box-model related css properties to the root component to allow for easier overrides when we do inevitably have to.
E.g. the below is a nested component within
Input
but the margin has impact on the implementations position, this would be remedied by moving the spacing to the root component and allowing overrides to be applied there.The text was updated successfully, but these errors were encountered: