-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RTL support #2114
Comments
When creating content inside the editor, you do so for a specific language, after all, you're writing text in that language. Therefore, unlike the UI of an application, the content is not expected to change direction automatically, no matter its context. This means that, if text has been set to be aligned right, it must stay right, no matter the direction context. Therefore, solutions like "start" should not even be taken into consideration. On the other hand, there is one situation where direction may have an impact and it is related to the default alignment value to display if no alignment is applied. In LTR this will be "left" while in RTL it'll be "right". If we'll even implement such default (so, for example, the proper toolbar button gets "on"), we're still talking about a UI feature. It is reasonable to say that the default should be what the user sees, not what the data tells. Therefore, I believe that such default should be calculated directly in the document view by sniffing the direction and alignment of the current selection, instead of retrieving it from the data model. |
I probably forgot to mention this. But the main reason behind this ticket is to sniff the default value as it is rendered by browser to not mess during conversions to model and to properly present UT state. So in other words inside: <p dir="rtl">Foo</p> Should have default "right" alignment (ie right alignment button will be in active state) while inside: <p>Foo</p>
<p dir="ltr">Foo</p> Should have default "left" alignment (assuming that whole content editable has LTR dir. |
Btw, let's not forget that direction can be controlled by CSS as well by the direction property. In fact, I believe that this is the property to be sniffed for default checking. It is worth checking the algorithm implemented in CKEditor 4. |
Where does the priority sit for RTL support in CKEditor 5? |
It's hard to tell. The only tickets which were reported about this were reported by us. I'm not sure if it was already mentioned to us by the community. I reported #1151 to track this feature in general. You can also contact us to check what are the possibilities to speed this up. |
Changes to the alignment feature were part of #1151. From now on, depending on the |
Some general thoughts on RTL support for Alignment feature.
As for MVP the RTL will not be supported by Alignment feature.
In RTL Alignment feature should work as with CSS
text-alignment
:The other question is how RTL will be supported by CKEditor 5 especially if
dir
attribute of elements inside edited content will bu supported.The text was updated successfully, but these errors were encountered: