Calcite-components: [Question] Should Icons be "mirrored" by default in RTL?

[macandcheese]

Currently you need to set mirrored on calcite-icon to have them swap direction, and this will only work if dir=rtl is also set or inherited from a parent. (FWIW the dev demo and Storybook has mirror vs mirrored so it's not showing up)

However this causes an issue with prop-pass-through in the case you want to, for instance, have a calcite-button icon-start="camera" be mirrored, since there's no way to request "icon to be mirrored" on the button.

So, should we just remove that prop and by default mirror icons in RTL - There are issues with this as an approach because, "AZ" or icons with numerical displays for instance, will be backwards, so open to other options.

Thoughts @Esri/calcite-components

I don't think wholesale mirroring makes sense because it is not acceptable for some icons, so I guess the question is more what is the paradigm for requesting a mirrored icon from a component that has wrapped calcite-icon

[driskull]

I don't think we should automatically mirror icons for RTL because, like you said, it really depends on the icon. Directional icons would make sense but not graphical ones.

We can have a prop on calcite-icon to flip/mirror/reverse but it should be up to the component to detect RTL and do that IMO.

[bstifle]

could be rough with something called "arrow right" and it appears left....

[driskull]

Yeah. it would be better if we just have different icons with different names rather than mirroring them with CSS or whatever.

[macandcheese]

Makes sense, I guess follow up, should we remove mirrored altogether from calcite-icon - since it's only usable directly on the icon component itself and wrapping components won't really be able to tell what icons are "safe" to mirror anyway if we were to add some pass-through prop (which we won't)?

[paulcpederson]

So it's a little more complicated:

1. Some should flip in rtl
2. Some icons (AZ, etc) should _never_ flip
3. Some icons need to flip in _some_ rtl locales, but not others.

This third case is the most confusing. The case we've ran into in Online is the question mark. In Arabic, it should flip as they have a flipped question mark character. But in hebrew, (also rtl) it should not flip. I will say in the 100+ calcite-ui-icons in our product, this is the only case where it needs to be that granular.

could be rough with something called "arrow right" and it appears left....

This is actually what you want most of the time. You build in ltr and expect it to just flip around in rtl.

Yeah. it would be better if we just have different icons with different names rather than mirroring them with CSS or whatever.

I'm not so sure. The icons lib is already pretty massive, so adding additional icon path data will just bloat it further.

[macandcheese]

Was basically trying to do this (from Google's docs on Bidirectionality) for the video component, and (in addition to our sliders not supporting rtl) realized it was currently impossible with our combination of calcite-button that has an internal calcite-icon:

[macandcheese]

Headache to even think about, but an item per icon in the JSON that denoted "mirrorable" would work that was interpreted at the calcite-icon level...

[driskull]

Ok. It sounds like the mirrored prop should stay. But it is just the component that uses the calcite-icon that determines whether to set it or not. The calcite-icon shouldn't have any RTL logic built into it.

Just remove the dir==="rtl" && here...

class={{
            [CSS.mirrored]: dir === "rtl" && mirrored,
            svg: true,
          }}

[paulcpederson]

The slider is an interesting case because if the data you're describing is numeric, you don't want to flip in rtl (numbers are always ltr). So we should probably have a "mirrored" prop on the slider as well...

[macandcheese]

I guess that could work but only in a controlled wrapping component...

For instance in calcite-video, I know that a calcite-button with icon-start="sound" should be mirrored (at least according to the Google article), but that would mean we'd need to expose a mirror-icon attribute on calcite-button that calcite-icon looked for. Which would open the door to folks setting mirror-icon on icons that shouldn't be mirrored.

Sorry for the can of 🐛

[driskull]

Sorry for the can of 🐛

We don't have to add mirrored to calcite-button. We can just slot the calcite-icon if mirroring needs to happen.

[macandcheese]

Re: slider - again from that Google article it seems like the actual time progression should remain LTR, but the volume would need to be mirrored along with the icons for volume.

[AdelheidF]

We talked to the internationalization team a while ago and they suggested that _all_ horizontal sliders in RTL languages stay LTR.

[macandcheese]

Related article - https://material.io/design/usability/bidirectionality.html#mirroring-elements

[paulcpederson]

The API on components with an icon-start and icon-end could be icon-mirror: "both" | "start" | "end"

This would enable the consuming dev to choose which ones should be flipped around. I think that is probably the most flexible option for these components that wrap icons like button and dropdown-item. That way in your example, for the play button you can choose not to flip, but for the volume indicator button you can choose to make it flip in rtl.

If we try to embed all of this flipping logic within the icon component it's going to be super weighty and unwieldy.

[macandcheese]

Going to go with the above, pretty easy add and allows flexibility for our own components or for consumers that wrap icons to position as they wish. Will remove the "needs to be RTL for mirrored to apply" from calcite-icon as well and add the above to relevant components.