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

Widgets: Add RTL support #1682

Closed
wants to merge 18 commits into from
Closed

Conversation

AhmedMustafa
Copy link

A starting point for UI mirroring support in jquery-ui.

@mention-bot
Copy link

By analyzing the blame information on this pull request, we identified @scottgonzalez, @jzaefferer and @arschmitz to be potential reviewers

@jquerybot
Copy link

Thank you for your pull request. It looks like this may be your first contribution to a jQuery Foundation project, if so we need you to sign our Contributor License Agreement (CLA).

📝 Please visit http://contribute.jquery.org/CLA/ to sign.

After you signed, the PR is checked again automatically after a minute. If there's still an issue, please reply here to let us know.


If you've already signed our CLA, it's possible your git author information doesn't match your CLA signature (both your name and email have to match), for more information, check the status of your CLA check.


/* RTL support */
.ui-accordion-rtl {
direction: rtl;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does this need to exist? The direction is already set or we wouldn't be adding this class.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is correct for the current case. But it would be required if there is a parent widget with dir ='rtl' & its child widget exists somewhere in the DOM with no dirattribute (e.g. autocomplete & menu).
I know it doesn't make any sense her, but I added it in case we need it at some point & for the mirroring support to be consistent across all the widgets.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We would never need this for accordion, so it doesn't make sense to add it.

@arschmitz
Copy link
Member

If i'm not mistaken, we don't actually need any changes to the widget or css here. Unless i'm missing something the Demo works with no changes except adding the demo.

I reverted all changes except adding the demo and it does not change the display at all.

@AhmedMustafa
Copy link
Author

@arschmitz Accordion & some other widgets don't require extensive modifications to support ui mirroring. However, a little changes should be made & in this case we have to make sure that the icons displayed correctly in rtl layout.

@AhmedMustafa
Copy link
Author

Based on your comments, Accordion doesn't need special handling to support ui-mirroring (except a minor css change).
So, I did the required changes & I am going to step to the next widget.

@@ -539,9 +542,10 @@ $.widget( "ui.autocomplete", {
// Size and position menu
ul.show();
this._resizeMenu();
var pos = this.isRtl() ? { my: "right top", at: "right bottom", collision: "none" } : this.options.position;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can't be hard-coded like this. It makes the option impossible to use.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I create _getPositionRtl: function( position ) which replace every left with right & vice versa when this.isRtl() == true ?
If so, should I put it in widget.js as it might be used within others widgets ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, you should assume the user has the option set to what they actually want.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we do anything with position, we would change the default to null, and on create, we would set a value based on the direction if the value is still null.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would be consistent with our null value options approach in other places

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The browser will not change that, but someone have to change it to be acceptable for bidi-users.
You are suggesting that the user should make the changes himself. But I prefer the changes to be made by the library.
So instead of letting every user writing another version of his app for rtl-layout, the library will do that for him by just setting dir=rtl. And he still have the ability to disable or override that behavior.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with you, we have to respect the user's choice & that is what we actually do in ltr-layout.
The user will always get what he expects in ltr-layout. But when he choose to enable mirroring(by setting dir=rtl), the library should do the magic for him with no or with minimal modification from his side.
The pros of this approach is:
1- The user don't have to write another app or make any major changes to enable ui mirroring.
2- Users don't have to have a deep knowledge about mirroring to make their apps mirrored correctly.
3- The user still have the ability to disable or override that behavoir.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The browser will not change that, but someone have to change it to be acceptable for bidi-users.

That not always true you can choose to have something in the same position regardless of your layout this is application specific and gives developers a way to force position regardless of direction if thats what their app requires.

The user still have the ability to disable or override that behavoir.

Please explain to me with your approach how you would set the position to be the same REGARDLESS of direction. As far as i can tell this is not possible with your approach. Also if someone was making a RTL first app do you really expect them to set position left when they really want right? this seems completely wrong an counter intuitive and will only lead to confusion.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's also very easy to write a plugin that does the mirroring for you. Widget functionality is never a black and white choice of the built-in or implemented as a one-off for every single user. Creating a position mirroring extension would allow users to have the mirroring logic without writing it themselves, but I still don't agree that automatic mirroring for position is correct.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right. I should revert it back.

@jzaefferer
Copy link
Member

Btw. the CLA check failed because the commit author (AhmedMustafa) doesn't match the CLA signature (Ahmed Mohamed Mustafa).

@AhmedMustafa
Copy link
Author

@arschmitz @scottgonzalez I am done here & waiting your feedback.

@arschmitz arschmitz changed the title Accordion: Adding RTL support Widgets: Add RTL support Jun 22, 2016
@ashensis
Copy link

ashensis commented Jun 30, 2016

I found some GUI mirroring issues while preparing demo for https://bugs.jqueryui.com/ticket/14477.
Specifically in demos/widget/textDir.html, the Menu, Select menu and Tabs doesn't seemto be properly mirrorred
in right column that has wrapping 'div' element with "rtl" dir attribute that apparently should suffice
to ensure the proper GUI mirroring of corresponding widgets. 9as illustrated by attached snapshot GUI_Mirroring_JQuery_widgetspng.png

@ashensis
Copy link

gui_mirroring_jquery_widgets

@AhmedMustafa
Copy link
Author

It has been a while since I receive any feedback from your side regarding this PR.
If you still convinced that some widgets don't need such a support and that the library is flexible enough to render correctly in RTL pages, then it will be great to mention that somewhere in jQueryUI documentation. This will provide the bidirectional-languages users with the support they need to mirror their pages easily & quickly.
For example, This could be part of the i18n section.

@AhmedMustafa
Copy link
Author

AhmedMustafa commented Oct 26, 2017

And for the other widgets (e.g. The Slider), I think you have to consider reviewing the code I have submitted above.
ref https://bugs.jqueryui.com/ticket/10658

@mrashad2017
Copy link

mrashad2017 commented Nov 6, 2017

Dears,
Based on AhmedMustafa comment above can you advise where to add RTL documentation. This will provide bidirectional-languages users with the support they need to mirror their pages easily & quickly. And will avoid to do the same effort and same investigation.

@mrashad2017
Copy link

Dears @arschmitz @jzaefferer ,

We do some investigation in mirroring, and we have valuable feedback to help the bidirectional-languages users with the support they need to mirror their pages easily & quickly.

This will minimize any effort to do mirroring as we can support them with code details.

Appreciate your guide to make the document in the proper format and the proper place, and may be after your review, you can reference to it in case of mirroring for bidirectional-languages users.

Attached file contain sample of our change to make mirroring
jQueryUI_mirror_document.docx

@dmethvin
Copy link
Member

dmethvin commented Aug 1, 2019

Closing as a stale branch.

@dmethvin dmethvin closed this Aug 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

10 participants