Not got time to check properly but this looks ok for accessibility at first glance. Needs to be reviewed by the accessibility team though.

I have tested this item ? unsuccessfully on dce6e70

After applying the patch and rebuilding npm the pr itself works great but it has a knock on impact elsewhere

before

after

After applying the patch and rebuilding npm the pr itself works great but it has a knock on impact elsewhere

Yep, we saw that a bit ago.
Changing to draft.

icomoon stuff was loaded, creating the issue with the featured columns icon.
It is now solved, but we have another issue:
The icons are very slow to load, including for all the other icons than the alerts ones.

Maybe this is due to the use of @extend in, for example

    .error,
    .danger {
      @extend .fas;
      @extend .fa-times-circle;
    }

and the fact that it is necessary if we use @extend to import fontawesome in joomla-alert.scss

We may have use a simpler

.error,
.danger {
      &::before {
        font-family: "Font Awesome 5 Free";
        font-weight: 900;
        content: "\f057";
      }

etc.

Before this PR I had the possibility to use custom language strings for custom message types
Factory::getApplication()->enqueueMessage('message my type', 'blah');

After this PR not.

both template.scss are importing already fontawesome. Why twice with this pr?

https://github.com/joomla/joomla-cms/blob/4.0-dev/templates/cassiopeia/scss/template.scss#L15-L18

@ReLater

both template.scss are importing already fontawesome. Why twice with this pr?

My test with @extend created errors when compiling as @extend can only work with selectors.
To solve this I had to load again fontawesome in the file where @extend is used.
This is why I need help from a scss expert. Will test without @extend to see how it behaves.

Before this PR I had the possibility to use custom language strings for custom message types

I guess you were always getting an info type message (blue background), with blah translated in the heading.

Here we use icons related to core types.
As blah is not a specific type, it will show without a specific icon, unless you define a css for an icon in your template css.
But the text will be correctly translated.

Example:
Factory::getApplication()->enqueueMessage('message with blah as type', 'blah');

BLAH="My custom heading text"

This brings up an important issue I have had with the way icons are currently handled. Which me'n hans are working on. Give me 24hrs to sort this out for the best solution. One thing we don't need/want is to load fa set twice.

@infograf768 for the love of god please don't mix Fontawesome with the alerts. They are and supposed to be universal (eg no dependencies and work well with any front end stack). Just copy paste these few lines of CSS from this comment: joomla-projects/custom-elements#99 (comment)

@dgrammatiko
I understand it should not be done this way as anyway the icons loading time is a no no.
But I am not sure how to apply your suggestion here.

Note: let's not forget that we have 2 ways to trigger the alerts:

1. the layout
2. the js

Therefore we do need a common resulting css for both.

Obvioulsy, it is possible to solve the issue for the layout, using a simple code similar to the one used in brianteeman@8f6c3f9
This because we do not use the h4 anymore.

i.e. adding

$icon = [
		CMSApplication::MSG_EMERGENCY => 'fas fa-times-circle',
		CMSApplication::MSG_ALERT     => 'fas fa-times-circle',
		CMSApplication::MSG_CRITICAL  => 'fas fa-times-circle',
		CMSApplication::MSG_ERROR     => 'fas fa-times-circle',
		CMSApplication::MSG_WARNING   => 'fas fa-exclamation-triangle',
		CMSApplication::MSG_NOTICE    => 'fas fa-info-circle',
		CMSApplication::MSG_INFO      => 'fas fa-info-circle',
		CMSApplication::MSG_DEBUG     => 'fas fa-info-circle',
		'message'                     => 'fas fa-check-circle',
		'success'                     => 'fas fa-check-circle',
		'danger'                      => 'fas fa-times-circle',
];

and then

<span class="<?php echo $icon[$type]; ?>" aria-hidden="true"></span>

But the problem remains for the js as I guess it is not a good idea to hardcode there these classes.

That is not correct for the reasons stated in that pr when it was closed

I think I understood Dimitris proposal. On it now.

I think I understood Dimitris proposal. On it now.

The same approach SHOULD be applied also to all the fields. Fields should be coded in such a way that Bootstrap/jQuery or Font Awesome is not a dependency... (eg icons should be a css baground-image property if you want the CMS to remain relative in terms of performance)

@dgrammatiko @brianteeman
Modified to use svg. No more issue loading time.

We now get

Have to correct a lot of scss cs, does not prevent from testing ;)

why is the background size so big?

background-image:url('data:image/svg+xml;utf8,<svg width="1792" height="1792" viewBox="0 0 1792 1792" xmlns="http://www.w3.org/2000/svg"><path fill="rgba(255, 255, 255, .95)" d="M1299 813l-422 422q-19 19-45 19t-45-19l-294-294q-19-19-19-45t19-45l102-102q19-19 45-19t45 19l147 147 275-275q19-19 45-19t45 19l102 102q19 19 19 45t-19 45zm141 83q0-148-73-273t-198-198-273-73-273 73-198 198-73 273 73 273 198 198 273 73 273-73 198-198 73-273zm224 0q0 209-103 385.5t-279.5 279.5-385.5 103-385.5-103-279.5-279.5-103-385.5 103-385.5 279.5-279.5 385.5-103 385.5 103 279.5 279.5 103 385.5z"/></svg>');

@Quy
On it.

@Quy
Should be OK now.

@N6REJ

why is the background size so big?

I picked 2 of these at joomla-projects/custom-elements#99 (comment)
Then I got the others from fontawesome svg and a bit mimicked code.

I have tested this item ✅ successfully on c39992e

Tested on win10 with FF and Edged. Just a hint for other testers: my cache was stubborn for these changes, so using a new instance of browsers is agood idea.

I have tested this item ✅ successfully on c39992e

RTC

Thanks