Consider RTL directions with the `placement` option

CSS has something called logical propertied, which introduces block and inline " to control layout through logical, rather than physical, direction and dimension mappings."

Also when I set display: flex to a DOM element it tidies its children elements respecting the direction of writing which can be set with CSS’s direction: rtl or the HTML’s dir=rtl attribute to any tag.

Now I used Floating UI to compute the position of the floating menu that is opened by clicking a button. This floating menu’s placement should be either bottom-end or bottom-start considering the direction of writing which may be RTL. BUT THIS DOESN’T HAPPEN.

In the above image, the menu has a placement of bottom-end but with RTL in our perception this is wrong, it is actually bottom-start.

With LTR it is just fine 👌.

[atomiks]

A couple of concerns:

1. {block|inline}-{start|end} is foreign to most devs right now; logical properties are way less intuitive than physical ones.
2. We can’t specify an alignment. This may mean we need to split this into two separate options.

For example, block-start for English is the top side. But that will just use the center alignment. block-start-start is weird syntax.

top-end right now would be:

side: 'block-start',
align: 'end',

Thinking we should actually forgo start and end and use physical properties by default and make logicalProperties a middleware which enables this behavior?

[atomiks]

Starting with a physical side and then using a logical alignment is really intuitive imo (the current API).

You avoid having to think about the direction of the alignment, for example top-right and right-top describe top-end and right-start in the current API but the latter is less confusing to me. I think handling the alignment with RTL is far more common than needing to handle writing mode directions.

I’m thinking we should support RTL by default and keep the current placement option. Handling writing modes is something the user could do themselves if needed as a middleware, because it really is an advanced use case and requires a big change to the placement options by splitting them into two.