Remove [dir] selectors

[LFFATE]

Hello everyone! Thank for your library, but i can't it use for now 😟
For what purpose some styles transformed to selectors with leading [dir] or [dir=ltr]?
Is it possible to leave original style with appended rtl rules?

Because there is some issues, for example, i'm using MUI with build-in jss styles and rtl.
So, also I use some styles from Bootstrap and at my css there is structure like this:
bootstrap.css

fieldset {
  border: 0
}

mui styles

.Mui-some-class-for-fieldset {
  border: 1
}

so by css rules - last with more weight. Class has more weight than tag selector. All is ok aaand
after postcss-rtl I have:

[dir] fieldset {...}
and .Mui-some-class-for-fieldset {}

So it breakes everything because now [dir] fieldset has more weight than mui selector. How a developer can predict all of this during develop?

I think it's not good to reassign selector`s weights for default direction.

[evilaliv3]

In the GlobaLeaks project actually we have the same requirement. Is there an option for making this?

This is actually very useful to simplify customizations over the generated library.

In fact suppose that a project is using a certain library (e.g. boostrap.css) and have already a customization well writtend to support rtl (e.g. customization-over-bootstra-with-rtl-support.css).
After using the current version postcss-rtl probably the customization wont work anymore because you will have added [dir] in front of every css directive. With the suggestion by @LFFATE instead the customization would likely continue to work. What do you think?

[LFFATE]

@evilaliv3
There is the option:

addPrefixToSelector: Custom function for adding prefix to selector. Optional. Example:

function addPrefixToSelector ( selector, prefix ) {
return ${prefix} > ${selector} // Make selectors like [dir=rtl] > .selector
}

with the notice:

note: the returned string must include prefix to avoid an infinite recursion

So I ignored it and my quick workaround:

...
       use: [
          {
            loader: 'postcss-loader',
            options: {
              plugins: function () {
                return [
                  require('postcss-rtl')(
                    {
                      addPrefixToSelector: function addPrefixToSelector ( selector, prefix ) {
                        if (prefix === '[dir]' || prefix === '[dir=ltr]') {
                          return `${selector}`
                        }

                        return `${prefix} ${selector}`
                      }
                    }
                  )
                ]
              }
            }
          }

And as a side effect I got some styles duplicated. Something like

.selector {
  padding-left: 2rem;
  padding-left: 2rem;
}

But looks like it works in general

[evilaliv3]

Thats nice @LFFATE thank you.

@vkalinichev do you have any suggestion on how we can improve this result removing this duplication effect? Do you consider this the only solution or do you have any other good solution that could work in our case? Thank you!

[evilaliv3]

@LFFATE: By any chance, have you found any alternative?

[LFFATE]

@evilaliv3 no, I'll try to wait for answer from @vkalinichev

[evilaliv3]

I see, thank you anyway

[PaquitoSoft]

We're facing this same issue and the @LFFATE alternative is a way to go but duplicate rules is a little problem for us.
Hope to see any update regarding a more performant solution.

[evilaliv3]

@vkalinichev : what do you think?

[fabercancio]

@LFFATE,

As a workaround, you can use the rtl:ignore directive to ignore a single rule or to ignore multiple of them.

Your workaround of creating an override of the main rule can create issues like this one (In rtl, there will be left and right properties at the same time). Or this one (in ltr the border-leftproperty is overridden).

[evilaliv3]

Thank you @fabercancio , but actually this wasnt the main goal of the ticket.

The main need is to make it possible to add only rules related to RTL without changing any existing CSS.
This in fact complicate the whole CSS in many situations like the one exposed in #64 (comment)

Do you have any advice on this?

[fabercancio]

@evilaliv3 I know that this is not the purpose of the ticket, I brought just a workaround to avoid adding [rtl] for certain rules. I think that it is possible to do what you are proposing, the only thing is that it has some pitfalls like the ones that I described or some examples that can be found on the section Override CSS on the rtlcss library.

[evilaliv3]

I see, thank you for the clarification. I guess we are stuck waiting for the suggestions by Vladimir Kalinichev and the evaluation for the possibility to make a patch to the library.

In my opinion the library could assume that the default is RTL and dont ass [rtl] to any of the rtl roules. @vkalinichev do you thins this could be done? even just a config flag for setting the default and apply this change if the user has specified it would be great!

[dzearing]

FWIW just to add to this issue; we've been evaluating this plugin and we're blocked on using this as well. For us it creates large bundle regressions. Most css has very few asymmetrical scenarios, but has plenty of symmetrical cases:

.r { margin: 0; }
.r { border: 1px solid color; }
.r { left: 0; right: 0; }

None of these should be affected as they're all symmetrical, but the plugin adds a bunch of bloat to the output unnecessarily. I took a look at the tests and see that it's validating that the [dir] prefix is added to directionally sensitive things.

Is there any reasoning for adding the dir prefix and modifying symmetrical rules at all? I'm assuming it's a specificity related thing like make all directional rules at least 2 levels of specificity so that they can be predictably overridden, maybe?

The workaround mentioned above would work, but the duplication fights against bundle size as well.

Could the [dir] prefixes be removed? Accepting PRs?

[evilaliv3]

I thinks so @dzearing and i may support with retesting;

I'm experienced with testing and packaging, in the meantime we could eventually fork the project while the patch gets officially loaded in.

[LFFATE]

FWIW just to add to this issue; we've been evaluating this plugin and we're blocked on using this as well. For us it creates large bundle regressions. Most css has very few asymmetrical scenarios, but has plenty of symmetrical cases:

.r { margin: 0; }
.r { border: 1px solid color; }
.r { left: 0; right: 0; }

None of these should be affected as they're all symmetrical, but the plugin adds a bunch of bloat to the output unnecessarily. I took a look at the tests and see that it's validating that the [dir] prefix is added to directionally sensitive things.

Is there any reasoning for adding the dir prefix and modifying symmetrical rules at all? I'm assuming it's a specificity related thing like make all directional rules at least 2 levels of specificity so that they can be predictably overridden, maybe?

The workaround mentioned above would work, but the duplication fights against bundle size as well.

Could the [dir] prefixes be removed? Accepting PRs?

without [dir] (and such) prefixes you can use some postcss plugins like this one: https://www.npmjs.com/package/postcss-discard-duplicates