Standard approach to Save and Cancel buttons

We should work towards a standard approach to placement and usage of the Save and Cancel buttons throughout the codebase. This is an approach that can be realized over time. A form generally has 2 main buttons, a form submission button and a button to cancel the action. See the following recommendations

  • Form submission button MUST be a <button> element; and
  • Form submission button MUST have classes of .btn-primary and .btn-save; and
  • Form submission button MUST not have a class of .btn-secondary or .btn-link; and
  • Form cancel button MUST be an <button> element; and
  • Form cancel button MUST have a class of .btn-link applied; and
  • For LTR languages, Form submission button MUST be to the right of the Form cancel button; and
  • For RTL languages, Form submission button MUST be to the left of the Form cancel button; and
  • A form MUST have only one button styled with a class of .btn-primary

That’s a lot of bullet points but basically it just means that this should be the template:

<div class="d-flex w-100 justify-content-end">
    <button type="button" class="btn btn-link">Cancel</button>
    <button type="submit" class="btn btn-primary btn-save">Save</button>

Other things on my mind related to this:

  • Right now .btn-cancel adds an icon to the element. Should we consider making a that utility class a first class citizen in the world of button (As the same as btn-primary, btn-secondary, btn-link, btn-danger, etc). This would allow to differentiate the de-emphisis process between a cancel button and other link elements that do not necessarily cancel an action but still should be de-emphasized. My thought is yes, we should do this.

Current approach of relying on developers takes away focus on functionality. If project has a ux standard, common client/javascript code is better at enforcing it. In case of these important actions you can have developer put all form actions in a <div class="oe-fm-action"></div> containing multiple tags with classes specific to this project (oe-fm-add, oe-fm-del, oe-fm-save, oe-fm-cancel). This makes the raw script easier to understand. The client side script can now uniformly add all the verbose tags required by bootstrap team. As a fun project for interns, the script can even rearrange the elements in a standard order and much more.
As an added bonus, migrations forced by bootstrap version changes or even switch to another framework becomes easier.

1 Like

Definitely agree with this. While developing this standard is important, addressing the reusability issues are also important. I can see a Twig macro solving some of this. Or, in the JS context, the solution is probably custom Web Components. Abstracting away the complexity is definitely the right approach. Gotta get some kind of standard established first though.

1 Like