Also, MobileFrontend features some more styles

@colorWarningBackground: #feb;
@colorWarningBorder: #fde29b;
@colorWarningText: #850;
@colorSuccessBackground: #e1fddf;
@colorSuccessBorder: #b7fdb5;
@colorSuccessText: #009000;
@colorErrorBackground: #fae3e3;
@colorErrorBorder: #fac5c5;

Ouch!

Yup. We have warning, error and success states would be great to consolidate all these things. First things first they'll need to be created the same way...

@Jdlrobson For me this is not about the technical creation, it's about using one set of CSS classes. That's what WMUI Base is for.

I have a requirement for displaying a warning message in Maps (for more details see T148883).

Based on the new color palette and a brief discussion with @Nirzar , here is how the message may look like:

border=Y50, text=Y70, bgColor=Y10, fontWeight=bold
border=Y50, text=Y70, bgColor=Y10, fontWeight=normal
border=none, text=Y70, bgColor=Y10, fontWeight=bold
border=none, text=Y70, bgColor=Y10, fontWeight=normal
border=none, text=Y70, bgColor=B10, fontWeight=bold

Note: I left the icon black because for now we don't really have a solution for coloring the OOjs UI icons , besides generating new files.
Another note: the warning text is there as a placeholder, and is likely to change for a more precise message.

Also, as a separate discussions, we can discuss the position of the icon in case of a longer message:

Please give your feedback and suggestions

See also MobileFrontend implementation

Here are a few collected thoughts on UI:

1. As color shouldn't be the only indicator (for accessibility reasons) it seems preferable to have an icon for these messages as well.
   1. Is it an icon on rounded background? Or do warning feature a triangle and errors an octagon or a rectangular shape?
   2. Are messages supposed to have an icon as well (example: “Log in to contribute” in MobileFrontend)?
2. Are we going to feature two types of messages, one for the general use case, for example above login, or in a form, flat and one with box-shadow on products like maps, and also not fully opaque background-color?

https://gerrit.wikimedia.org/r/#/c/324161/ is targeting at aligning .mw-echo-alert colors to M82.

Another one in Flow using the color that should be reserved for interactive elements only:

In T127405#2920531, @Volker_E wrote:

Another one in Flow using the color that should be reserved for interactive elements only:

At the time the accent color was consider appropriate for use as background color for messages. Using it only on interactive elements can be a useful cue, but I'm not sure that was already decided as the way to go or we need to refine the criteria a bit (e.g., should progress bars be blue?).

Currently a bug prevents the message to be connected to the input area as intended (framing the active interactive element as te blue borders do):

(I created a separate ticket for that: T154762 )

Ok, so in deriving a solution for the Flow message some kind of yellow background was among the discussed options as well T108762.

In T127405#2924594, @Volker_E wrote:

Ok, so in deriving a solution for the Flow message some kind of yellow background was among the discussed options as well T108762.

To add a bit of context: the goal was for the message to be (a) noticeable (to prevent you from posting anonymously by mistake) but (b) not present it in a negative way as an error/warning (since it is legitimate to post anonymously if you want to do so). I think we can explore different solutions if needed, but I think we need to preserve these two properties.

Hello, what is the progress of this task? :)

Based on what I saw further up I made a mock to discuss on.

M241 WikimediaUI: Messages (Errors, Warnings, Successes, Notices)

14

Picking parts of this up again in current work in T92026.
I agree in various points with @Hanna_Petruschat_WMDE proposal.
And have provided feedback on M241 itself, an example of UploadWizard:

There is also the JS popup notice used by the watchlist star icon and some other things, native form errors (HTML5 form validation attributes which are handled by the browser directly - try submitting a registration form with an empty password for example), edit notices (which VisualEditor hides into a weird dropdown thing and the old editor just pastes on top of everything), wikitext parse errors (they use the errorbox, but not always, I think? maybe it depends on preview vs. save?), Lua console errors (open a Module: namespace page for editing and enter something into the debug window at the bottom); AbuseFilter warnings/errors. If you want to get into templates as well then also {{error}}.

MediaViewer also has its own homegrown error page (open some image in MediaViewer, disconnect from internet, open another image on same page). Also there's the Varnish error page when MediaWiki servers are not available at all, although hopefully these days that's not shown much.

@Tgr Yes, we have several native elements, which we leave as is as the browser doesn't let us reach into the elements (optgroup cross-browser or autocomplete menus in recent Chrome as examples aside of the error styles).
This task is about the error notes which are already in place and styled by us.
There's also T113114: Make all wiki-facing error pages consistent for error page styles.

Change 517197 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[wikimedia-ui-base@master] Add user system message variables

https://gerrit.wikimedia.org/r/517197

Change 517197 merged by jenkins-bot:
[wikimedia-ui-base@master] Add user system message variables

https://gerrit.wikimedia.org/r/517197

PR at https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/209

This has been merged and is now part of Design Style Guide's Components overview.
Further amendments will be made on project-specific tasks.