Skip to content
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 #63

Closed
anefzaoui opened this issue Dec 15, 2017 · 2 comments
Closed

RTL Support #63

anefzaoui opened this issue Dec 15, 2017 · 2 comments

Comments

@anefzaoui
Copy link

(Please excuse my poor English as I'm not a native speaker :) )

So I opened this issue to sort of explain what I'm working on in a Pull Request I'm going to push soon.

RTL support is already at a great level on the CSS level which is awesome! However the framework depends on Bootstrap which is famously known for ditching RTL support despite continuous efforts from the community to add it. So there are many additional Bootstrap plugins adding RTL which is nice, however most maintainers get tired and those plugins get outdated fast.

So the solution I came up with was to ditch horizontal gravity classes that are coming from bootstrap and replace them with dynamic classes.

Let me explain:

Basically horizontal gravity classes are the ones ending with -left and -right, and their job in bootstrap is solely add text-align:left and its counterpart. They come in different sizes and shapes like text-left, text-sm-left, text-lg-left, etc...
I am not sure why do they have multiple names since their job is to add the one same line of code that is of text-align.

So, I removed those from the HTML and replaced them with the dynamic gravity classes. Those are ones that has start and end keywords. The idea is inspired from CSS3 spec that advises to use start and end keywords instead of left and right because they add better RTL support. How?

Well, left will always be left in LTR and RTL contexts, however the keyword start in LTR refers to the left side of the screen, while refers to the right side in case of RTL (since RTL is a right-to-left script language). and vice versa with the end keyword.

There's a little more to it so I'll update this issue as I make progress and when ultimately pushing a PR.

Thanks

@anefzaoui
Copy link
Author

Although I'm seeing some snippets that are a bit confusing to me if someone could explain :)
screen shot 2017-12-15 at 1 32 58 pm
In this example both left and right text aligns are called.

According to bootstrap

.text-left {
  text-align: left !important;
}
@media (min-width: 768px) {
...
  .text-md-right {
    text-align: right !important;
  }
...
}

So in screens larger than 768 pixels wide they overlap and given both are being attributed as important it puts lessens the performance while the engine tries to render both and assign priorities.

I'm sorry I'm sure I see how this lines up? :) Thanks!

@dianaprajescu
Copy link
Contributor

Although using start and end for the text-align CSS property seems like a good idea for RTL, the browser support for these keyword values is not so good. We believe it is more important to have a product that works the same cross-browser than to have a product that works only in some browsers.

Bootstrap classes used for alignment don't have multiple names for the same purpose. They do indeed set the same CSS property, but for different breakpoints. When designing a responsive website, having it look good on mobile is at least as important as how it looks on desktop. What looks okay when aligned to the right on a desktop device may not look okay on mobile. For this reason the classes text-left text-md-right are being used.

It's true that between some breakpoints the rules overlap, which is not ideal, especially for performance, but this is why Bootstrap and the Froala Design Blocks are built mobile first. Since mobile devices are smaller and have lower performance than a desktop, the overlap will happen on the device which is more likely to have more resources.

Froala Design Blocks is currently using Bootstrap and it is best to keep it the way it is, without ditching and replacing basic rules from the project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants