This loses the work that @Fedik did to disable buttons

@brianteeman Would you have the number on that PR?

Any suggestions for the 'Change Status' icon and color?

I think the pr was #20650

You will need to get the a11y team to review this so that the dropdown is described and announced correctly

You will need to get the a11y team to review this so that the dropdown is described and announced correctly

@joomla/joomla-accessibility-team-jat Please review.

I have tested this item ✅ successfully on 47fc7c1

This loses the work that @Fedik did to disable buttons

@Fedik As JS is not really my forte, I'll ask you for some guidance on this.

I would like to remember my PR and show only buttons if they can do someting . https://issues.joomla.org/tracker/joomla-cms/20559

@ciar4n are you using Bootstrap's dropdown here?

@chmst

show only buttons if they can do someting

+1

@ciar4n are you using Bootstrap's dropdown here?

Yes. I think doing anything else is outside of the scope of this PR. For now lets consider that grouping buttons is the way to go and if so, how best to group them,

no - lets wait a year for a custom element - that solves everything everywhere

@brianteeman you know what I'll revert all the custom elements work. Back to jQuery bootstrap seems what people want! So let me please you and good luck with Joomla 4...

Please stop fighting. Ciaran is correct that this is not the place for the custom elements discussion - he's using the api for grouping buttons. Whether that uses Bootstrap or Custom Elements is a totally different issue/PR. (To an extent so is the accessibility of that dropdown as it's not just going to be used here - but across many extensions for differing groupings - although of course if we can sort that here all the better!).

However ensuring that we don't regress the grey'ing out of buttons when no items are selected is important and should be considered as part of this issue

the question here, what should be "grayed" (disabled), the "main" button of the group, or the elements in it?

the elements not grayed, because in the group they are "anchors" <a> not <button>, if I right remember,
I try to check more next weekend

@Fedik As none of the "change status" options will be enabled unless an item is selected then I would suggest that it should be the main button that is disabled

My2Cent: The graying needs a designer. As it is now, I always try to clean my glasses. Maybe gray could be really gray?

Or even grey ?

I have tested this item ✅ successfully on 47fc7c1

Ready to Commit after two successful tests.

Please remove the RTC as per discussions above here #21247 (comment) it is not ready to be merged yet

There was a request for an accessibility test. The toolbar does not meet the accessibility requirements. I am preparing a report. But I need time

@zwiastunsw for future reference if you are doing an a11y test please can you post that it is in progress so that the pr doesnt get merged while you are testing

Of course, the last days I were very busy.

@zwiastunsw thats not a problem - just so that we know its being done

@franz-wohlkoenig Please remove RTC label on tracker, see #21247 (comment) and below.

@wojsmol done, Status is now "Pending".

I can make "disabled" the elements in dropdown,
but I hit the problem, with the main button,
Bootstrap crashes if I add <joomla-toolbar-button/> to toggler:

<joomla-toolbar-button>
 <button class="button-group btn btn-info dropdown-toggle" 
    data-toggle="dropdown">Bla</button>
</joomla-toolbar-button>

Bootstrap do not expect extra wrapper...

@dgrammatiko maybe you have some idea?

@ciar4n please check ciar4n#4

@Fedik use this: https://github.com/joomla-projects/custom-elements/blob/master/src/js/dropdown/dropdown.js

hm, then I have no idea :)

okay, fixed,
@ciar4n please check ciar4n#4
this should work now

I have tested this item ✅ successfully on 47fc7c1

@franz-wohlkoenig wait, @ciar4n still need to merge my pull request :)

Thank you @Fedik ?

If the purpose of this PR is only to group buttons, I have no comments. However, I have to write here that this toolbar causes accessibility problems. I have presented them here: Toolbar - About accessibility.

Concerning the "disabled" of the items in the dropdown: the intention is right, but in this case it should be the buttons and not the anchors. The "Publish", "Unpublish", "Feature", "Unfeature", "Archive", "Trash" options do not move the user to another page or place, but only change the status of the selected items.

I think there are two issues. First: grouping the buttons. This looks good.

The second is: Disable buttons when no item is selected. Do we really need this disabling?
The message in J3: "Please make a selection" is quite clear. I never saw a question or complaint there. In the contray. Now i must know what to do for enabling the buttons.

Do we really need this disabling?

Actually, from UX perspective, disabling is not the best option. If something is not available you should not present it, that is the rule of thumb for good UX

As I said .. but in this case I see this: The function is available as soon as a singel item is in the list and the user has the right to change the status. So the buttons can be used but need checked items. A message "Please check items" is correct and we must do nothing

If the user has not the edit.state right or if the list is empty: https://issues.joomla.org/tracker/joomla-cms/20559
But this can be another PR, we must not mix these two issues

Actually, from UX perspective, disabling is not the best option. If something is not available you should not present it, that is the rule of thumb for good UX

I am not a UX specialist. This is a toolbar. I should see what kind of toolkit I have. But it is also common (and good?) practice if options that I can't use are disabled. So I do not think that failure to show is a good thing.

Concerning the "disabled" of the items in the dropdown: the intention is right, but in this case it should be the buttons and not the anchors

then just need to replace <a> to <button>, and problem solved

I've change dropdown items from anchors to buttons and grey'd disabled items as suggested.

PR should be ready for testing if anybody is willing ?

I have tested this item ✅ successfully on d23fd84

Great improvement
Scanning so many big buttons horizontally is a headache / tiresome
plus it is intimidating to see them there all the time

I imagine other core screens (and 3rd party extensions), will follow after this is merged

Applying Patch got

and Patch isn't applied.

That's a patch tester issue, nothing to do with this...

thanks Michael, but Patch isn't applied.

By design. After filtering out files that shouldn't be patched (there are a bunch of files in the repo that don't exist in release packages), if a file that is supposed to be patched doesn't exist then applying the patch fails.

As the notification says, 4.0 support is experimental because the repo is in a constantly changing state. Patch tester doesn't know about any of the NPM build tools to ignore those in that filtering step mentioned above, so a pull request changing some of those files isn't going to work correctly.

Additionally this PR have merge conflicts.

Ok @ciar4n would you mind sorting out the conflicts here (sorry) if we have the disabled status sorted then I'll get this merged as a working implementation of the grouped buttons and we can then additionally work on ally/custom elements etc :)

Unable to compile SCSS with the recent media changes. Already spent half the morn with Dimitris trying to sort it out with no luck. Issue seems to be unique to windows.

Ah. So it wasn't just me then.

If there is one thing I've learned over the last year and a half it's that NPM and Node are probably the worst as it relates to being problematic to use on Windows, everyone at my office has had issues galore since starting new projects or migrating legacy projects that use SCSS compiling (funny enough the LESS compilers work fine, and it all works fine on our Linux dev tools or CI pipelines).

is this the error you are getting

something exploded Invalid CSS after "...eed to override": expected 1 selector or at-rule, was "text-rendering: aut"
something exploded 1
something exploded 7
something exploded Invalid CSS after "...ly-monospace)}}": expected "}", was ""
something exploded 1
something exploded 7
something exploded Invalid CSS after "...ly-monospace)}}": expected "}", was ""
something exploded 1
something exploded 7
something exploded Invalid CSS after "...ly-monospace)}}": expected "}", was ""
something exploded 1
something exploded 31
something exploded Undefined variable: "$input-btn-padding-y".
something exploded 3
something exploded 36
something exploded argument `$color` of `darken($color, $amount)` must be a color
something exploded 129
something exploded 36
something exploded argument `$color` of `darken($color, $amount)` must be a color
something exploded 129

@brianteeman yes that was it iirc

@ciar4n @brianteeman @dgrammatiko scss compilation is working for me on Windows 8.1 if I run node build.js --compile-css

node -v
v8.11.2
npm -v
6.2.0

@dgrammatiko npm run build:css in not working

joomla@4.0.0 build:css W:\var\www\4npmtest
> node build.js --compilecss


  error: unknown option `--compilecss'

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! joomla@4.0.0 build:css: `node build.js --compilecss`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the joomla@4.0.0 build:css script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

@wojsmol thanks, this should fix it: #21350

This is failing for me too
npm run build:css

When i posted successuful test i used:
(I have npm 5.6.0)
node build.js --compile-css

because i noticed that npm install (postinstall part) is using the above
will test #21350

@wilsonge conflicts fixed

@wilsonge if you can merge this, i can look at doing similar in other views

@rdeutz is the system test here failing because we're moving the basic toolbar to a webcomponent or some other reason?

Definitely want to get this merged. Need Dimitris to fix the installation stuff (you can manually patch you versions for now in both installation files), fix the merge conflict you accidentally committed and I've asked Robert to look into the system test failure because that's not the 'normal' installation one that fails from time to time

fix the installation stuff

What's broken?

Question: is this still compatible with the WORKFLOW?
(Just compared the test instructions screenshot with what we have now with workflow.)

Please post a screenshot of what is now expected from this PR, specially the Status dropdown.

Also, can't apply here (with eclipse) the changes brought to cassiopea

After patching I confirm that using the "Change Status" toolbar button is useless except for Feature/Unfeature.

Question: is this still compatible with the WORKFLOW?

Honestly no idea. All I get when opening 'workflow' is...

I'd have presumed it was a different component so doesn't apply here. I guess that must be incorrect. Also add that this PR was created prior to workflow been merged.

Also, can't apply here (with eclipse) the changes brought to cassiopea

What changes exactly?

After patching I confirm that using the "Change Status" toolbar button is useless except for Feature/Unfeature.

I assume this is in the 'workflow' component?

I assume this is in the 'workflow' component?

Nope. It is in the Articles Manager where the new workflow stuff has impact.

Since workflow has been merged, quite a few things have disapeared from the time when you created this PR. Basically, we have, in Articles Manager, a totally different use of the Toolbar.

Here is what we get now without your patch:

Here is what we get now without your patch:

Certainly not what I am seeing on this end. I think I might have to park this until workflows is more stable.

After patching I confirm that using the "Change Status" toolbar button is useless except for Feature/Unfeature.

With workflows introduced, this is indeed true. I have no idea how to go about fixing this.

So it appears workflow removes the publish/unpublish/archive/trash buttons from the toolbar? I guess that leaves feature/unfeatured the only items added to the 'Change Status' dropdown?

and that is just plain wrong and hopefully it will be changed

This PR contains the required CSS to apply similar changes to other views. So for the sake of moving things along, only the feature/unfeatured options remain in the toolbar (as is currently the case). They can be added back when ready by does working on workflows.

This PR should be once again ready for testing/merging

I really like this PR, perhaps we could implement a in some way "intelligent" dropdown button, which offers transitions depending on the selected articles...

The good thing is, with this approach we would get, although we're using the new workflow, exactly this output, when using the unmodified default workflow: https://user-images.githubusercontent.com/2803503/43141243-6266f50c-8f4d-11e8-8d8a-a80a96bf4127.png

If it could look like #22004 designwise it would be great.

Closing. Replaced by #22393.