Open Bug 195050 Opened 22 years ago Updated 17 years ago

use STRONG/EM instead of B/I in Composer's HTML mode

Categories

(SeaMonkey :: Composer, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

People

(Reporter: glazou, Unassigned)

References

Details

User's request : be able to bind B and I buttons from Composer's format toolbar to STRONG/EM instead of B/I elements. Very low priority bug but still an valid request.
Status: NEW → ASSIGNED
Priority: -- → P5
how would this impact css mode?
This should probably be dependent on toolbar configurability bug....
See also historical bug 34894.
QA Contact: sujay → beppe
*** Bug 216548 has been marked as a duplicate of this bug. ***
> Very low priority bug but still an valid request. I don't agree about the "very low priority". Consider a web-based content management system which allows users to edit content using a WYSIWYG-editor (see http://htmlarea3beta.demo.tobias-herp.de/). Some of the users use Mozilla, others use MSIE. When changing the content someone else has written, it shouldn't matter which browser either of them has used. MSIE inserts logical tags (strong and em). When a Mozilla user tries to edit text which contains strong and em tags, (s)he can't remove them, and instead of <strong> and <em> tags <span> tags with style attributes are inserted. Mozilla is incompatible here to 1. the recommendation to use logical markup 2. the de-facto standard (MSIE was the first one [known to me] to support WYSIWYG editing, and it does it right). Ok, it might make some sense to let the user choose what type of markup (s)he wants to use. But by default 1. logical markup should be used! The current default seems to be to use styles; 2. unchanged text should be saved like it had been read As you can see on the demo page montioned above, it is possible to make the bold, italic etc. buttons to act like in a text processor: when the cursor is located in bold text, the button is pressed. This comfort should be available to those who use logical markup!
I finally found an "official" demo page for HtmlArea (besides the demo for my Zope product): http://dynarch.com/htmlarea/.
me says with module owner hat on: this should be solved in Standalone Composer by toolbar customization.
> this should be solved in Standalone Composer ... I'm not sure if I got you right: are you saying that the browser's behaviour won't be changed? > ... by toolbar customization. What about the default?
If we are discussing the "rich-text editor" feature in the browser (once known affectionately as Midas), this is a non-issue. A site that wants its users to use strong/em can send the command with "strong" or "em" instead of "b" or "i"; in this sense, Midas is fully configurable. As for Composer, it should have flexible toolbars as Daniel describes so this bug should be specific to Composer application and not the core editor.
> A site that wants its users to use strong/em > can send the command with "strong" or "em" > instead of "b" or "i"; > in this sense, Midas is fully configurable. Are you saying that Midas can use logical markup? How? Can you provide a link? When the text which is to be edited contains <em> and <strong> tags, Midas can't do nothing about this; it can't make the text look normal. If this isn't a bug, find another name for it; but it must be fixed.
regarding comment 11: If I wanted to change the demo at http://mozilla.org/editor/midasdemo/ I would change the div with the id "bold" to be "strong" (and "italic" to "em") In your own page you could do something like: document.getElementById('edit').contentWindow.document.execCommand("em",false,null); If toggling "strong" or "em" doesn't work as it should, please file a bug and assign it to me (brade@comcast); that is a separate issue. Bug 194957 is already filed about "removeformat" not working (a regression after 1.4).
> document.getElementById('edit').contentWindow.document.execCommand("em",false,null); The above doesn't work :-( It throws an exception which basically says "not implemented". The only way that seems to work currently is using execCommand("useCSS", false, false); before each call to execCommand("bold" ["italic", etc.] ...). But this unfortunately doesn't switch to semantic tags (strong, em) but to old HTML tags "b", "i", "u", etc. So, is there any way to use semantic tags (strong, em) like IE does?
Mihai Bazon (comment 13) -- that sounds like a Midas-specific problem. Please file a new bug and include (attach) an html file that shows the problem. Please cc the following people on that bug: brade@comcast.net, mkaply@us.ibm.com Thanks!
Product: Browser → Seamonkey
filed Bug 317093 according to comment 14
Assignee: daniel → nobody
Status: ASSIGNED → NEW
Priority: P5 → --
QA Contact: rubydoo123 → composer
You need to log in before you can comment on or make changes to this bug.