Change the used CSS classes to follow the coding standards

The proposed solution sounded nice to me, so I did it that way.
Everything works fine expect this:

--- a/core/modules/toolbar/src/Element/ToolbarItem.php
+++ b/core/modules/toolbar/src/Element/ToolbarItem.php
@@ -82,7 +82,9 @@ public static function preRenderToolbarItem($element) {
         $element['tray']['#wrapper_attributes'] = array();
       }
       $element['tray']['#wrapper_attributes'] += $attributes;
+      // ToDo: Remove class 'toolbar-tray' with all references in css/js.
       $element['tray']['#wrapper_attributes']['class'][] = 'toolbar-tray';
+      $element['tray']['#wrapper_attributes']['class'][] = 'toolbar__tray';
     }

I tried to replace toolbar-tray with toolbar__tray and remove it's references in javascript and css. But after all it didn't worked. I can't find any reference, but it breaks anyway.

Maybe someone will have a look on this and test?

I think there is already an effort to clean up the toolbar css over at #1663198: Clean up toolbar css. Perhaps we can focus our efforts in that issue?

I thought that it was just part of our CSS standards? Does this issue block banana issues?

Sounds good, probably easier to keep this as part of #1995272: [Meta] Refactor module CSS files inline with our CSS standards

Also see: https://www.drupal.org/node/2195695

A few comments on these OOCSS class suggestions:
.toolbar__main
What does main refer to? I actually don't know without looking up the html. Ideally this name should be obvious without having to inspect the element.
.toolbar__lining
Is this like an __inner? I think that is more common
.toolbar__lining_tray-name
I think this could just be .toolbar__tray-name? Or .toolbar__tray

I've updated the issue summary with all the current classes and what they are for. Next is to update the suggestions.

Ok I've updated the suggestions, I've changed the parent component to admin-toolbar to prevent clashing with other frontend frameworks. I've added variants for the icons and state changes for the toolbar tray, which I renamed to drawer which seems more common.

.admin-toolbar
.admin-toolbar__tabs
.admin-toolbar__tab
.admin-toolbar__tab--home
.admin-toolbar__drawer
.admin-toolbar__drawer.is-vertical
.admin-toolbar__drawer.is-horizontal
.admin-toolbar__drawer-inner
.admin-toolbar__menu-item
.admin-toolbar__icon
.admin-toolbar__icon--escape-admin
.admin-toolbar__icon--shortcut
.admin-toolbar__icon--menu

I've changed the parent component to admin-toolbar to prevent clashing with other frontend frameworks

Hmm interesting. Do you have any examples of such clashes? A quick Google search turned out fruitless :(

Material design was the one that came to mind: http://www.google.com/design/spec/components/toolbars.html

We could include the toolbar in the audit spreadsheet in #2012020: Complete a survey of 3rd party resources to aid with component naming conventions

admin-toolbar is very bad name. Every css class need to be prefixed with it's module name and not any other.

Removed invalid admin prefix.

The only reason why toolbar clash with any other stuff is #1944572: Remove "ul.menu" dependency to prevent theme clashes. Please help reviewing this case.

Working on this. Google Sheet started to organize the classes with notes from the summary.

https://docs.google.com/spreadsheets/d/1DMrCUe1WqTcReaDdZaA8JK8gS8OuQ1sp...

Every css class need to be prefixed with it's module name and not any other.

This isn't the case, our CSS standards does not require us to prefix the classes by the module name, just the name of the component. Modules can define name components, for example the system module defines loads of components like action-links and menu

Because of a lot of the same code, we discussed in DrupalCon Barcelona, that we are going to reroll in #2452343: toolbar add in javascript classes to remove confusion with css so we have a working patch over there, then close that ticket, and merge it in this one, so we can base all the changes suggested by @lewis upon the rerolled patch mentioned before.

This isn't the case, our CSS standards does not require us to prefix the classes by the module name, just the name of the component. Modules can define name components, for example the system module defines loads of components like action-links and menu

@LewisNyman: Why refuse you to understand that such generic named classes may be used in css frameworks? This may disallow adoption of Drupal. We had very good and safe rules in past that everything need to be prefixed and it was good as it has not clashed with any other components or only in rare edge cases. What you say has caused hundreds of clashes in Toolbar. That is why we prefixed all toolbar classes with toolbar and this need to be kept. If we name it prefixing with module or component - I do not care, but never use generic and short names like icon, menu and such things.

Please try to learn from the issues #1938044: Prefix all toolbar classes to prevent theme clashes and #1944572: Remove "ul.menu" dependency to prevent theme clashes what happens with generic classes like "menu", "icon" and other sh**. Re-think and come back and ask if you have not understood these issues, please. But please don't ignore them and tell us anything else.

Don't wait 2 months again before you come back and comment again the wrong ideas, please.

@hass I am not saying that we shouldn't prefix them. I'm saying we should prefix them with admin-toolbar instead of toolbar. Which one do you think is more likely to be used in another framework?

I think a toolbar- prefix (the component name) is already fine and ends with toolbar-foo what should be safe enough. Writing admin-toolbar-foo sound really long and I'm not sure what admin should tell me here as the toolbar may not only an admin thing. It could also be used to the public as a normal menu. Some people already asked for this in navbar module.

@hass Do you not think that there is a high chance that frontend theme developers will use a class like toolbar? Bootstrap uses the navbar class and Zurb foundation uses topbar. The AUI styleguide does use the aui-toolbar class. It's also an aria role so I feel like some overlap will happen?

I think we are fine with the current names. We made them already very unique to prevent clashes. If it still does not fit for one theme we are now able to override it with theming. That was not possible in past when this case was opened. Today we have the toolbar twig template and all is good from my point of view.

I only see one open todo. Remove the unneeded clearfix class from the toolbar. It is causing issues in my yaml themes.

In my mind '.admin-toolbar' good way. But now we have many modules which use '.toolbar' in css & js files.

* { color: green; }
ul, ol, li { color: blue; }
UL.foo, span.bar { color: red; }

I am removing the last related issue added, since it's not relevant for this issue.

The Toolbar Module was approved for removal in #3476882: [Policy] Move Toolbar module to contrib.

This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

The deprecation work is in #3484850: [meta] Tasks to deprecate Toolbar module and the removal work in #3488828: [Meta] Tasks to remove Toolbar module.

Toolbar will be moved to a contributed project before Drupal 12.0.0 is released.