Need a way to get BiDi dir from Range

[BenjamP]

From MS Office Team:
The Unicode BiDi Algorithm (explained here: http://www.unicode.org/reports/tr9/tr9-31.html) is used by Text Rendering engines to properly display LTR and RTL text together in the same paragraph. In short, each character has a classification (mostly L and R, plus a bunch of neutral types), and the sequence of character classifications is used to determine which runs are displayed as LTR or RTL.

Mostly what I think we would need is the ability to query, for a given character, whether its direction is LTR or RTL after the Unicode BiDi Algorithm has been applied. I don’t know where the best place to put this API would be, perhaps the Range object? Something like this:

Range.getBiDiTextDir() : int
Return value is an enum in the range (LTR, RTL, MIXED), where MIXED is returned when the Range contains both LTR and RTL characters. (The caller would need to try again with a smaller range to get something useful in this case. MIXED would never be returned for a single character.)

I have no idea if this is the best API design but I’m just hoping to get across what would be useful to us.

For context, the reason this is important to us is that while HTML has the concept of “neutral text direction” (whenever the CSS property direction: ltr or direction: rtl is NOT specified), some editors like Word do not. Every run is either marked as LTR or RTL. If we can’t correctly detect the text as it’s being typed, then we may save it incorrectly into the document, and Word will display text direction differently than what the user saw as they were typing in the browser. There are also some performance optimizations we could make around text selection if we knew where in a paragraph the text changed direction, but this is less of a compelling reason than content fidelity.

[rniwa]

Sounds to me, this is better tackled as a CSS OM feature rather than a part of selection API. Is there any reason getting the directionality of text is more important in the selected text than elsewhere in the web page?

[BenjamP]

It's primarily used in Editing scenarios, but it could be used elsewhere. I was thinking about the relationship of Selection to both Editing and Range. Do you think it should be elsewhere?

[rniwa]

I think we need to list & understand use cases to know directionality of text.

[BenjamP]

The primary one I know of is listed above. It's an editing scenario.

[Reinmar]

CKEditor currently supports only element-based settings (using the dir attribute) and according to the spec we should not mix that with the Unicode BiDi markers:

Conflicts can arise if markup and explicitly formatting characters are both used in the same paragraph. Where available, markup should be used instead of the explicit formatting characters.

I haven't worked on the BiDi support in CKEditor myself. However, I can clearly see from the code that, even support for element-based settings affects the editor performance, because tracking the direction changes (to reflect that state in the toolbar buttons) is pretty ugly. Not only we have to check every selection change, but also attribute and style changes. Furthermore, querying the direction from the DOM isn't that simple, since we have to check computed styles, or the attribute, or the dir property.

Therefore, a method for getting the text direction from a range would already be an improvement. But what would really help is an event fired whenever the text direction of the selection end changes.

[fredck]

I can imagine that text may come from different sources and then inputed into the editable in different ways. Some may use the dir attribute. Others may use Unicode features. So a generic function that would unify all this and give an easy single answer may be welcome, even if it will not let us know which strategy has been used to apply direction to the text.

I have doubts if range is the right place for it. This opens door to all kinds of range.getWhateverContentProperty methods and I don't thing that this is the purpose of the ranges API. In the other hand there is no easier DOM api point where to work on “slices of DOM”, so it may be the one and only place available for it.

As for the method name, BiDi features have always been referred either as "direction" or "dir", so a simpler name like getTextDir or even simply getDir may do the job as well.

[NorbertLindenberg]

I agree with Ryosuke that clear use cases would be useful. Ben's request sounds like Word needs a mapping from the standard Unicode/HTML bidi model to its proprietary model – my naive response would be that such a mapping belongs into Word, not into a standard. Frederico's request sounds like certain input functions should modify the input or existing content – that would belong into a spec for contentEditable, not the selection API. But in both cases it's quite possible that I'm missing something.