Show cursor as grab when buttons are draggable

[ghost]

Currently when you resize the screen and hover over the buttons they mouse cursor is pointer. This PR changes the mouse cursor to grab to indicate that the buttons are draggable.

As per github issue: #4694

Before:

After:

When the buttons are not draggable the mouse curor is pointer.

This just makes it easier to understand when the drag function is activated.

[FlusherDock1]

Cursor shouldn't be with drag icon just because you hovering buttons. It can be misunderstood that buttons not clickable but draggable. I think cursor should be with drag icon when you click and hold on buttons.

[ghost]

@FlusherDock1 How to know if the buttons are draggable when the mouse cursor doesn't tell you - if you don't click them? The whole point of the mouse cursor:drag is to indicate that the element is draggable. It's common sense, that a button is clickable (that's it's purpose). But it's not obvious that the elements are draggable.

It's only cursor:drag when the draggable function is turned on. When it's not turned on it's cursor:pointer this is the correct normal method how to do things.

[edit] Our developer and marketing company codes and designs things to ISO standards, what that means is we make iso continuity standards. In this case this PR pattern matches the exact same behaviour of the table grab function (see pr here: #4629 - which Daftspunk accepted). It is not a good idea to mix and match different patterns on the same code base - it confuses users and creates a poor UX.

[bennothommo]

@ayumihamasaki2019 I somewhat agree with @FlusherDock1's point-of-view, insofar that the primary function of the buttons is to be clicked on, so having it show as a drag icon by default is hiding the primary intention of the buttons. It made sense for the table headers purely because they're not necessarily clickable.

Additionally, it's likely that in most cases, the only people who will need to drag the toolbar buttons will be people on mobile devices, which means there is no need for a mouse icon.

[ghost]

@bennothommo A couple of things I disagree with you on (sorry):

It made sense for the table headers purely because they're not necessarily clickable.

You're wrong - the table headers are clickable and when you click them the columns are sorted in order.

Additionally, it's likely that in most cases, the only people who will need to drag the toolbar buttons will be people on mobile devices, which means there is no need for a mouse icon.

That's a poor assumption! Let's say I have a long list of buttons, then the draggable function would show up on a larger screen size. In an example, let's say I have a list of horizontal buttons in one of my plugins, it would then appear on a desktop device, thus a mouse cursor would be a factor. Actually I do have some plugins that have 6 - 10 buttons in a row so that conflicts with your statement.

[bennothommo]

@ayumihamasaki2019

@bennothommo A couple of things I disagree with you on (sorry):

Haha, I welcome discussion, so by all means, disagree away. :)

You're wrong - the table headers are clickable and when you click them the columns are sorted in order.

This is true, but in that case, I would've made the same argument as I am making now with the buttons. I must've missed this one when that change was being reviewed.

That's a poor assumption! Let's say I have a long list of buttons, then the draggable function would show up on a larger screen size. In an example, let's say I have a list of horizontal buttons in one of my plugins, it would then appear on a desktop device, thus a mouse cursor would be a factor. Actually I do have some plugins that have 6 - 10 buttons in a row so that conflicts with your statement.

Personally, if you need more than 4-5 full-size buttons in a toolbar, I think your whole navigation could probably be refactored, either into a dropdown menu of actions, or made more contextual with certain elements in your page.

[ghost]

@bennothommo

Personally, if you need more than 4-5 full-size buttons in a toolbar, I think your whole navigation could probably be refactored, either into a dropdown menu of actions, or made more contextual with certain elements in your page.

Yah I agree, personally I'm not a big fan of the current method, I think it's a poor design, built from an age before flexbox.

I much perfer to see the buttons use a flexbox wrap method and when the screen size gets very small to make the search box reduced even more. I think it's time to make all the buttons 100% width.

For example:

Above 320px screen width use flexbox wrap method.

Below 320px screen width make all buttons 100% width for each row and the search box on the first row.

[Samuell1]

Its just to save space on smaller displays, you dont want to have every button on every new row i cant imagine how much it takes space from smaller screens. If you prefer it like that you can manually override it trough plugin or backend css i did same thing with scoreboard :D

[LukeTowers]

Going to close this because the primary function of the buttons is to be clicked on. If you're on a device that has a mouse pointer and also has too little screen space to show the buttons then that tells me that you have too many buttons and should refactor it to use dropdowns or other UI elements.

I would however be fine with a PR to make the "scrollable container" the buttons are in have the grab icon so long as the buttons themselves retain the regular pointer.