If this script runs right-to-left, are there any issues when handling that? Is bidirectional text adequately supported? What about numbers and expressions? Do the Unicode bidi controls and HTML markup provide the support needed? Is isolation of directional runs problematic?
GitHub issue #256
Languages: arb pes ug ur ks 1
This issue is applicable to all languages with RTL orthographies.
Style sheets need to add special rules for RTL styles if they are not supported by logical properties or values.
One approach is to create a second style sheet which, when pulled into an HTML page, overrides styles in the main style sheet with settings for RTL text. This approach is not ideal because it requires maintaining the styles in two separate locations, which can therefore get out of synch, and it requires explicit addition of a call to the second style sheet in every page that will support RTL text.
The :dir() pseudo-class avoids these issues by allowing the content author to include the RTL variations in the same style sheet as the others. However, it is not yet supported by all major browser engines.
A workaround that precedes selectors with :root[dir=rtl] selector_here can help, but :dir() is a better way forward. There also appear to be Shadow DOM implications if this is not supported.
:dir is not interoperably supported by all major browser engines.selectors-4 Describes the :dir() feature in CSS.
html5 Describes the :dir() feature in HTML.
Can I Use indicates that Gecko supports :dir(), but Blink, and Webkit do not.
This was confirmed while trying to get this to work recently.
The functionality appears to be available in Blink, but behind a flag.
This simple test below checks whether :dir() causes styling to be changed. The test currently passes for Gecko, but not for Blink or WebKit browsers.
This pseudo-class significantly improves the process of designing style sheets that can cater for both LTR and RTL pages. It is a valuable enabler for better internationalisation of the Web for the billion or so potential users of RTL scripts. This was therefore marked as Basic.interactive test, The browser supports :dir() selectors.
Blink • Webkit
WebKit now supports this selector, as well as Gecko.
GitHub issue #244
Languages: arb pes ug ks 3
This issue is applicable to all languages using a right-to-left script.
For support of bidirectional plain text, the Unicode Standard provides a number of formatting characters, which include RLI, LRI, PDI and FSI. See an explanation of how these work.
Although markup should be used most of the time in HTML pages, there are parts of an HTML document that don't support markup, such as the title element and title, alt, and other attributes. These characters can be necessary for managing inline runs of such text.
For more details, see this GitHub issue, which is being used to track this gap.
GitHub issue #217
Languages: arb pes ug ur ks 1
This issue is common to all RTL scripts, and vertically set scripts.
Adoption of logical keywords such as -start and -end, rather than -left and -right needs to be completed.
For margins, padding, block size, border colour, width & style, logical keywords such as margin-inline-start or margin-block-end are widely supported by major browsers in their simplest forms (such as those just mentioned). However, logical properties are not well supported in shorthands such as margin-block or margin-inline or the margin property. The lack of support for shorthands is significant, since they are expected to have high use.
Support for the margin shorthand is currently held up by a discussion about the appropriate syntax. See this CSS issue.
Other logical properties that are not widely supported include border radius, caption side, and float. Firefox does support border-radius and floats, but otherwise these are not supported.
See a set of test results.
These new values also need to be widely supported in editing applications.
GitHub issue #216
Languages: arb pes ug ur ks 3
This issue is common to all RTL scripts.
When strings are passed around, some applications don't receive or use information about the appropriate base direction to use for those strings when they are rendered as part of a page.
This can lead to text being incorrectly aligned, and to text within a sentence or paragraph being incorrectly ordered. Some of this can be addressed by using heuristics to detect the direction first-strongly directional character in the string, but some strings can fail such heuristics.
For example, imagine a service which retrieves book names on an English page. If the page retrieves from the database an Arabic book name that begins with LTR letters, it should look like this:
However, if just first-strong heuristics are used to decide the base direction for the inserted book name, it will incorrectly produce:
For these cases the databases or JSON files, etc., from which such strings are pulled need to contain metadata about the base direction which needs to be applied to correct the display. The appropriate direction can be communicated to the backend storage from a form input by using the dirname attribute. This indicates the base direction in force for a form control, whether it is derived from the surrounding text or set manually by the user while typing.
More:
The direction of the field is passed with the form data by Chrome and WebKit, but not by Gecko. Note that Gecko also doesn't change the computed direction of the form field when the user manually sets the direction.
Basic, because of its usefulness in ensuring correct directional display of RTL text that starts with a LTR character.i18n test suite HTML5, dirname
Gecko bug (already raised)
All 3 major browser engines, Gecko, Blink, & WebKit, now support relaying the field direction to the server using dirname. It also supports changing the computed direction of a form field when the user manually sets the direction.
