author is simon@softel.co.il

ben- need code review

Copying german. Frank, I want to apply this patch and generate some screenshots. I'll get back to you here.

Actually I can't attach the patch because there aren't any strings. Frank, can you provide a screenshot or a ASCII art drawing of what this looks like? (I'd also like to see the text strings that are used)

oh my. i suggest a better UI than complicating our already over-complicated menus with more stuff the normal user never will care about. how about 1 pref panel to set all this stuff, and then be done with it?

I meant "attach a screenshot" instead of "attach a patch". oops.

>how about 1 pref panel to set all this stuff, and then be done with it? see 79676 >there aren't any strings. the dtd have been landed as in 79684

ben- download the bidi build from ftp://ftp.software.ibm.com/ps/products/warpzilla/bidi-win32-rel-11-13.zip or ftp://ftp.software.ibm.com/ps/products/warpzilla/bidi-win32-rel-12-08.zip and you can look at the "View" menu to see it. see http://www.langbox.com/AraMosaic/mozilla/ for discussion

Thanks, Frank I'll check this out this afternoon.

Sorry, I can't approve this modification to the Navigator UI. The view menu is cluttered enough as it is. Can't this stay in the preferences UI?

Come on people -- this is basic, basic stuff. It's spelt out very clearly in the UI guidelines for Windows ... Minimize the number of levels for any given menu item, ideally limiting your design to a single submenu. <http://msdn.microsoft.com/library/books/winguide/ch08b.htm> ... and for Mac. Never use more than *one level* of submenus. A submenu at the second level would be buried too deep in the interface and would unnecessarily create another level of complexity. Also, it takes more time for the user to use and peruse a hierarchical menu than a pull-down menu. It is physically difficult to use a second level of submenus without slipping off the first submenu ... Don't even *think* of doing this. <http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-90.html> (Fixing the submenu nightmare for encoding selection is bug 10999; fixing the submenu nightmare in the `Tasks' menu is bug 32502.) Now, I'd like to know: (1) how Internet Explorer can currently have bi-di support without any visible UI for this stuff, short of a direction toggle in their `View' > `Encoding' submenu (and no, I don't a blanket statement `we have better bi-di support than IE', I want details); (2) what each of these menu items are supposed to do (the fact that I can't tell what they're for, just by looking at them, is troubling in itself); (3) what effort, if any, has been put into code to set these options automatically so there does not need to be a UI for them at all.

ok, there are some UI disagreement here. Simon and mkaply- can you folks address UI design issue?

Matthew Thomas (mpt) thanks for your comment- I will let bidi folks (simon@softe.co.il and mkaply@us.ibm.com) answer you See http://www.langbox.com/AraMosaic/mozilla/ for early discussion simon- How many of these menu items are used frequently by the users between pages? Which one should we only put inside the pref but not in the menu item ?

Would one long menu be better than the nested submenus? Or would it be better to open a dialog? After discussions here we have decided to remove the character set option. This was needed when the options were originally designed, but has been obsoleted by other changes. IE doesn't have the Numeral Shape option because it takes it from the regional settings on the Windows Control Panel. (Does anybody know what happens in the Mac version of IE?) How IE manages without the other options is not my problem, luckily. The only way to change between visual and logical text is to change the encoding, which is fine if the encoding is ISO-8859-8, which exists in both logical and visual forms, but problematical for UTF-8. I agree that visual text in UTF-8 is wrong, but not everybody knows that :-) Visual textfields are necessary for gateway sites that provide a web interface to host systems with visual ordering. They are also useful for search engines, if you want to search for Bidi text which might be either on a visual or a logical site (with IE you have to reorder it in your head and type it in twice, once in each direction)

A long menu can be just as bad as a too nested menu, it all depends. I personally think it does not belong into the menu at all. Neither in this discussion nor in any of the documents listed have I seen reasoning as to why this has to clutter the view menu. I'd like to know: - what percentage of users out there does use this feature: - if only a relatively small percentage uses it should it be an optionally installable package instead of being in every install in the world? - those users who need this feature, how do they use it? - if it's not used frequently it probably does not belong in the menu at all, especially not in all it's depth, the advanced prefs might be a much more suitable place for it - if it is used frequently you'd still do not want to spill out all the options of such a complex feature directly in the menu for all to see. Instead you could the menu to add *one* item as an access point to a dialog that lets you make bidi changes and can provide some assisting text. -

Or what if this menu item was added dynamically on pages that have bidirectional content? Then the x% of users that don't need the function would never see it.

That is an interesting idea, as it addresses the issue of not bothering the majority of users that do know what it is or do not need the feature. two points though: - it doesn't answer whether a menu is the right choice at all (see my comments on frequency of usage) - disappearing menu items are not always a good choice (especially on mac where things usually get greyed out), as you put the burden on the user to figure why the item is sometimes there and sometimes isn't. Also many users remember menu items' location by relative position, so disappearing menu items near the top or middle of a menu can throw off users.

Come to think of it, one place where menus do have dynamic context based content is contextual (ie right click) menus. Maybe that could be a way to do it, if settings for this feature need to be switched frequently, like from document to document. There are accessibility issues with contextual menus though...

german, simon, you might be interested to know that i18n already had a similar issue with charset customization. Originally, it was planned as an pref window and ended up as a menu item ("View->Character Coding->Customize...") for better accessibility. A similar route might be pursued with the Bidi options, they could be accessible both through the prefs and a browser menu item. Simon's pref XUL code could be used for both cases. Adding a single menu item (and possibly context menu item, which will be neccessary because of embedding) is not too much IMHO.

If someone were to summarise the different options necessary, and why and when they are necessary, it would make it easier to design a sensible UI for bidi. We should certainly only enable whatever-it-is when bidi content is present. That's not hard. Gerv

see bug 79676 for more documentation Just want to clearify one thing. Who should be the UI designer for this and 79676, who should we work with and who can make decision? What is the process? so... we have the following setting, we need to consider put them into pref, menu, both, or none. 1. Default Direction 2. Text Type: Visual or Logical 3. Text Type for Text Field 4. Text Type for Clipboard 5. Numeral Shaping I have the following opinion: A. I think none of them need to be show up in the menu unless the page is Arabic/Hebew or UTF-8. B. I think Default Direction is a MUST in menu item for bidi pages (as A.) C. I think Text Type is a MUST in menu item for bidi pages (as A.) D. I doubt about 3,4, and 5. for MENU item. How many chances user need to switch them around? Will they switch it between web sites? IF not, then we should not put in the menu. If they will, the we need to ask how frequent wil they switch. For numeric shaping Macintosh also have Arabic Numeric shaping control panel. I am not sure IE use it or not. Should we listen to the OS control panel for Numerica shaping instead ? Why should we have this setting in our application instead of listen to the OS setting?

Frank - just to clarify: you are saying items 1-5 _must_ be set by the user and the correct setting cannot be calculated from the contents of the page itself (and/or Mozilla's current language setting)? Obviously, the more things we can work out automatically, the better. Gerv

Frank as for Netscape's UI on this feature you should talk to me, as for Mozilla UI I think probably in addition either mpt or Ben can advise you. The Details: - I would try to re-sue the OS settings wherever possible as starting defaults - Infer as much as possible automatically from the document at hand 1. the word default already implies its something that belongs into prefs right? you want to set it as to default for future use 3. - 5. if you think they should be in prefs yourself, then they should probably not go into the menu. The menu is less scaleable for large number of items and overusing the menu for all settings makes the app look unapproachable for the beginning user. Pref also are not cluttering up the top level UI.

>Obviously, the more things we can work out automatically, the better. Agree. >Frank - just to clarify: you are saying items 1-5 _must_ be set by the user >and the correct setting cannot be calculated from the contents of the >page itself (and/or Mozilla's current language setting)? no, that is NOT what I said. What I said is I think 1 and 2 is MUST to be set by the user in the per page basis- therefore, it is better to put under menu. (Again, I am not daily bidi users, I am not 100% sure about this. But that is my understanding) I am not sure about 3,4 and 5. I am not bidi users. We need real bidi users to answer that question. ABOUT DEFAULT TEXT DIRECTION (or DIRECTION) about using content to find out the setting, here is some info in html 4.1 http://www.w3.org/TR/html4/struct/dirlang.html in sectoin "8.2 Specifying the direction of text and tables: the dir attribute" >User agents must not use the lang attribute to determine text directionality. so we know we cannot use lang attribute to find out text directionality. Basically, the "default direction" is the default value while dir attribute is not specified in any part of the html. in http://www.w3.org/TR/html4/struct/dirlang.html#h-8.2 it define the dir attribute. But there are no place in html 4.1 specify what is the default value of it while it is not there. Therefore, we must have to have a UI to allow user to set the default direction of the document while the content lack of such information. In IE, the text direction menu will only show up when user visiting Hebrew/Arabic or UTF8 pages. We probably should do the same thing. ABOUT THE THREE TEXT TYPES (or should we call it DATA ORDER?) I believe the main one is also needed. But the question is when do we need it? Can we only show it while we are visiting Hebrew/Arabic/UTF8 pages ? Why IE do not have them? Can some Hebrew/Arabic user list some page which NEED this setting? List URL here, please. Why we need the two other TEXT TYPE for form field and clipboard? Can BIDI users give me some user cases ? When do you need to use the form text filed text type ? in which web application? Please list URLs. Are we trying to use with non BIDI web application - say English Netscape.net mail to read Hebrew mail? When do we need to clipboard text type? Which application do we interact with? Why do we need them ? Are we interact with both bidi application and non-bidi application- say Netscape 4.x ? Do we need these text type setting for all doucment, or just for Hebrew/Arabic/UTF8 pages ? Do we need to change the setting on per page basis? Do user usually NEED to change the numeric shaping on per page basis. (My question is not "Can they change", but instead "Do they NEED to change" in average cases.

As I said in bug 79676, this discussion needs to take place in in n.p.m.ui and n.p.m.i18n. Bugzilla is a very poor medium in which to work out a UI design for such a technically complex feature.

I wrote something about 5 in n.p.m.i18n. Should I paste it here?

mkaply- please help to drive this one.

mkaply, is this bug still valid?

We had some philosophical issues that kept this from getting done. There were arguments as to whether Bidi options should be in prefs, menus, or both and whether the Bidi options should always be there (or be an overlay) For this reason, I think this bug got put on hold. We probably need to open up the discussion again.

>We probably need to open up the discussion again. We should, as two years have past since the last comment here.

Simon, as the creator of the original patch, what is your take on the issues raised in comment #30? Prog.

Is it still the intention to land this change? People from this list: http://wiki.mozilla.org/SeaMonkey:Supporters I have added you to the CC list since now it's up to you to make the call rather than the majority of people currently CCed. Feel free to remove yourself if you find this a hassle, or just make the decision. Non-Seamonkey people: Please remove yourself from the CC list if you're no longer going to involve yourself in seamonkey-related decision making. And now for my opinion on the matter: - set document direction is already present as 'switch page direction' so we can scrap it - numeral shape, text mode in controls, text mode in clipboard - should be in prefs only - charset - I don't see what this does as opposed to the 'character encoding' submenu - text-type - this can stay, but doesn't it mean making the ISO-8859-8/-I charsets the same charset, but with different logical/visual text type? Anyway, this needs an access key even more than it does a menu item. And I would suspect it would be used infrequently (unless the two charsets I mentioned get unified).

We wouldn't even consider adding a pref or menu option that only applied to Macs to Windows and Unix builds. The same standard should apply here, Bidi support is a localization problem, not a general browser problem. It should be handled at that level.

(In reply to comment #34) Why should this not be handled exactly like the "switch page direction" item which now appears on my View menu? gShowBiDi = isBidiEnabled(); if (gShowBiDi) { document.getElementById("documentDirection-swap").hidden = false; document.getElementById("textfieldDirection-separator").hidden = false; document.getElementById("textfieldDirection-swap").hidden = false; } This way this addition to the view menu only appears on installations in which it is relevant.

(In reply to comment #35) For the same reason a Mac only item shouldn't be installed on a windows computer and then hidden. You are using resources for something that is of no benifit to the user. That little bit of code increases the footprint and it has to be processed resulting in a slighly less responsive piece of software. The general princple should allways be don't install it if it isn't needed, and it isn't needed for the vast majority of users. This one small item by itself is no big deal, but small items add up as more and more are included. You can't put everything that evryone might need in without running into problems. Very few people need Bidi, which is why I think it should be handled at the localization level so it only affects the people who need it. I simply can't see a justification for placing code on a thousand computers when it is only needed on one or two of them. At most Bidi support should be an option in the installer that is off by default so that people who don't need it don't have unnessacary code placed on thier system.

> Non-Seamonkey people: Please remove yourself from the CC list if you're no > longer going to involve yourself in seamonkey-related decision making. Not sure what does this exactly mean. Are you asking people that are not in the decision making process not to monitor bugs?!

(In reply to comment #36) > At most Bidi support should be an option in the installer that is off by > default so that people who don't need it don't have unnessacary code placed on > their system. But then what happens if someone adds BiDi support to his/her system? He/she shouldn't have to reinstall seamonkey for that. Actually, it may be the case that a person installs seamonkey just prior to configuring the BiDi support on his/her system. And think of what would happen for seamonkey packages for Linux distributions. > Very few people need Bidi, which is why I think it should be handled at the > localization level so it only affects the people who need it. Also, having this only in localized builds is a problem for two reasons: - The localized builds usually also do a lot of things many people simply do not tolerate, e.g. change the UI language to Hebrew, switch the menu bar and toolbar button positions, etc. - A lot of the seamonkey users use nightlies, not releases (unlike ff/tb users, but we don't care about them anymore right? ;-) ... ) ; they (we) would want this built by default in nightlies (but perhaps not necessarily built by default in localized-to-non-BiDi-locales builds). A final option would be to go back to having all this UI as an extension once seamonkey gets toolkitized. I wouldn't like it though... (In reply to comment #37) > Not sure what does this exactly mean. Are you asking people that are not in > the decision making process not to monitor bugs?! I was just saying that since this is a seamonkey-only bug, people who only intend to focus on ff/tb QA work should not have to get all this spam and are encouraged to remove themselves from the CC list. Of course whoever is interested is most welcome to stay...

> For the same reason a Mac only item shouldn't be installed on a windows computer > and then hidden. You are using resources for something that is of no benifit to > the user. This is faulty logic - we do this quite a bit currently; it's something CSS does very well. And your estimates of those who need BiDi are somewhat low. Several languages use it; other people may want to view it. If bidi is switched on, the BiDi options should be on the menu. Seems fairly logical to me. Gerv

(In reply to comment #34) > We wouldn't even consider adding a pref or menu option that only applied to Macs > to Windows and Unix builds. The same standard should apply here, Bidi support is > a localization problem, not a general browser problem. It should be handled at > that level. This is just not true. Many users who need to view pages in bidirectional languages have no interest in localized versions of the browser (Biblical scholars for example).

Is this request still actual?

I think this is extension fodder.

We seem to have got on OK for the last 11 years without it. If something is still needed, a different bug would be more appropriate - start with a clean slate. Gerv