Skip to main content

Search and Top Navigation

#14477 reopened feature ()

Opened September 08, 2015 11:23AM UTC

Last modified March 15, 2016 06:35PM UTC

Support of base text direction in JQuery widgets

Reported by: shensis Owned by:
Priority: minor Milestone: none
Component: ui.widget Version: 1.11.4
Keywords: Cc:
Blocked by: Blocking:
Description

The must to have requirement to any program product from the Arabic/Hebrew customer's perspective is support for base text direction. For detailed explanation of what base text direction term means please see, for instance, pages 5-9 of the following reference document.

https://docs.google.com/document/d/1dDrSwimrQbpbXybhMYDEiJXLeeqvelnY4cc8HeCP1Nk/edit?usp=sharing

Every platform (like MS Office or Open Office) or web based (like CKEditor, IBM Docs) text editor as well as large variety of program products and platforms (like dojo) allows the possibility to specify the base text direction that impacts the display of Arabic/Hebrew text.

Te current proposal is to introduce the base text direction into JQuery widgets.

Possible candidates for support are Accordion,Autocomplete, Button, Dialog, Menu, Selectmenu,Tabs and Tooltip.

Like in dojo.dijit new option named 'textDir' is proposed to be added to JOuery UI base widget.

The every widget supporting this option will implement it's own logic to enable base text direction for its text containing elements.

I prototyped, for instance, the support for Selectmenu widget. here are the code excerpts of those steps in my sketched POC:

1. 'add 'textDir' option to base widget

$.Widget.prototype = {

.....

options: {

textDir: null,

2. Set text direction for text selection button:

_drawButton: function() {

.......

this.buttonText = $( "<span>",

......

this.options.textDir && this.buttonText.css("direction", this.options.textDir);

3. Set text direction for drop down options menu:

_renderItem: function( ul, item ) {

var li = $( "<li>" );

if(this.options.textDir) {

li.css({"direction": this.options.textDir, "text-align": "left"}); //to do 'dir' attribute GUI mirroring value instead of left

}

Attachments (0)
Change History (7)

Changed September 08, 2015 11:33AM UTC by shensis comment:1

Few more words on this subject. The possible values for base text direction support are

'ltr' (left-to-right), 'rtl' (right-to-left) and 'contextual' (meaning that either

'ltr' or 'rtl' value is used depending on the first strong(Arabic/Hebrew or English) character of

string been displayed.

Changed September 08, 2015 01:14PM UTC by scottgonzalez comment:2

resolution: → duplicate
status: newclosed

Duplicate of #11053.We're already working on this, but we do not want a ticket that prescribes an implementation right now. I'm going to close as a duplicate of #11053, but note that we already have other existing tickets for specific widgets.

Changed September 20, 2015 08:48AM UTC by shensis comment:3

Please take note that #11053 speaks of measuring performance of resolving DOM direction style while what has been proposed here is to implement text direction as property(option) on widget level irrespectivly of resolved DOM text direction, the way we got this implemented in dojo.

You mentioned, as well, they you are already working on implementation of text direction for some specific widgets , however it is unclear what are these choosen ones?

Does this mean that the global approach proposed in this ticked in considered unacceptable?

Changed September 21, 2015 07:32PM UTC by scottgonzalez comment:4

Replying to [comment:3 shensis]:

what has been proposed here is to implement text direction as property(option) on widget level irrespectivly of resolved DOM text direction, the way we got this implemented in dojo.

We prefer avoiding new options, especially if the correct information should already be present in the DOM. Hence the investigation ticket I linked to.

You mentioned, as well, they you are already working on implementation of text direction for some specific widgets , however it is unclear what are these choosen ones?

I'm not sure where I said that. The only widget that currently cares about text direction is datepicker, which is in the middle of a complete rewrite, so that's not even relevant.

Does this mean that the global approach proposed in this ticked in considered unacceptable?

It's considered undesirable, not unacceptable. We would prefer to avoid adding an option if possible.

Changed March 15, 2016 02:12PM UTC by scottgonzalez comment:5

resolution: duplicate
status: closedreopened

Reopening for further discussion.

Changed March 15, 2016 04:57PM UTC by tomerm comment:6

I am glad we can discuss the subject again. Please observe that https://bugs.jqueryui.com/ticket/14923 and https://github.com/jquery/jquery-ui/pull/1682 are talking about GUI layout mirroring (flipping around imaginary vertical axis passing in the middle of the screen).

In this specific thread we are focusing on text display as part of graphical widget. While direction of graphical layout of widget is dictated by language to which overall GUI is translated to (Arabic -> RTL layout, English -> LTR layout), direction of text is dictated by text itself and completely independent from GUI. Namely, you can still use Arabic data while interacting with GUI in English (and vice versa, you can still use English data while interacting with GUI in Arabic). That is the reason why we see GUI layout direction and text direction completely independent and orthogonal to each other.

By the way we are not alone :-) in this perception. For example Android has separate API for controlling GUI direction and text direction. The same is true for iOS, Eclipse, Dojo and others.

Would it make sense to submit a PR with sample code "fix" illustrating how this functionality is realized in the context of simple widget ? Based on this code example it would be much easier to discuss both behavior and approach for implementation.

Thanks again for reopening the ticket !

Changed March 15, 2016 06:35PM UTC by scottgonzalez comment:7

Replying to [comment:6 tomerm]:

Would it make sense to submit a PR with sample code "fix" illustrating how this functionality is realized in the context of simple widget ? Based on this code example it would be much easier to discuss both behavior and approach for implementation.

Absolutely. A PR would be great.