Setting for postcss-logical to allow having logical properties with fallback

[Arkkimaagi]

What would you want to propose?

When we updated to postcss-preset-env 8.0.0, our logical properties broke.

We have Arabic and English content on the same page on few special content pages of 15k pages. Previously the logical properties did work with the [dir="ltr"] [dir="rtl"] prefix. It was not perfect, but it did work.

I went through the issues and found a few relevant, but I felt that they did not fully answer our situation:

• The issue Proposal for postcss-logical #736 looks like the one that has been implemented here, but it mentions forcing the direction being only fallback, not the only solution. Is there a way to have the logical property and the hardcoded direction both in same file with some setting we missed?
• Like issue 863 suggests having a preserve: true would allow us to have a "dumb" fallback for situations when old browsers do not support logical properties. It would not work on old browsers + arabic layout, but it would not break as bad as just using pure logical properties would and it would work on two different contents on same page for most current browsers (iOS14.x is our only major group with no logical property support).
• We basically have same issue as 832, but you surely can understand that since we have both English and Arabic content on same page, compiling same file twice does not work.

So, is there some setting that would allow us with Arabic and English content on same page to use logical properties and fallback to non-logical properties either with [dir="ltr"] and [dir="rtl"] or without them?

Suggested solution

Some postcss-logical related setting that would allow having logical properties and a "dumb" fallback at the same time, so that we could have two different direction languages on same page.

Additional context

No response

Validations

• Follow our Code of Conduct
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Would you like to open a PR for this feature?

• I'm willing to open a PR

[Antonio-Laguna]

Hey @Arkkimaagi

Thanks a lot for taking the time to submit such a detailed question.

Is there a way to have the logical property and the hardcoded direction both in same file with some setting we missed?

No, there's no way to do this with the current plugin.

It would not work on old browsers + arabic layout, but it would not break as bad as just using pure logical properties would and it would work on two different contents on same page for most current browsers (iOS14.x is our only major group with no logical property support).

While I agree and I see the pain this adds to your usecase, preserve just does not mean the same, having preserve means just another behaviour because you have margin-inline with margin-left and margin-right coexisting but that could mean something else in other setting which is undesired.

I see your point and while we were thinking about revamping logical we ruled out these cases as they seemed like edge cases rather than something else.

While evaluating your issue something came to mind which I'm going to discuss internally before giving any hopes. We'll get back to you

[Antonio-Laguna]

@Arkkimaagi after thinking about this thoroughly we still think we made the right move.

What we were thinking is about adding some control with comments or even with [dir]

[dir] {
  margin-inline-start: 10px;
}

/* becomes */
[dir=ltr] {
  margin-left: 10px;
}

[dir=rtl] {
  margin-right: 10px;
}

Or alternatively, we could not do anything magical and just interpret a parent rule with a selector that contains [dir=rtl] as if the plugin had received a right-to-left option.

However, our initial thought was that If you really need to support older browsers and have mixed writing modes within the same doc, you need to do it manually. Even if we add these, our initial thought remains correct.

I'm happy to change my opinion but I can't really see a clear way forward that is a good solution for all cases

[Antonio-Laguna]

@Arkkimaagi a final note, we've tracked the issues we found with logical as we know it's a controversial change. The wiki page outlines what we found: https://github.com/csstools/postcss-plugins/wiki/PostCSS-Logical-Issues

I'm hoping we can find something clever that makes this tick but so far, we don't see anything viable.

[Arkkimaagi]

For now we've fixed the postcss-preset-env version to 7 instead of 8 and we're waiting for fall of 2023 when iOS17 will be released. We're hoping that the use of pre iOS 15 Safari will drop to low enough percentage so that we can start using logical properties natively. 🤷

[romainmenke]

@Arkkimaagi You can also add the old postcss-logical version as a standalone plugin and disable the feature in newer versions of postcss-preset-env.

This allows gives you the best of both for your use case :

• latest postcss-preset-env with all the new features and bug fixes
• old postcss-logical so that you don't need to migrate to the new approach

[romainmenke]

Closing this because no action is planned at this time, but happy to re-open this if someone has a good suggestion on how we can avoid all the issues and have fallbacks :)