Skip to main content

Search and Top Navigation

#6820 open bug ()

Opened January 06, 2011 07:43PM UTC

Last modified July 14, 2014 06:25PM UTC

appendText wrongly follows isRTL

Reported by: aneves Owned by:
Priority: minor Milestone: none
Component: ui.datepicker Version: 1.8.7
Keywords: Cc:
Blocked by: Blocking:



In a nutshell

dir="rtl" on HTML + isRTL: true, appendText: "dd/mm/yyyy on datepicker = appendText before input.

(Before is on the right, for RTL.)


The same seems to happen if direction is set using CSS.

A solution would be to simply output the appendText afterwards.

But that might frustrate existing assumptions of behaviour.


I work developing a multilingual website, user picks his language and everything is translated.

When user selects arabic, I define in my HTML's opening tag the property ''dir="rtl"''.

This makes content flow properly from right to left.


I define isRTL :true for my datepickers when language is arabic, most content flows from right to left properly.

However the appendText content is writen to the page before the input.

Because both the text and the input are inline, the dir="rtl" set on the page makes the appendText appear before the input and not after as intended.

(For arabic, before is on the right.)


That's the culprit.

I think setting dir="rtl" on the parent of the datepicker would potentially have side-effects, since that parent isn't generated by the datepicker... so I guess the thing to do is to just output the appendText afterwards and let the HTML dir="xyz" rule the relative position of the inline elements.


Attachments (0)
Change History (4)

Changed October 11, 2012 02:43PM UTC by scottgonzalez comment:1


Changed October 18, 2012 12:13AM UTC by mikesherov comment:2

_comment0: This is confirmed. \ \ These lines should always use `after` and `nextSibling` and let dir="rtl" take care of it, like the rest of the code does: \ \ \
status: newopen

Changed June 24, 2014 11:46PM UTC by scottgonzalez comment:3

milestone: 1.11.0none

Changed July 14, 2014 06:25PM UTC by scottgonzalez comment:4

See also #7128