Last Comment Bug 96057 - Paragraph directionality control UI in Editor
: Paragraph directionality control UI in Editor
Status: NEW
: helpwanted, rtl
Product: Core
Classification: Components
Component: Editor (show other bugs)
: Trunk
: All All
: -- enhancement with 33 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://bidiui.mozdev.org/mail/
: 125580 213149 231132 254436 (view as bug list)
Depends on:
Blocks: Persian 115711 152111 bidi_relnotes 240501
  Show dependency treegraph
 
Reported: 2001-08-20 08:31 PDT by Ilya Konstantinov
Modified: 2010-08-22 15:17 PDT (History)
27 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch v1.0, ready for reviews (44.42 KB, patch)
2002-03-28 08:02 PST, Daniel Glazman (:glazou)
no flags Details | Diff | Splinter Review
patch v1.1, in answer to Joe's comments (42.58 KB, patch)
2002-04-04 01:01 PST, Daniel Glazman (:glazou)
mozeditor: review+
Details | Diff | Splinter Review
patch final (43.69 KB, patch)
2002-04-04 08:23 PST, Daniel Glazman (:glazou)
no flags Details | Diff | Splinter Review

Description Ilya Konstantinov 2001-08-20 08:31:36 PDT
Problem:
To create a right-aligned document (e.g. a mostly Hebrew document), a user needs
to go to "Page Color and Background" and define the DIR property to be "rtl".

Solution:
Two buttons should be added to the Composer, one with an arrow pointing to the
right (for LTR) and one with an arrow pointing to the left (for LTR).

Those buttons should affect the paragraph's BiDi directionality (DIR=LTR /
DIR=RTL or the unicode-bidi CSS property).
Comment 1 Kathleen Brade 2001-08-20 14:43:05 PDT
Another work around is to go to the individual paragraphs tags and set the dir 
attribute for it via Show All Tags and the advanced properties editor.

Steps:  
 Type a few paragraphs.
 Go to All Tags mode (bottom toolbar or via View menu)
 double-click the <p> tags
 add the dir attribute with "rtl"
Comment 2 Keyser Sose 2001-08-20 18:01:37 PDT
marking NEW.
Comment 3 Zach Lipton [:zach] 2001-08-25 18:12:36 PDT
Mass-move all BiDi Hebrew and Arabic qa to me, zach@zachlipton.com. 
Thank you Gilad for your service to this component, and best of luck to you 
in the future.

Sholom. 
Comment 4 Simon Montagu :smontagu 2001-08-27 08:11:29 PDT
I would suggest also adding "Default direction" to the New Page Settings
preferences tab.
Comment 5 Daniel Glazman (:glazou) 2001-08-27 08:20:22 PDT
Hmmm, I disagree with new buttons for directionality. This 

  (a) belongs to page properties for the whole document
  (b) is an element property for local overriding

Comment for editor's ex-team : I wonder if the Advanced Properties Dialog
could have special handling for the following attributes, applied to all
elements : ID, DIR, LANG, TITLE. They could be explicitely described in the
advanced attributes panel, what do you think ?
Comment 6 Ilya Konstantinov 2001-08-27 09:06:58 PDT
I disagree (as an Israeli user who had enough experience with Hebrew editing):
directionality control must be per-paragraph and not per-page. It is likely to 
have both mostly-english and mostly-hebrew paragraphs in the same page. Also, 
they must be immediately accessed - THIS IS NOT A STYLING ISSUE WHICH CAN BE 
HIDDEN IN SOME OBSCURE DIALOGS.

Microsoft Word has such paragraph directionality buttons and I think it does 
an excellent job with it.

Also, on Windows, there are Left Ctrl-Shift and Right Ctrl-Shift to change any 
input widget's direction, keys which could be used in the Composer as well, 
but that's a different issue.
Comment 7 Roozbeh Pournader 2001-08-27 09:16:25 PDT
As a Persian speaker/writer, I agree with Ilya. We need direction controls in
the paragraph level. There is a need to switch that a lot in a single bidi document.
Comment 8 Daniel Glazman (:glazou) 2001-08-27 09:27:48 PDT
About the strong emphasis materialized by the capitals, I am often authoring
documents in both english/french and yiddish. I am not the iso-8859-1-centric
fanatic you seem to believe I am...

I agree with an easy way to see/change dir ; I disagree with an overload of
the toolbar with buttons (I am not talking of other UI means) achieving this
feature. 
Comment 9 Shoshannah Forbes 2001-12-31 07:53:25 PST
Francly, I do not see any other way to have those controls accecible enugh for
use without haveing them on the toolbar- It would be a real paint to go into the
menu each time I want to set the directionality of the paragraph.
Every editor that knows how to deal with Hebrew properly puts those controls on
the toolbar: Nisus for Mac, front page express (now discontiniued, leaving a gap
since it was the only WYSIWYG html editor that was actaully aware of Hebrew),
Qtext for windows, Dagesh, etc etc.
As you can see from the partial list above- having those buttons on the toolbar
is quite cross-application and cross platform. That is another reason IMO that
we should have them there- if they are not there, I wonder how many users who
need the option will know it even exsits?
Comment 10 Shoshannah Forbes 2002-01-02 06:23:12 PST
Also, what about objects like lists and form elements? user should be able to
defined them as rtl esaly
Comment 11 Kathleen Brade 2002-02-15 06:51:14 PST
*** Bug 125580 has been marked as a duplicate of this bug. ***
Comment 12 Shoshannah Forbes 2002-03-27 00:23:55 PST
Any progress here? I have been receving several emails from users wondering how 
to set paragraphs to RTL in composer- it is a shame that:
1. Many users who need this feature are unable to find it on there own
2. There is no easy answer to give them.

After all, people who use composer to create web pages, almost by defenition 
are not fluent in HTML.
Comment 13 Daniel Glazman (:glazou) 2002-03-27 05:56:13 PST
yes, there is (hidden) progress : this is almost ready in my own tree but I had
to stop further work on it due to moz1.0 bugs.
Comment 14 Daniel Glazman (:glazou) 2002-03-28 08:02:11 PST
Created attachment 76568 [details] [diff] [review]
patch v1.0, ready for reviews


I have finished this work on my personal time, because I personnally consider
this fix as important for a 1.0 milestone, in the perspective of Israeli and
Arabic markets. I'll leave the readers of this comment try getting a nomination

for it.

The patch adds direction control (a) in composer preferences (b) in mail
compose preferences (c) in page properties in Composer (d) in Format menu
in both Composer and mail Compose.
The menu is always contextual to the selection, as the other Composer's UI 
controls are. 

Oh, and if I tell you that this patch is CSS safe and adds the CSS 'direction'
property in a STYLE attribute instead of a DIR attribute when the CSS pref
is checked, will you believe it ?-))))

/* enjoy */
Comment 15 Kathleen Brade 2002-03-28 10:12:05 PST
nominate for nsbeta1
Mike Kaply--Daniel is going to be on holiday until next Tuesday, can you check
this in once it gets reviews, etc.?
Comment 16 Simon Montagu :smontagu 2002-03-29 09:22:46 PST
brade: would you like to own this? nsbeta1 bugs not assigned to @netscape.com
addresses can slip through the triage net.
Comment 17 Joe Francis 2002-04-03 08:16:16 PST
I have partially reviewed this and talked with Daniel about my findings.  I'm
awaiting a new patch before I can complete the job.
Comment 18 Daniel Glazman (:glazou) 2002-04-04 01:01:06 PST
Created attachment 77622 [details] [diff] [review]
patch v1.1, in answer to Joe's comments
Comment 19 Joe Francis 2002-04-04 05:38:49 PST
Comment on attachment 77622 [details] [diff] [review]
patch v1.1, in answer to Joe's comments

r=jfrancis
I gave Danile some more suggestions for a final patch
Comment 20 Daniel Glazman (:glazou) 2002-04-04 08:23:37 PST
Created attachment 77647 [details] [diff] [review]
patch final
Comment 21 Simon Montagu :smontagu 2002-04-05 16:06:30 PST
I have begun testing this patch on Win2K. Composer is working well, but I had
error messages and crashes in mail. I see that there are recently fixed bugs in
that area, so I have updated my tree, but I will not have a build ready for more
tests before the end of the day. I will report further results as soon as I can.
Comment 22 Simon Montagu :smontagu 2002-04-08 12:18:57 PDT
I have now tested mail on Win2K. Everything seems to work correctly, but I have
a few issues which should be addressed, if only on the release note level.

Most seriously, I couldn't discover any way to set the global direction for a
whole mail message (equivalent to setting the direction in Page Title And
Properties from Composer) except by setting the preference for default
direction. This is awkward, because I doubt if many people write *all* their
mail in a right-to-left language.

Secondly, the default direction pref only takes effect on restart.

After restarting, the direction works fine when composing mail, but is lost when
sending, unless one chooses HTML format. I think this behaviour is reasonable
(direction for plaintext mail is another issue, see bug 119857 and
http://bugzilla.mozilla.org/show_bug.cgi?id=95371#c5) but it could be confusing.
Maybe the text in the preference dialog should add something like "(HTML mail only)"
Comment 23 Daniel Glazman (:glazou) 2002-04-11 06:47:15 PDT
Simon: thanks for testing and useful comments ; working on it to make this patch
and feature land as soon as possible.
Comment 24 Ilya Konstantinov 2002-05-04 15:45:44 PDT
1. It is possible to retain the directionaly in plain/text too, but only in
Unicode plain/text (e.g. UTF-8), since that requires Unicode directionality
zero-width characters. I think its a good idea that using those buttons will
mark the mail as "rich" and offer to send it as HTML; this "formatting" is
rather important for actually understanding the content of the message.

2. There's a need for more accessible means than an option in the Format menu.
An option in the Format menu is how you're likely NOT to access this feature.
Strip it from the menus -- it just adds more clutter.

3. Lets do it like Outlook does -- two directionality buttons on the toolbar,
both in Composer and in the Mail Composer.

4. It would be nice to have Windows / Outlook-like keyboard accelerators for it
too: LeftCtrl-Shift setting the paragraph to be left-aligned, RightCtrl-Shift
setting the paragraph to be right-aligned. Those accelerators are very
comfortable. Please lets not impose a learning curve on the users.

5. If you think my suggestions are THAT bothering for Latin-1 users, add all of
those (the toolbar buttons, the accels) only if a single pref checkbox named
"Support Right-to-Left (Arabic, Hebrew) languages" is marked. Only a single
checkbox -- trust me on this: if someone wants to edit RTL documents / mails, he
wants all of those, cause if he ever edited Hebrew documents in the last 5
years, that's how he did it (on MS Office).
Comment 25 Brant Gurganus 2002-10-13 11:38:23 PDT
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Comment 26 Kathleen Brade 2002-11-04 07:07:07 PST
unfortunately this patch needs to be updated to deal with editorshell removal :-(

Also, is a preference panel change really required?  That seems like overkill. 
I'd rather have us try to be smarter somehow.

Lastly, someday when we have configurable toolbars, we should let users add
controls for rtl/ltr on the toolbars (a separate bug if this lands soon).
Comment 27 Prognathous 2003-01-06 02:01:20 PST
There's also a third workaround which is very similar to the second one:
Click the Source tab and manually add the tags: <p dir="rtl">  </p>

Obviously, this is hardly as convenient as having toolbar-buttons for direction.
Is there any progress with the patch?

Prog.
Comment 28 Shoshannah Forbes 2003-01-06 06:25:10 PST
That workround is not good for lists or tables, unless you edit them manully,
thus, defiting the whole WYSIWG thing of composer...
Comment 29 Prognathous 2003-04-18 17:33:56 PDT
A year has gone by since the final patch was submitted. Any chance to see it 
updated and checked-in? 

Note that HTML templates are currently broken (Bug 191799), in turn forcing 
users to go through 4 different menus and dialogs before writing RTL emails. 
Unfortunately, only Mozilla-fanatics bother to do that.

Prog.
Comment 30 Kathleen Brade 2003-04-21 07:54:00 PDT
adding helpwanted keyword
We need someone to make the patch apply to the current tip.
We also need someone to (presumably) make these show/hide with the other
preferences for composer toolbar controls.
Comment 31 Simon Montagu :smontagu 2003-07-24 16:04:44 PDT
*** Bug 213149 has been marked as a duplicate of this bug. ***
Comment 32 Uri Dor 2003-11-16 00:04:36 PST
pls, pls, pls - let's get rid of this two-year-old bug !
Comment 33 Prognathous 2004-04-17 08:02:17 PDT
Asaf, I believe you meant to *ask* for blocking1.8a, not do *deny* it - that
should be '?' rather than '-'. More on flags here:
http://bugzilla.mozilla.org/flag-help.html

Prog.
Comment 34 Prognathous 2004-04-28 09:40:56 PDT
*** Bug 231132 has been marked as a duplicate of this bug. ***
Comment 35 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2004-04-30 09:59:51 PDT
review flag is missing for "Patch final"
Comment 36 Tsahi Asher 2004-04-30 11:38:02 PDT
(In reply to comment #35)
> review flag is missing for "Patch final"

that's because this patch is so old, bugzilla didn't have the review flag when
it was submitted. doesn't it need to be updated?
Comment 37 Prognathous 2004-04-30 13:13:03 PDT
The patch has already become bitrotted a couple of years ago. See comment 26.

As far as I remember, the patch author (Glazou) is nowadays against BiDi UI in
Mozilla. It clutters the menus or something.

Prog.
Comment 38 Tsahi Asher 2004-04-30 13:36:23 PDT
that's not what he wrote here:
http://www.mozillazine.org/talkback.html?article=4521#1 .

daniel, as module owner (at least according to
http://www.mozilla.org/owners.html), what is your position on this?
Comment 39 Daniel Glazman (:glazou) 2004-04-30 14:11:36 PDT
(In reply to comment #38)

> daniel, as module owner (at least according to
> http://www.mozilla.org/owners.html), what is your position on this?

Writing direction control UI will be in Nvu 0.3, as promised.
Comment 40 Prognathous 2004-04-30 14:28:19 PDT
(In reply to comment #39)
> Writing direction control UI will be in Nvu 0.3, as promised.

I stand corrected. Thanks for working on this!

Prog.

Comment 41 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2004-05-01 04:51:59 PDT
(In reply to comment #39)
> (In reply to comment #38)
> 
> > daniel, as module owner (at least according to
> > http://www.mozilla.org/owners.html), what is your position on this?
> 
> Writing direction control UI will be in Nvu 0.3, as promised.
> 

And what about a solution for those of that still using the suite (or a platform
without an offical build of Nvu)? :-)
Comment 42 Daniel Glazman (:glazou) 2004-06-02 04:59:29 PDT
Working on it now.
Comment 43 Prognathous 2004-07-19 17:19:00 PDT
Daniel, if you need any help in testing this, just ask. 

Meanwhile, you might want to check the progress of directionality control in
Chatzilla (Bug 250864). It would be nice to have consistent BiDi UI across
Mozilla components.

Prog.
Comment 44 Daniel Glazman (:glazou) 2004-07-20 01:54:40 PDT
proganthous: please see Nvu 0.30 release. Bidi control is included.
Comment 45 Tsahi Asher 2004-07-20 02:00:23 PDT
yes, but we would like to see it in Composer too :)
Comment 46 Jo Hermans 2004-08-05 12:01:19 PDT
*** Bug 254436 has been marked as a duplicate of this bug. ***
Comment 47 Uri Bernstein (Google) 2006-01-21 05:30:13 PST
This is clearly a SeaMonkey/Composer issue, not a layout issue.
Comment 48 Eyal Rozenberg 2006-03-15 14:20:58 PST
Whoa, just noticed this bug...

this issue is addressed by the BiDi Mail UI extension:

http://bidiui.mozdev.org/mail/

One the migration to toolkit happens, we might consider integrating some of that code into the trunk.
Comment 49 Eyal Rozenberg 2007-06-24 01:09:14 PDT
I suspect the last patch is bitrotten, plus, AFAICT it doesn't distinguish between document direction and paragraph direction. There are also several issues with the editor which need to be resolved before proper direction control can be implemented, which have come up over the last few years as bugs for BiDi Mail UI, and need to be addressed as part of the addition of directionality control to the editor:

https://www.mozdev.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=bidiui&component=General&component=Mail&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&query_based_on=Open+BiDiUI&field0-0-0=noop&type0-0-0=noop&value0-0-0=

- paragraph mode vs body text mode as default
- auto-reversion to body text mode in some cases
- persistence of various aspects of style when changing from paragraph mode to body text mode and vice-versa, or when saving and re-editing a draft
- Ctrl+RShfit,Ctrl+LSfhit still not usable
- events missing for various state changes / button presses

Some other issues have come up but these were solvable on the JS level; they might have better solution if one tinkers also with the C++ under the hood of various interfaces.

Anyway, SM is almost toolkitized now, maybe the integration of BiDi Mail UI with the trunk is a viable option.

Note You need to log in before you can comment on or make changes to this bug.