Feature: It would be nice to have a radio button choice on the preferences that would allow one to choose when using the editor/composer between using logical tags (i.e., <strong> and <em>) and physical tags (i.e., <b> and <i>) when composing to produce bold and/or italic text. If logical tags were chosen, the B button would produce "<strong>...</strong>" and the I button would produce "<em>...</em>". Some of us always use logical tags in writing pages.

moving to M20 where enhancement requests are tracked. Charley -- this is a pretty cool idea, but I'll let you determine the impact on providing such a feature.

assigning to cmanske

This is a difficult issue and I've been inclined to use logical attributes all the time. I'm not sure if we will really be able to have different rules that are pref-sensitive -- depends if Joe finishes core work first. I know the "logical" attributes are what HTML writers really should use, but B, I, and U are still quite common. A couple of points: 1. "strong" causes so much more doc size bloat as compared to "b"! 2. What do we do when we encounter <b> and <i>? Leave them if user doesn't edit that portion of doc? Convert to logical if they do edit try to extend existing <b> text (i.e., you select from within existing <b> to some text outside and press the "B" button. Whatever we do, I would still like to show "B" and "I" on the toolbar. In the tooltip (not implemented yet) for the toolbar, and in the Format Menu, we could use text like "Bold <strong>" and "Italic <em>" to tell the HTML geeks what's happening.

This bug is invalid. You shouldn't `choose between' EM and STRONG as one complete set and I and B as another. EM, STRONG, I, and B all have their own distinct purposes, and it is quite legitimate for an author to use all four in the same document. The fact that EM and I (for example) happen to have the same visual formatting in a few major browsers is irrelevant. What you really want here is UI exposure to EM, STRONG, CITE, and friends, so that users have the ability (but not the compulsion!) to use them where appropriate instead of I, B, U, S, and TT.

I agree with mpt on this. We should offer Strong, Emphasize, and other related tags in the Format Style menu. Changing summary. Add keyword helpwanted since this is M20. I'd guess this would be pretty easy for someone to do since it should be able to be done by just changing the xul and js files for the editor overlay.

As Kathy said, it seems the correct solution is to support the attributes we don't now (such as "em", "strong", etc.) by simply adding them to the Format | Text Style submenu allowing access for those who want them. If we add them directly, this menu will be really long. If we put them in submenu one more level deep (under an "Other" item), Mac will be upset for having nested menus 2 levels deep. Any comments? I don't think we need "helpwanted". If we decide this is the right thing to do, I could do it in about 10 minutes. Since we would need new strings, we should do it for M16.

Do just what you would do if this was a color submenu, or a font size submenu -- put the most useful options in the submenu, and provide access to the rest of them in the Text Properties dialog. For example, the Aphrodite menu spec (see URL) has this: | | Format menu | ----------- | St_yle ... Ctrl+Shift+Y | -------------------------------------------- | _Text Properties ... Ctrl+T | _Meaning > | _Link ... Ctrl+L | Lin_k Target ... Ctrl+Shift+L | -------------------------------------------- |... | Format > Meaning submenu | ------------------------ | . _Emphasized Ctrl+Shift+I | . _Strongly Emphasized Ctrl+Shift+B | . Ci_tation Ctrl+Shift+T | . _Abbreviation [(Previous Word)] Ctrl+, | . _Quotation Ctrl+' And all the rest of the non-deprecated character formatting elements (B, BIG, CODE, DFN, I, KBD, SAMP, SMALL, TT, and VAR) would go in the Text Properties dialog -- along with fun stuff like SUP, SUB, INS, DEL, and BDO.

We don't have a text properties dialog (at least not at the moment). I think we should just append them to the Format->Text Style menu. I'd have it something like this: Bold Italic Underline Strikethrough Superscript Subscript ------- Emphasis Stronger Emphasis Citation Abbreviation Acronym Code Sample Output Variable I'm not sure if we should add "Definition" since this could get confused with "Definition List". Also not sure about "text to be entered by the user" (kbd). I'd also consider leaving off the last 3 (especially Variable) if people think that this proposed menu is too long. Also, in response to the previous comment, I believe that big and small are available on the formatting toolbar as well as in the Format -> Text Size menu. I don't think we should support INS and DEL right now since we don't really have any other version control features. If someone really wanted to add these tags, they could do so via the "Insert HTML" dialog. Also, these are some special considerations (maybe?) since these can serve as either block-level or inline elements but not both.

I appreciate the comments about adding both logical and physical tags to a pull down menu, but I still like my idea of being able to map the buttons to either logical or physical tags depending on the user's preference. Buttons are easier to use than pull down menus, but there is no reason to clutter to interface with too many buttons. Then on the other hand, how about making a button for every command, and letting the user choose which buttons show on his or her screen?

Customizable buttons are a nice idea and can be achieved to some extent by changing the "package" (one step more involved than changing "skin"), which allows you to supply your own XUL file for the editor window, and thus it's toolbars. Toolbar customizing by adding/changing individual buttons at runtime will have to wait until the next version. We will stick with the extended menu for this release.

as mpt says above, this bug would be invalid if you wanted to change <b> to <em> or whatever. I think what you really want is toolbar customization. Could you write up a new bug about that (which will be pushed off or posted as helpwanted)? This bug has evolved too much and shouldn't continue to change...

Just for the record, from the HTML 4.0 strict DTD: <!ENTITY % fontstyle "TT | I | B | BIG | SMALL"> <!ENTITY % phrase "EM | STRONG | DFN | CODE | SAMP | KBD | VAR | CITE | ABBR | ACRONYM" >

checked in.

verified in 4/25 build.

See also bug 195050.