Confirm Functioning of Options That Can Be Specified at Form or Form Element Level

[lcreid]

Some questions have been raised about options, like layout: inline/inline:true, that can be specified at the form level (on bootstrap_form_for, bootstrap_form_tag, or bootstrap_form_with), or at the individual element level (on checkbox for example). The documentation may be unclear or wrong, the code may be wrong, or both.

This issue is intended to capture the discussion around these options. It may lead to more specific issues and pull requests. Please contribute your thoughts.

From: #410 (review):

Some parts of the README imply that you just add layout: :inline to bootstrap_form_for and you are done. But that is either broken or the doc is wrong, because as I see in the tests, you must explicitly pass inline: true to each radio or checkbox (in addition to passing layout: :inline for the form?).

The options that should be looked at are:

• layout: inline/inline:true
• layout: horizontal
• hide_label
• skip_label
• label_class
• label_col
• control_col
• inline_errors
• label_errors

Please add any other options that you think should be considered.

[lcreid]

#291 requested passing label_class to each of the labels when hide_label: true is given to collection_check_boxes. It begs the question as to how to format the label regardless of the state of hide_label.

[lcreid]

Could someone please confirm that this is how we would want check boxes to look given layout: :inline, layout: horizontal, and default? Make sure to scroll down to see hide_label and skip_label.

The examples can be taken as what should be generated by collection_check_boxes in a simple case. The user could also generate the same effect using check_box directly, but would have to provide some additional markup, for the "group" labels (Bootstrap calls them legends), and for the rows in the case of layout: :horizontal

In the layout: :horizontal case, label_col and control_col would be used for the label (legend) and control (the check boxes combined with their labels). The ``skip_label` case would not use the default, but would use the whole width for the controls.

(I'll do radio buttons next.)

[lcreid]

Please confirm that this is how we would want radio buttons to look given layout: :inline, layout: :horizontal, and default? Make sure to scroll down to see hide_label and skip_label.

The comment above applies to radio buttons.

Thanks in advance for your comments.

[lcreid]

The Bootstrap documentation says that you'll have to add your own spacing to make inline forms look good. In the case of check boxes and radio buttons, there is a class, but in other cases, it looks like it's left up to the designer's taste.

Since it's bootstrap_form's mission to make it easy to get decent looking forms, we should address this.

One approach would be to find reasonable defaults. The Bootstrap documentation uses "mb-2 mr-sm-2". It looks like you would place these classes on the immediate children of the in-line form. It also looks like the last child would not get the "mr-sm-2".

Since we would want it to be easy for the user to override the defaults, I don't think we can rely on simply telling the user to use some of the various exiting class options. It would be hard for the code to figure out that the intent of the user was to override the defaults.

Perhaps we could do something like a new inline: option at the form level. inline: true would be equivalent to layout: :inline. However, inline: would also take a hash. Any non-empty hash would turn on layout: :inline. Keys in the hash would be, at a minimum, vertical: class and between: class, where class would typically be a Bootstrap spacing class. (We could also take horizontal as a synonym for between.)

Since these are new options, we shouldn't break anyone's code. Also, by choosing reasonable defaults, existing forms that are migrated to version 4 should look no worse than they do before the migration.

[lcreid]

PR #433 addresses much of this issue, but doesn't go very far in addressing the layout ideas in the preceding comment. The PR might be enough to say we've resolved this issue for 4.0.0 alpha.

[lcreid]

Closing as no longer relevant.