You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Complex forms contain many types of input elements (checkboxes, dropdowns, pickers). It is difficult to use a consistent input labeling mechanism approved by Material. Take a look at this for instance:
The dropdown input labels "From" and "To" would match perfectly to what the input label will look like for "Location" once a value is entered. In reality, this would be a hack in the client app's code because Location's style and size is provided by the input widget while the "From"/"To" labels of the dropdowns are explicitly drawn by the app.
Leafy chose to fix this by disabling material labeling for all form elements and instead providing a consistent labeling mechanism. Unfortunately, this breaks when intrinsic padding is introduced. Examples:
Top and bottom padding on Input
Top and bottom padding on DropdownButton
Start and end padding on Slider
It would be great if clients could specify the padding (if any) for these elements.
Another way to solve this is to standardize labeling across all form elements. That would be very neat and it would not require any workaround on the app side. That way, Input would require no change but things like Slider, Checkbox, DropdownButton would optionally take a "label" argument which would create a label similar to Input's label with the same font/padding/size.
#254 is another (long standing) issue about making associating a label with a control much easier. There are a bunch of expected behaviors for associated labels which are hard to get right w/o framework help.
changed the title [-]Allow clients to define the padding for Input and DropdownButton[/-][+]Standardize labelling among input widgets[/+]on Nov 3, 2016
The dropdown input labels "From" and "To" would match perfectly to what the input label will look like for "Location" once a value is entered. ...
I'm not entirely sure what you're getting at here. I'm guessing that you want to be able to line up the baselines of the label and the dropdown's value?
I spoke with @mehmetf and he clarified that this bug is basically about making sure all the existing input controls (checkboxes, radio buttons, sliders, dropdowns, etc) can be used with the widget we create for #6421 in such a way that they all line up (i.e. removing any default padding in that case).
We could do this by having #6421's widget set some sort of inherited widget that controls whether or not to show default padding, or we could make it simpler and just remove the padding on existing widgets (slider in particular), or make it configurable.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
eseidelGoogle commentedon Nov 1, 2016
@mpcomplete is mr. forms.
mehmetf commentedon Nov 1, 2016
Another way to solve this is to standardize labeling across all form elements. That would be very neat and it would not require any workaround on the app side. That way, Input would require no change but things like Slider, Checkbox, DropdownButton would optionally take a "label" argument which would create a label similar to Input's label with the same font/padding/size.
eseidelGoogle commentedon Nov 1, 2016
#254 is another (long standing) issue about making associating a label with a control much easier. There are a bunch of expected behaviors for associated labels which are hard to get right w/o framework help.
[-]Allow clients to define the padding for Input and DropdownButton[/-][+]Standardize labelling among input widgets[/+]HansMuller commentedon Nov 3, 2016
I'm not entirely sure what you're getting at here. I'm guessing that you want to be able to line up the baselines of the label and the dropdown's value?
Hixie commentedon Nov 3, 2016
Fixing #6421 would automatically fix this for the From and To fields here, right?
Hixie commentedon Nov 3, 2016
I spoke with @mehmetf and he clarified that this bug is basically about making sure all the existing input controls (checkboxes, radio buttons, sliders, dropdowns, etc) can be used with the widget we create for #6421 in such a way that they all line up (i.e. removing any default padding in that case).
We could do this by having #6421's widget set some sort of inherited widget that controls whether or not to show default padding, or we could make it simpler and just remove the padding on existing widgets (slider in particular), or make it configurable.
github-actions commentedon Sep 5, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.