Move the Save button into the Top Bar

Created on 13 December 2023, about 1 year ago
Updated 18 September 2024, 3 months ago

Problem/Motivation

The top bar is being built in ✨ Create the Top Bar Needs review with the minimum functionality: the local actions from entity form. This issue is aimed to move the Save button into that top bar (for Entity forms only, at least for now).

Proposed resolution

To define.

References to make it accessible:

Remaining tasks

Code review

User interface changes

Before:

After:

API changes

None

Data model changes

None

📌 Task
Status

Needs work

Version

11.0 🔥

Component
Navigation  →

Last updated about 11 hours ago

No maintainer
Created by

🇪🇸Spain ckrina Barcelona

Live updates comments and jobs are added and updated live.
  • Accessibility

    It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.

  • Needs accessibility review

    Used to alert the accessibility topic maintainer(s) that an issue significantly affects (or has the potential to affect) the accessibility of Drupal, and their signoff is needed (see the governance policy draft for more information). Useful links: Drupal's accessibility standards, the Drupal Core accessibility gate.

Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @ckrina
  • 🇨🇦Canada m4olivei Grimsby, ON
  • 🇨🇦Canada m4olivei Grimsby, ON
  • First commit to issue fork.
  • 🇷🇸Serbia finnsky

    We had rude prototype for top bar elements.
    https://www.drupal.org/project/navigation/issues/3408500 📌 Move the Save button into the Top Bar Active

    Probably css and markup of it can be reused

  • 🇷🇺Russia kostyashupenko Omsk

    Just my thoughts.
    1. Each form can have several submit buttons, i.e.: Save, Preview, Something else? Which means we can't just use `for` html attribute with form_id attribute value.
    2. Instead we could use somekind of

      <label for="edit-submit" tabindex="0">Preview</label>
      <label for="edit-submit--2" tabindex="0">Save</label>
      <label for="edit-submit--3" tabindex="0">Something else?</label>
    

    The solution above is already working, but i don't think it's too much accessible honestly, correct me if i'm wrong.

    3. Non else "native" solutions are working.
    4. Potentially we could use javascript for this. For everything: creation of the "fake" submit buttons in top bar and for binding listeners.

    Few more thoughts but about other thing:
    1. I think this task should be not only about moving "Save" button in top bar, but instead we should move all actions of the form in top bar.
    2. On which pages we should do this trick? In Drupal there are many pages in admin back office with lots of forms, which has actions. I bet for any admin page where we have form, isn't it ?
    3. Potentially one admin page can contain two or more forms (but i can not be sure here) - obviously we shouldn't move all actions from all forms in top bar. What to do in that case?

  • 🇪🇸Spain ckrina Barcelona

    Answers to #6:

    Each form can have several submit buttons

    Ideally, we shouldn't have several Submit buttons. The other ones should be regular buttons and/or links.

    The solution above is already working, but i don't think it's too much accessible honestly, correct me if i'm wrong.

    See the link on the summary to Stackoverflow where explains that the main button with the attribute form should be enough to associate a button to a form-owner in modern web browsers (the ones supported by core).

    Other thoughts:

    1.I think this task should be not only about moving "Save" button in top bar, but instead we should move all actions of the form in top bar.

    Not really: we'll probably more the Delete action somewhere else more hidden to leave more space in the top bar.

    2. On which pages we should do this trick? In Drupal there are many pages in admin back office with lots of forms, which has actions. I bet for any admin page where we have form, isn't it ?

    This should only happen on Entity forms for now.

    3. Potentially one admin page can contain two or more forms (but i can not be sure here) - obviously we shouldn't move all actions from all forms in top bar. What to do in that case?

    Exactly! That's why we should move it only for Entity forms now. I forgot to add it in this specific issue. I've updated the form.

  • 🇷🇸Serbia finnsky

    Gonna add POC MR

  • Merge request !169Resolve #3408500 "Form attr" → (Open) created by finnsky
  • 🇷🇸Serbia finnsky

    Main idea to use form attribute https://dev.to/dailydevtips1/submit-button-outside-the-form-2m6f

    Claro buttons has margin so not looking good OOB. :)

    We can create custom button button in fact and hide original one.

  • Pipeline finished with Success
    11 months ago
    #85483
  • 🇪🇸Spain ckrina Barcelona

    ckrina → changed the visibility of the branch 3408500-move-the-save to hidden.

  • Status changed to Needs work 11 months ago
  • 🇪🇸Spain ckrina Barcelona

    Needs rebase :)

  • Pipeline finished with Success
    11 months ago
    Total: 235s
    #95676
  • 🇷🇺Russia kostyashupenko Omsk

    MR rebased

    Seems submit is working fine in top bar. But i'm thinking that maybe we shouldn't move original submit, but instead - duplicate? I find it unclear when i'm scrolling down the page and there is no "Save" button in the bottom.

  • Pipeline finished with Success
    11 months ago
    Total: 145s
    #95679
  • Status changed to Active 11 months ago
  • Status changed to Needs work 11 months ago
  • 🇪🇸Spain ckrina Barcelona

    Thanks @kostyashupenko! I left a few comments in the MR plus:

    This should be removing any default margin the button has to it's adjusted to the top bar and looks minimally OK:

    I find it unclear when i'm scrolling down the page and there is no "Save" button in the bottom.

    I totally understand this, and the reason is that you're used to find the button there. We discussed this and having the button in 2 places didn't work. We're basically trying to do a change of paradigm here on full page forms.

  • 🇷🇸Serbia finnsky

    Better to duplicate button then.

    We may create Drupal.theme.toolbarButton = () => {}

    Or what i personally prefer use web component for this:
    https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_te...

  • Pipeline finished with Success
    9 months ago
    #128682
  • Pipeline finished with Success
    9 months ago
    Total: 147s
    #129774
  • Pipeline finished with Success
    9 months ago
    #134675
  • Pipeline finished with Skipped
    9 months ago
    #135381
  • 🇪🇸Spain ckrina Barcelona
  • 🇬🇧United Kingdom AaronMcHale Edinburgh, Scotland

    Don't get me wrong, I love the idea here. The challenge we have to consider, I think, is that we would then have the form submit button in very different locations depending on which form your using.

    For instance, if you're on the node edit form you would Save by going to the top right of the screen, but then if you go to a configuration form, you would save by going to the bottom left of the screen, that feels a bit too inconsistent.

    There's also the question of whether this is follows form design best practice, the user generally expects to start at the top of the form and work their way down until they get to the bottom where they expect to find the submit button. I suspect (although we would need to test this), that users might find this change challenging, especially users who use magnification software so cannot see the entire screen at once.

  • First commit to issue fork.
  • Pipeline finished with Failed
    8 months ago
    Total: 814s
    #166497
  • Pipeline finished with Success
    7 months ago
    Total: 1040s
    #192047
  • Pipeline finished with Success
    7 months ago
    Total: 925s
    #192735
  • Pipeline finished with Success
    6 months ago
    Total: 1092s
    #202184
  • Pipeline finished with Success
    6 months ago
    #202210
  • Pipeline finished with Success
    6 months ago
    Total: 135s
    #204638
  • Pipeline finished with Skipped
    6 months ago
    #208453
  • First commit to issue fork.
  • Pipeline finished with Failed
    3 months ago
    Total: 778s
    #285232
  • Pipeline finished with Failed
    3 months ago
    Total: 151s
    #285242
  • Pipeline finished with Success
    3 months ago
    #285253
  • Status changed to Needs review 3 months ago
  • 🇮🇳India nayana_mvr

    Changes in MR!169 are not getting applied in Drupal 11.x. Getting the following error:-

    Checking patch js/form-actions.js...
    Checking patch navigation.libraries.yml...
    error: navigation.libraries.yml: No such file or directory
    Checking patch js/form-actions.js...

    Tried to apply the changes of MR!7943. Changes applied cleanly but getting console error.

    I have created a new MR!9516 incorporating review comments of MR!169. I have placed all the action buttons in top bar otherwise it will be confusing for the editors imo. This is currently working for node edit form, media edit form and taxonomy term edit form.

    Regarding,

    the user generally expects to start at the top of the form and work their way down until they get to the bottom where they expect to find the submit button.

    I think placing the action buttons in top bar is useful so that editor can save the form immediately after editing a field instead of scrolling down the whole form (E.g., if editor needs to edit just the first field value.). Also, top bar is currently available only on entity edit forms. When user is creating a new node/ term/ media, the save button will be in the bottom itself.

    Kindly review the changes. Thanks.

  • 🇷🇸Serbia finnsky

    @nayana_mvr, original function was written with vanilla js. Is there any special reason to sue jQuery?

  • 🇮🇳India nayana_mvr

    @finnsky No specific reason. jQuery is my primary language. If required, I will re-write it in vanilla js.

  • 🇷🇸Serbia finnsky

    Better to avoid jQuery in core contributions. You can find lot of issues in Drupal core about removing jQuery. So new code may contain it only if special reason exists

  • Pipeline finished with Failed
    3 months ago
    Total: 129s
    #286025
  • Pipeline finished with Success
    3 months ago
    Total: 456s
    #286037
  • 🇮🇳India nayana_mvr

    Thanks @finnsky for the information. I will be careful about that in future. I have update the code using vanilla js. Kindly review.

  • Status changed to Needs work 3 months ago
  • 🇷🇸Serbia finnsky

    Few more ideas we can implement there.

    1. We can not copy all buttons with original classes.
    Because they contain unexpected styles. Probably it is better to create new buttons with document.createElement('button') there and copy original buttons attributes like https://codepen.io/finnsky/pen/qBzGNoZ?editors=1010

    2. We can use existing toolbar button component for that copied buttons. Here you can see idea, https://thunderous-treacle-600c5c.netlify.app/?path=/story/page--basic (Styles can be outdated, this is old POC)

    3. Classes for that buttons can be based on button type. Let's say button type="submit" is primary and other buttons just basic.

    4. Here you may see original comment https://git.drupalcode.org/project/drupal/-/merge_requests/9516/diffs#71...

    We need to do research in Drupal core forms. and find common selector logic for them. I believe should be something. But i'm sure.

    Thank you for participating

  • 🇮🇳India nayana_mvr

    @finnsky I have attempted your suggestions and created a patch. Following are the changes done based on the suggestions:-

    • Created new buttons when 'type=submit' which are 'Save' and 'Preview' buttons in case of node edit form. For 'Delete' action, I cloned the element as it is as I was not sure if it needs to be changed to <button>.
    • Copied all attributes except 'class' from original buttons to new buttons and added new classes 'toolbar-button toolbar-button--primary' to the new buttons since both buttons have 'type=submit' (Referred class names from https://thunderous-treacle-600c5c.netlify.app/?path=/story/page--basic).
    • Placed the new buttons and Delete link in the top-bar.

    This is how the buttons look like now:-

    Regarding the original buttons, should we just hide them from the UI or remove them completely once new buttons are created?

    This is just an attempt based on my understanding. As mentioned in previous comment, this may require more research on Drupal core forms.

  • 🇷🇸Serbia finnsky

    Sorry, but why patch? before you sent it as MR

  • Pipeline finished with Failed
    3 months ago
    Total: 140s
    #291949
  • 🇮🇳India nayana_mvr

    nayana_mvr → changed the visibility of the branch 3408500-move-save-button-to-topbar to hidden.

  • 🇮🇳India nayana_mvr

    nayana_mvr → changed the visibility of the branch 3408500-move-save-button-to-topbar to active.

  • Pipeline finished with Failed
    3 months ago
    Total: 279s
    #291958
  • Pipeline finished with Success
    3 months ago
    Total: 1084s
    #291985
  • 🇮🇳India nayana_mvr

    @finnsky Sorry for the confusion. Since there could be more changes, I thought creating patch would be better than directly committing to the MR. I have now committed the changes to MR!9516. Please check.

Production build 0.71.5 2024