Style Javascript messages in the offcanvas tray

1. +++ b/core/modules/outside_in/css/outside_in.messages.css
   @@ -0,0 +1,78 @@
   +  background-color: #000;
   +  background-repeat: no-repeat;
   ...
   +  background-position: 10px 18px; /* LTR */
   

   Can be background: #000 no-repeat 10px 18px; /* LTR */

2. +++ b/core/modules/outside_in/css/outside_in.messages.css
   @@ -0,0 +1,78 @@
   +  padding-top: 15px;
   +  padding-right: 10px; /* LTR */
   +  padding-bottom: 15px;
   ...
   +  padding-left: 35px; /* LTR */
   

   Can be padding: 15px 10px 15px 35px; /* LTR */

3. +++ b/core/modules/outside_in/css/outside_in.messages.css
   @@ -0,0 +1,78 @@
   +  margin-top: 10px;
   +  margin-right: -20px;
   +  margin-bottom: 10px;
   +  margin-left: -20px;
   

   Can be margin: 10px -20px;

4. +++ b/core/modules/outside_in/css/outside_in.messages.css
   @@ -0,0 +1,78 @@
   +  border-top: 0;
   +  border-right: 0;
   +  border-bottom: 0;
   +  border-left: 0;
   ...
   +  border-style: solid;
   

   Can be border: 0 solid;

5. +++ b/core/modules/outside_in/css/outside_in.theme.css
   @@ -7,6 +7,10 @@
   +/* Using import so messages styling loads last and overrides core messages css.
   + * We can do this because all outside-in css is tightly scoped to the tray. */
   +@import url("/core/modules/outside_in/css/outside_in.messages.css");
   

   Definitely should not be doing this manually. *.libraries.yml should be sufficient to order things correctly.

Small fix on libraries.yml to pass the tests.
Screenshot in Chrome-OSX

The current message "You have unsaved changes" is an ad-hoc JavaScript error message by tabledrag.js, I would like to test it with normal drupal_set_messages messages, but I can't figure it out.

Also I tried to set form errors, to test different messages styles or multiple messages, but I can't figure it out how to do it. (Validation doesn't display in the settings tray, it will jump to a different page)

A bit of help on how to test, is welcome.

#10: Not using shorthand is intentional here. In many instances listing all properties is more readable and maintainable.

There is a fine balance between readability and maintainability of code and allowing CSS code size to balloon. In my opinion, those contributing to CSS should be able to interpret shorthand property values. As such, I advocate the following, in which exceptional declarations (e.g. in selectors having more specificity) avoid shorthand to aid readability, while overarching declarations employ shorthand to aid efficiency:

div {
  border: 2px 2px 0 4px; /* LTR */
}
div:hover {
  border-bottom: 1px;
}
[dir="rtl"] div {
  border-right: 4px;
  border-left: 2px;
}

For what it's worth, our CSS formatting guidelines have a few examples where shorthand is used generically.

+++ b/core/modules/outside_in/outside_in.libraries.yml
@@ -3,18 +3,17 @@ drupal.outside_in:
-    component:
...
-    theme:
...
+    - css/outside_in.module.css: {}
+    - css/outside_in.form.css: {}
+    - css/outside_in.table.css: {}
+    - css/outside_in.details.css: {}
+    - css/outside_in.tabledrag.css: {}
+    - css/outside_in.motion.css: {}
+    - css/outside_in.messages.css: {}

You need a string here, either 'base', 'layout', 'component', 'state', or 'theme'.

The dashes are invalid.

Here is a fix the libraries file.

@tkoleary checkout the interdiff here to see the problem that @tim.plunkett was talking about.

@corbacho nice work here. re "I would like to test it with normal drupal_set_messages messages, but I can't figure it out."

I actually don't think it is possible. This Drupal dialog system problem not a Settings Tray specific problem. I have tried adding a drupal_set_message directly to \Drupal\outside_in\Form\SystemBrandingOffCanvasForm::buildConfigurationForm and it doesn't work. The other place place I tried was force a form validation error but that actually will bring up the form outside of the dialog on a new page. Right now all the forms we have just have required field validation which will be enforced on the client side so that is probably why we didn't notice this.

I have also just tested a simple callback using dialog and this does not display drupal_set_messages either. You can checkout my test module if you are interested https://github.com/tedbow/D8-Tester goto /tester-modal-link

So I think we shouldn't worry about drupal_set_message message right now. Will change the title. We may need create a more generic follow up to deal with dialogs including modal and the tray with other messages. But since we are using the regular dialog library we should solve that there. No need wait on that to make JS messages look better though.

Presumably if we got drupal_set_message to work with the dialog library the change made here should take effect because it uses the same classes but no way to test that out.

Random test failure,ArgumentPlaceholderUpdatePathTest, back to RTBC, rinse and repeat ;)

+++ b/core/modules/outside_in/css/outside_in.messages.css
@@ -0,0 +1,66 @@
+.ui-dialog-offcanvas .messages--status {
+  background-image: url(../../../misc/icons/73b355/check.svg);
+  border-left-color: #77b259;
+}
+[dir="rtl"] .ui-dialog-offcanvas .messages--status {
+  border-right-color: #77b259;
+}
+.ui-dialog-offcanvas .messages--warning {
+  background-image: url(../../../misc/icons/e29700/warning.svg);
+  border-left-color: #e09600;
+}
+[dir="rtl"] .ui-dialog-offcanvas .messages--warning {
+  border-right-color: #e09600;
+}
+.ui-dialog-offcanvas .messages--error {
+  background-image: url(../../../misc/icons/e32700/error.svg);
+  border-left-color: #e62600;
+}
+[dir="rtl"] .ui-dialog-offcanvas .messages--error {
+  border-right-color: #e62600;
+}

Don't we need to reset the border-left-color on the rtl classes. Plus the ltr versions are missing the comment.

Here is how seven is doing something similar:

/* See .color-success in Seven's colors.css */
.messages--status {
  color: #325e1c;
  background-color: #f3faef;
  border-color: #c9e1bd #c9e1bd #c9e1bd transparent;  /* LTR */
  background-image: url(../../../../misc/icons/73b355/check.svg);
  box-shadow: -8px 0 0 #77b259; /* LTR */
}
[dir="rtl"] .messages--status {
  border-color: #c9e1bd transparent #c9e1bd #c9e1bd;
  box-shadow: 8px 0 0 #77b259;
  margin-left: 0;
}

It'd be good to have rtl and ltr screenshots given the nature of the CSS being changed.

@tkoleary I thin thi

+++ b/core/modules/outside_in/outside_in.libraries.yml
@@ -3,18 +3,17 @@ drupal.outside_in:
-    component:
-      css/outside_in.module.css: {}
-      css/outside_in.motion.css: {}
-      css/outside_in.form.css: {}
-      css/outside_in.table.css: {}
-      css/outside_in.details.css: {}
-      css/outside_in.tabledrag.css: {}
-    theme:
-      # @todo Set the group higher than CSS_AGGREGATE_THEME so that it overrides
-      #   both jQuery UI and Classy's dialog.css, remove in
-      #   https://www.drupal.org/node/1945262.
-      css/outside_in.theme.css: { group: 200 }

My guess is the test failed because you removed the "component" and "theme" levels of the libraries file. Those are needed as far as I can tell. You cannot put the resource directly under "css:"

Is this still relevant?

Closing this has duplicate of #2826722: Add a 'fence' around settings tray with aggressive CSS reset.
Since that is doing a hard-reset it has to provide default style for messages.

Changing to new settings_tray.module component. @drpal thanks for script help! :)