Floating save button

+1. And/or perhaps there's a module (or just a block snippet) that one can add to the Admin menu for saving/submitting whatever form is open?

--D

++1 I totally agree. same for the block page.

I believe this would be a great feature for all submit/save buttons on all pages. You always have to click them. So maybe a Action bar would be a good way to go.

I have done a very quick patch that creates what I think we should be trying to achieve. Obviously it needs a little more work but this should be a start.

Did some cleaning up to only include the areas I thought were relevant instead of "all" buttons that are created by forms.

--edit I prefer patch 4 more now. patch 5 cleans up too much. Wish to find a better way to clean up bit.

I figure this is not soo active so I take some lead on it.

Ok now I am much happier with this cleanup. but there is still more to be done. Some people checking and saying what there is would always help. :)

I am pretty happy with this new patch. Think it is ready for testing and then just patching for that testing.

Your selectors are not yet correct, it also applies the style to underlying elements (see attached screenshot).

Also when applying the patch there is the following error:

<stdin>:9: trailing whitespace.
 
warning: 1 line adds whitespace errors.

Can you give me some more information about what environment you are using. I don't see this. I don't get a search button on that page. It has autocomplete for me. and this is on Mac OSX with GC, FF and Safari and IE, GC and FF on windows.

I will check the whitespace issue out now.

I checked it with the latest Chrome on Mac OSX, with overlay enabled, so it was an overlay over the front page (which shows a search box by default in the first sidebar).

ahhh ok yes I know why now then. :)

Patch added that should fix both these issues.

This is also not the right way to go I think, now you are manually selecting elements that might be influenced by your first selector to give them a relative position again. This will not hold up and by doing it this way you have to add new selectors to the list once we find out that the are influenced by your selector.

So the right way to go I think is: Only target the submit buttons that are part of the main form and might or might not be rendered in an overlay when the submit button is down the fold (so when you are not able to see it when you load the page or when you are scrolling).

That will need some more work because we need to build in more logic, we might have to introduce some javascript to tell 'where' on the page we are. Also we have to think about the other forms we might influence and whether or not this way is still usable. (take for instance the new node edit initiative or custom modules).

It might be better to build this kind of logic into a module because it touches so much more than only showing the form-actions at the bottom of the page.

Yeah well I think there is a lot more functionality it needs to have anyway. Like there are people who would like the buttons up the top instead as well. So looking at that. And also how to handle mobile devices. This is a start though that shows that some simple css can achieve it.

You are probably right on the separate module front for now. which means then that maybe a D8 version of http://drupal.org/project/page_actions is the necessary move with the aforementioned improvements. In which case it would be smart to grab all similar requests for D8 and combine them in one area and work on them.

However maybe we should be looking at it more in this task which means there is a way to push it into the d8 core.

http://drupal.org/node/1510550

Which is a sub task of this one

http://drupal.org/node/1510532

I agree with you that the basics of this issue could be achieved with only a few lines of css, so in that way: good work! I also agree that we should look at the bigger picture right now and getting UX / UI people involved in the main tasks of form element (save buttons in this case) placement. So i think the best way to go is join forces with the people already thinking about this in the tasks you mentioned in #15.

This is general bad practice now, considering mobile useage.