problem with RTL code generation

[ghost]

Describe the bug
Hello. according to the well written Quasar documents, to support RTL mode, language pack and RTL flag must be added to the config file.
as i was reading this repository issues I found out that 'rtlcss' module was taking responsibility for adding RTL converted code and i couldn't find anyway to configure it. i am developing a first RTL website (mainly rtl with no ltr support in mind) and i dont need this module to generate any code for me. but i cant set the RTL flag ( in the config file ) to false, because the components visual behavior depend on it. there is a way to disable one css rule at a time but, adding this "ignore rule" to every line of the code is frustrating.
is there anyway to disable this code generation but still keep the RTL behavior of the components ?
Thanks in advance :)

To Reproduce
Steps to reproduce the behavior:

1. Follow Quasar RTL support guide
2. add margin-left to an element (developing a RTL website)
3. margin-left is converted to margin-right while it was not necessary

Expected behavior
There should be an option to make rtlcss module, stop generating unwanted code OR providing a new Object as the config for rtl support in Quasar.config for additional control over this convertion.

[pdanpdan]

Hello, sorry to be so late with the reply.
It would help us very much if you could do a research on rtlcss configuration options and find a way to disable it for your specific case. That would allow us to implement the required changes at framework level.
Thank you.

[Saeid-Za]

Hello, no problem at all, thanks for replying.
Actually I did some research on rtlcss dependency that is being used in quasar source code. I will try to present my findings on the matter.

Solution 1

It appears that quasar is depending on rtlcss postcss plugin rather than rtlcss itself. after reading the rtlcss and the postcss plugin documentation, I came with an idea, Ignore every lines of CSS that should not be transformed as documented in rtlcss and quasar itself.

code snipped to ignore rules as documented in RTLCSS:

.code {
  /*rtl:ignore*/
  direction:ltr;
  /*rtl:ignore*/
  text-align:left;
}

code snipped to ignore rules as documented in Quasar (SCSS version):

.my-class {
  margin-left: 10px #{"/* rtl:ignore */"};
}

one thing to note here, the css version will not work on SCSS version, somthing like this, won't work:

.my-class  {
 #{"/* rtl:ignore */"}
 margin-left: 10px
}

also, these versions won't work too, (note the scss loud comment syntax):

.my-class  {
/*! rtl:ignore */
 margin-left: 10px
}

.my-class  {
 margin-left: 10px /*! rtl:ignore */
}

probably an issue, if the scss is pre-proccesd to css, these should work too, moving on with the version described in quasar docs.

as we know, this is not practical at scale, but there was an other option in rtlcss documentation, ignore CSS rules by specifying an ignore block.

.code {
  /*rtl:begin:ignore*/
  direction:ltr;
  text-align:left;
  /*rtl:end:ignore*/
}

but this option, wont work in Quasar, and is not documented in Quasar docs. there were several closed issues on this problem too :

• CSS files as exceptions in RTL CSS files as exceptions in RTL #4800
• /* rtl:ignore */ not working when building for SSR and Cordova /* rtl:ignore */ not working when building for SSR and Cordova #2377

but, if there way a way to make this work, we would have one more problem to face. there are limitation on how we can use this "ignore block" feature. there is currently no way to ignore files, instead of css rules. on to the next solution then.

Solution 2

thinking about the problem again, I've found out that the root of the problem is one thing, quasar RTL code generation logic is based on a crucial fact, that I, as a developer, am building a web app which is LTR and also, I want RTL transformed version too.
In fact, quite opposite, my web app is written in RTL and i want LTR transformed version.
having this thought in mind, I once again, searched in rtlcss documentation, and found this:

fromRTL (default: false): assume all styles are written in RTL direction and generate corresponding LTR styles for them

so finding what I exacly wanted, I tried to apply this config. after some research on extending config of postcss plugins, I did this change on .postcssrc.js:

const rtl = require('postcss-rtl')

module.exports = {
  plugins: [
    require('autoprefixer'),
    rtl( {fromRTL : true} ),
  ]
}

hoping that this change would solve it all, after restarting quasar app, i noticed that my styles were not being wrongly modified, but quasar styles won't be transform too. so all of the quasar components returned to their original LTR mode. this behavior was expected, there is no RTL-ready version of Quasar, the styles are all being transformed by the previous config, so changing the config would conflict with behavior of quasar itself.

IMO, using ignore syntax or fromRTL is solving the wrong problem, because even if there was no limitations on that, assuming developing a RTL web app, developer is enforcing the postcss plugin to ignore files and rules, which is cumbersome and too much implicit.
the real problem is hidden in how quasar is using this plugin. rtl-postcss plugin is being applied globally and therefore, affecting developer's codebase, which should not. from the documentations:

RTL support needs to be enabled. You need to set “rtl” to “true” under quasar.conf.js > “build”. What this does is it compiles CSS for both your website/app code and for Quasar components and add corresponding RTL CSS rules automatically. Your CSS bundle will slightly increase in size due to the addition of these CSS rules.

so in this (long :D) reply, i would suggest two new solutions:

1. limit postcss config to quasar code base itself and not developer code base, so there must be a change in how quasar is using this plugin.
   2.use postcss pre-build time of quasar and generate rtl and ltr version of quasar components, then ship them to repository. this way the correct version would be applied based on dir attribute on html tag.

I think both these solutions on themselves, while solving this particular problem, would introduce a new problem.
there this nice feature, that developer can change direction of his/her web app at runtime. when quasar is not in charge of applying postcss on developer's code, there should be an extend option to tell quasar on how to apply direction change.
I'm not 100% sure on that it would definitely not work with current mechanism, unfortunately I haven't got time to explore $q.lang implementation.
Hope that these information would help solving this problem, in my 3 months of using quasar, the only thing that bugged me, was this not-wanted transformation. everything else about quasar is damn right, I really enjoy that this community is spending time towards a true vision. I would be very happy to be a part of this community and give back what I can.
Great Job Quasar !

[pdanpdan]

Hello, can you check if this syntax does work?

#{"/* rtl:begin:ignore */"}
.code {
  direction:ltr;
  text-align:left;
}
#{"/* rtl:end:ignore */"}

Meanwhile I'll try to think of something and ask for support from postcss-rtl.

[Saeid-Za]

Hi, just checked this syntaxt:

#{"/* rtl:begin:ignore */"}
.code {
  direction:ltr;
  text-align:left;
}
#{"/* rtl:end:ignore */"}

results in :

SassError: property "#{"/* rtl:begin:ignore */"}" must be followed by a ':'
>> #{"/* rtl:begin:ignore */"}

also checking this syntax:

.code {
#{"/* rtl:begin:ignore */"}
  direction:ltr;
  text-align:left;
#{"/* rtl:end:ignore */"}
}

results the same error.

[Saeid-Za]

Hello Again @pdanpdan
Thanks for opening that issue in postcss-rtl repository and pursuing a solution. correct me if i'm wrong but i think we're trying to make an exception for userland css files/rules to exclude them from wrongly being interpreted as LTR styles.
I think that way of resloving the problem, has it's own drawbacks. as I mentioned in my previous comment, this solution would cause the developer to implicitly tell the postcss-rtl that where it should apply the transformation or not. it's a bit too much implicit. and has no real advantage over individuality telling to ignore blocks or rules of css. also, there is no way of using ignore block rules right now as discussed in previous comments (I still don't now the cause of this). furthermore, we are blocked until an implementation is ready to use in postcss-rtl, and unfortunately, the contributors at postcss-rtl, aren't that active, so we would not have an implementation in near future.
thus I think the real solution should be implemented in framework itself. I still insist on the last two options that i presented.

• either use a two step transformation of Quasar framework css files and userland css files

Or

• shipping RTL and LTR version of quasar CSS files.

let me explain them a little more, so that I could express what is it that i'm thinking of.

a two step transformation

let's assume that we got a new config rule in quasar.conf.js, i'd call it 'fromRTL', meaning userland css files are RTL-first (meaning that the developer is writing his/her we app, fully in RTL - defaults to false for backward compatibility), so with this new config in mind:
Quasar CSS is always written in LTR direction. so the step that would compile Quasar LTR styles to RTL ones, remains the same. but it would only affect framework sass/styl files. I assume that this is possible by only giving the framework style files as source file to postcss-rtl. after this step, RTL version of quasar components have been generated.

a second step that would compile the userland style files (sass, scss, ...) to corresponding direction, based on fromRTL configuration rule. if nothing is provided, (fromRTL is false then) this step would cause the userland styles to be considered LTR, and RTL version of them would be generated. which is the current behavior.
but if fromRTL resolves to true, the userland styles would be considered to be written in RTL and corresponding LTR versions would be compiled.
there is a (small ?) drawback to this solution, if I, as a RTL web app developer, only want to develop my app in RTL, with no LTR support in mind, I have no choice but to bear the additional weight of LTR generated styles that would never be used.
another flag can be used to tell that no userland transformation is needed, but lets focus on one problem at a time.

Shipping separate RTL and LTR versions of Quasar styles.

by this I mean that as a build step of framework, before shipping it to register, we could use postcss-rtl on it self and generate the RTL version, and then based on the fromRTL value, we could just import quasar.rtl.css instead of quasar.ltr.css on final build.
this is the approach that many UI frameworks take. providing separate direction builds. we could further discuss on how to support backward compatibility on this.

unfortunately, this problem has a very negative effect. RTL language web apps (arabic, persian, azeri, hebrew and more) can't be developed using quasar (unless developer is only using the quasar components - no other third party components and would bear the pressure of explicitly inserting ignore rules.) I personally became engaged with this problem when i was trying to use third party tables and everything about the direction was wrong. there was no workaround or anything. i had to fallback on using quasar table instead (which i'm really happy with) but no framework is perfect and developer would one day need an other third party library that this wrong style generation would conflict with that library and making it impossible to work with (I can show some of my experiences when working with them).
i'd be happy to work on these solutions, but before that, i need Quasar contributors' comments and suggestions. is there anything I missed? or something that was not expressed clearly? is there a better solution?
looking forward to have some opinions, and again, thanks for the hard work.

[Saeid-Za]

@pdanpdan any news on this? still waiting for this to be merged, is there any problem that i could help with?

[rstoenescu]

Enhancement will be available in "@quasar/app" v2.2.0 v2.1.7 - quasar.conf.js > build > rtl: { fromRTL: true }

[firibz]

Hello, I tried these and none of them work:
(pkg quasar v2.3.3
pkg @quasar/app v3.2.3)

build: { rtl: { source: 'rtl' }, },

build: { rtl: { fromRTL: true }, },