Closed Bug 241587 Opened 16 years ago Closed 15 years ago
Di: Set textarea direction/alignment using a combination of methods (implied, manual and contextual)
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
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.
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.
(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  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: 15 years ago
Resolution: --- → WORKSFORME
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.