[4.0] [a11y] Contrast of Drop down chevron

[astridx]

Draft for Issue #28673.

Edit: To test this draft, it is necessary to use the npm ci command, as SCSS files need to be compiled.

Summary of Changes

I made it possible, that the drop down chevron on success and danger drop downs is white (not black).
For the red danger background the Contrast Ratio is even worse. It is 3.71.

When editing a module, the white arrow also fits better with the calendar symbol at start publishing.

Next you see the white chevron on a drop down with the green success background while editing a plugin. Note: The chevrons on the drop downs with the gray background are still black.

I made this as a draft, because I am not sure, if I understand the way we want to handle multiple background elements. Perhaps someone like to teach me?

[Quy]

See #28463 for hint to solve the issue.

[ciar4n]

No need to redefine these color properties in RTL (color, bg and border)

[astridx]

Thank you @ciar4n, but I need color, bg and border for rtl, as it is set for the variable
$custom-select-background-light-rtl and I have to override it.

Without

With

I could set the properties in the variable $custom-select-background-light-rtl differently. But in my opinion, this would make a bigger mess because it would be very different from $custom-select-background-rtl.

[ciar4n]

Actually I see why you might need background-color as you are re-setting the color to transparent with background: $custom-select-background-light-rtl;. The border and color should be fine without but maybe I'm missing something.

[ciar4n]

No need to redefine these color properties in RTL (color, bg and border)

[brianteeman]

I dont understand why there is a new image. I though the whole point of using an svg is that you can change its colour using css eg fill: white

[ciar4n]

I dont understand why there is a new image. I though the whole point of using an svg is that you can change its colour using css eg fill: white

Because it is a background image, it is not part of the DOM and therefore, to my knowledge, can't be changed via css. The svg will need to be added inline. Eg. https://chriswrightdesign.github.io/customforms/select-box-svg/

[brianteeman]

Thanks @ciar4n I didn't know about the background image but that makes total sense

[astridx]

Does anyone know the reason why we sometimes use FontAwesome and sometimes SVG images?

[ciar4n]

In a perfect world, they should be all the same. My preference would be inline svg. If you look deep enough, you will even find some css chevrons in the mix.

[astridx]

@ciar4n In a perfect world, they should be all the same. My preference would be inline svg. If you look deep enough, you will even find some css chevrons in the mix.

How would you do it exactly? If we enter the svg directly in the markup, we can not reuse things, right?

1. If you save the SVG in a file and load it with <?php echo file_get_contents("my.svg"); ?>, you could reuse things.

2. Or we can put the svg on the end of a page like this:

<svg>
<symbol viewBox="0 0 32 32" id="myid1"><title>youtube</title><path ../>
</symbol>
<symbol viewBox="0 0 32 32" id="myid2"><title>youtube</title><path ../>
</symbol>
</svg>

Then we can use it like this

<svg role="img" class="myclass" aria-labelledby="">
<use xlink:href="#myid1"></use>
</svg>

[ciar4n]

There have been a couple of recent PRs for the frontend views on this (#28262 & #28351)... a somewhat contentious issue.

[infograf768]

What is the advantage of using svg vs icons? As I see it, it rather makes things more complex than necessary.

[ciar4n]

Size... with SVG you just load what you need rather than an entire library (css & font). Also SVG allows us to drop in custom fonts rather than been restricted to a set library.

Regardless I think Font Awesome is fine for the backend as it is just one template that will likely be ever used. The frontend is a slightly different matter.

For this PR I think ideally we change the choices icon to Font Awesome, bringing it inline with the majority of the admin. If that is not possible, then this PR as it is fixes the issue.

[adj9]

I have not tested this item.

With and without patches, the field state arrow is always black.
This is in the plugin and in the articles.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/28680.}

[astridx]

@adj9 Thanks for your test. May I ask you: How did you test? Did you use the patch tester?

[astridx]

@ciar4n @infograf768 Thanks for your opinion. I'll look at that tomorrow.

[Quy]

Please test PR #28755