Closed Bug 241587 Opened 20 years ago Closed 20 years ago

BiDi: Set textarea direction/alignment using a combination of methods (implied, manual and contextual)

Categories

(Core :: Layout: Text and Fonts, enhancement)

Product:
Core
Component:
Layout: Text and Fonts
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: mozilla-bugzilla, Assigned: mkaply)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040405 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040405 Firefox/0.8

This happens, for instance, when trying to fill in a form that contains both
hebrew and English.

Usually, in hebrew (or any RTL language, for that matter) supporting
applications, text-windows have the option to be aligned in a certain way, which
can be:
1. Either by the page's context (if page is right-to-left, the form will allow
right to left only, and if page is left-to-right, the form will allow
left-to-right only) ("page is right-to-left" means <html dir="rtl">)

2. User customizable. By default, make the window aligned like the page, but,
allow the user to switch alignment by using (left)ctrl+shift (to move to ltr)
and (right)ctrl+shift (to move to rtl) upon need.

3. Smart by-context switching; If a line of text begins with a letter in a
left-to-right language (say English), the whole line will be aligned left. If a
line of text begins with a letter in a right-to-left language (say Hebrew), the
whole line will be aligned right.

4. Mixing 2+3. By default the context will be automatically guessed according to
the typed language, but, if user wishes, he can use the control keys to override
the default decision.

The preferred behavior is from last to first. Meaning, 4 would be the best, 3
afterwards, 2 afterwards, and 1 is the situation today. Some might disagree with
me about the desired way; MSIE for instance combines options 1 and 2. Perhaps
this option should be by the choice of the user in the options menu :)

Reproducible: Always
Steps to Reproduce:
1. Write in a language which is the opposite of the page context alignment direction
2.
3.
Assignee: firefox → mkaply
Component: General → Layout: BiDi Hebrew & Arabic
Product: Firefox → Browser
QA Contact: zach
Version: unspecified → Trunk
this is possibly a dupe of Bug 98160. in any case, i don't think it's a good
idea that mozilla will try to guess the correct direction. rather, it should
initially follow page direction, and then apply user preference (i.e. 1+2 in
comment 0).
I'm confirming this bug, as it sounds like a very useful suggestion. In fact,
the idea of using various methods to control directionality can be unified to a
single set of rules based on the first three methods mentioned the original report:

Method #1 is already implemented (textarea direction set according to page
direction)
Method #2 is requested in Bug 98160 (manual control of textarea direction)
Method #3 depends on the functionality of Bug 218823 (automatic/contextual
control of textarea direction)

These three methods don't necessarily have to collide. Here's an example: 

An RTL page containing a textarea is loaded, the initial direction is set as RTL
using method #1 (caret is aligned to the right) -> The user then starts to type
an English word, method #3 kicks in and the text is aligned to the left -> The
user may choose to manually switch the direction to RTL again, thus employing
method #2

Needless to say, this bug is not Firefox-only. I'm changing the summary from
"BiDi: Firefox will not align the text according to the currently used language"
to one that more closely follows the root of this suggestion: "BiDi: Set
textarea direction/alignment using a combination of methods (implied, manual and
contextual)". Feel free to further change this summary to make it clearer.

Prog.
Status: UNCONFIRMED → NEW
Depends on: 98160, 218823
Ever confirmed: true
Summary: BiDi: Firefox will not align the text according to the currently used language → BiDi: Set textarea direction/alignment using a combination of methods (implied, manual and contextual)
as i wrote, i object to trying to guess what the user wants. in most cases where
the guess will differ from the inherited direction, you will be wrong, and annoy
the user.
Automatic paragraph direction is needed in browser textareas too, see Bug
218823, comment 18.

Prog.
no it's not, see bug 218823 comment 19 :)
I don't think "first strong directionality character" rule has a place in 
plain-text TEXTAREAs, since it doesn't carry on with the submitted text. In 
other words, it misleads the user to think the direction he sees would retain 
(e.g. if he's submitting a message to an online forum), while the server most 
likely will use a static direction (LTR or RTL). 
 
Only when HTML introduces a 'direction:contextual' mode (each paragraph's 
direction according to the first strong character), which'll allow a 
non-BiDi-aware web application to output text with contextual direction, will 
there be a place for such a TEXTAREA mode. 
 
This mode is, however, relevant for MIDAS (richtext edit) controls. 
It's time to close this one.

Contextual/Main menu are fixed, as well as a keybinind (well not "native" ones,
but that is bug 98160).

I don't think we want comment 0 [3] for text-plain *editable* areas, this will
be unexpected (AFAIK only Konqueror has it) behavior to Windows / Mac users.
(In reply to comment #7)
> It's time to close this one.

I agree, though I'll let you choose the resolution ;-)

> Contextual/Main menu are fixed, as well as a keybinind (well not "native" ones,
> but that is bug 98160).

Right, wfm (or a dupe of that bug).

> I don't think we want comment 0 [3] for text-plain *editable* areas, this will
> be unexpected (AFAIK only Konqueror has it) behavior to Windows / Mac users.

I disagree with you here, but this discussion belongs in Bug 218823 (please make
sure to read the entrie bug before commenting...)

Prog.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: zach → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.