9.84 KB, image/png
10.12 KB, image/png
4.28 KB, application/vnd.mozilla.xul+xml
22.26 KB, image/png
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; 0.8.1) need ability to select from multiple signatures. I might not always want to sign my mails with "Regards". When sending to family or loved ones, it would be nice to be able to select another signature line (e.g. "Love"). Also, it would be nice to have an HTML signature for business and family. That makes a total of 4 different sigantures that should be selectable *while* composing a mail. I suggest creating a dropdown icon ("Signature") where one can choose from predefined signatures (text & HTML). Of course, one should be able to select a default signature under prefs. :)
I really want this too. But first we need a UI spec for this. ->UI: Design Feedback (BTW, bugs like this tends to be bloated with different specs, please don't do that. Let's keep this clean with useful and complete comments...)
OK, here is a good starting point (Hakan reviewed it and said i should post it here): I would suggest that in the compose window, next to the "save" icon, to place a "Signatures" icon that when clicked yields a dropdown list (similar to the "Get Msg" icon) with the signature names (e.g. Private-txt, Private-html, Business-txt, business-html) where the user can select a signature. If he just clicks the main icon, the default sig would be selected (defined in orefs). The selected signature should then be immediately visible in the body at the end. If the user changes his mind, he could select another sig at *any time* before submitting the message and the change would be shown in the body (dynamic update = tough to implement?) If a user selects an html sig in a newsgroup, a warning dialogue should come up saying "You selected a HTML signature for this newsgroup posting. Newsgroups are usuallly in plain text oly. Are you sure that...." YES/NO - ", <> "Show this dialogue in the future" In prefs, the user would be able to enter his various sigs and assign them descriptive names that appear in the icon above (e.g. Private-txt, Private-html, Business-txt, business-html). User would be able to ADD, EDIT and DELETE signatures in the prefs. Here the default sig would be set (checkbox). It would be best if the sigs were not remote files (like NC4.x), but stored in prefs.js. The sig text would be typed directly or pasted into the prefs dialogue (e.g. from composer for html).
Actually I never reviewed it. But I OK'd that you posted it here... I'll let the usability gurus review it.
plairo's use of review is ok, although we should probably use the term pre screened (i occasionally have my comments pre screened too).
mpt suggested that this is a duplicate, please help us find it.
Might be a considered dup of bug 2350, which is a RFE that you can vary the signature based on the domain of the TO field; vaguely related to bug 37644. If we're going to have multiple, named signature, I think that you should also be able to assign signature on a per adress book card. Also, the signature editing UI should show which cards any particular signature is associated with, plus have an easy way of adding and deleting cards from the association.
Bug 2350: This is a completely different bug from bug 2350, which wants sigs based on domains for company internal and external correspondence. I think this should be a *separate* bug/option. Personally, I don't like this idea because I have friends, family AND business contacts often all in one domain (e.g. compuserve.com). Bug 37644 should be dependant on this bug because it specifies how the signature selection should be. This bug requests the signature feature in general (back-end work). Actually, I would suggest wontfix for bug 37644 because it would take up too much screen space. M. Cline's suggestion: Adding a signature on a Address Book entry basis should at least be a separate bug (ENH) because it is a distinctly separate and independant way of handling sigs. I also don't think it is very intuitive and involves a LOT of setup effort by the user. My suggestion for the interface is much cleaner - have just an icon at the top (next to the "save" icon) called "Signature" that has a dropdown as follows: < SIGNATURE > |V| +--------------------------+ | Signature Preferences... | | -------------------------| | No Signature | |--------------------------| | Signature 1 | |xSignature 2 | | Signature 3 (default) | | Signature 4 | +--------------------------+ Where: "Signature Preferences..." would go to some dialogue in preferences for adding/editing/deleting and setting the default signature, much in the way "View - Apply Theme - Theme Preferences" works. "No Signature" would clear whatever signature is displayed. "x" marks the currently selected sig (this would be a check mark). "(default)" shows which signature is automatically selected if no action is taken (selected in prefs).
Most newsreaders, even some very simple ones (Free Agent, Gravity), have the ability to set default signature for usenet posts on a per-newsgroup basis. Should that be a separate RFE dependent on this one? The .sig button should be optional (since some people have used the same one signature for years), but at worst that's handled by bug Bug 15144.
"*Default* signatures on a per-newsgroup basis" has NOTHING to do with this bug. Please file a new bug.
*** Bug 112236 has been marked as a duplicate of this bug. ***
*** Bug 128853 has been marked as a duplicate of this bug. ***
Shouldn't this be in the 'MailNews' category? Could the owner of this bug please move it?
RE comment #9: A *per-account pref* for signatures might be a good idea. It could be similar to the new "Return Receipts": +-- Default Signature for MyIMAP@mozilla.org -----------+ | | | <o> use global default signature [ Peter Reaper (txt) | | | | < > use another signature for this account | | [ Business1 (txt) \/] | <--(NOTE: this is the | | *same* list as in +-------------------------------------------------------+ the global selection) Where account could be any mail account or any newsgroup account. Perhaps new signatures should only be add-/editable in the global signature settings dialogue. The global signatures preference dialogue could look like this: +-- Signature Preferences ---------------------------+ | | | Select default signature [ Peter Reaper (txt) \/] | | | |---- Manage Signatures -----------------------------| | | | [ ADD... ] | | | | [ Peter Reaper (txt) \/] [ DELETE ] [ EDIT ] | | | | +-- Preview of Selected Signature -------------+ | | | | | | | Sincerely, | | | | Peter Reaper | | | | | | | | | | | +----------------------------------------------+ | +----------------------------------------------------+ Add and Edit would bring up this: + -- Add / Edit Signature ---------------------------+ | | | Signature Name [ ] | <-- user definable names | | | ---------------------------------------------- | | < > Text only | | <o> HTML | | ----------------------------------------------- | | Type or Paste your signature below: | | [Variable Width] [Color] [Size] [B] [I] [U] | <-- grayed-out if "Text" | +------------------------------------------------+ | | | | | | | | | | | | | | | | | | | | | | +------------------------------------------------+ | | [ OK ] [ CANCEL ] | +----------------------------------------------------+
All signatures should be store in the user's profile directory in *one* file. This file (signatures.moz) would be a mish-mash of plaintext anf html code (for text AND html sigs), and would be divided into a section for each signature: +-- signatures.moz -----------------------------------+ | | | Header Info: This file contains signatures that are | | appended to to the e-mails this user sends. | | This file is generated from within Mozilla's | | preferences: | | (edit / preferences / Mail&News / Signatures) | | | | Although the signature can be edited by editing this| | file, it is strongly recommended to edit signatures | | from within Mozilla's preferences. | | | | -- Signature 1 ------------------------------------ | | SigName: Peter Reaper (txt) | | SigType: Plain Text | | Character Coding: ISO 8859-15 | <-- do we need this? | Signature Contents: | | | | Sincerely, | | Peter Reaper | | | | -- Signature 2 ------------------------------------ | | SigName: Peter Reaper (HTML) | | SigType: HTML | | Character Coding: ISO 8859-15 | | Signature Contents: | | | | <bold>Sincerely, | | Peter Reaper</bold> | | | +-- end of file --------------------------------------+ The advantages of having all signatures in one file, that is generated and maintained by mozilla (but user editable) are many --> no more browsing to looong directories for each signature, editable from within mozilla (and by manually editing *one* file), no more telling novices they must create an *external* text or (even worse) HTML file and then link to it from mozilla (talk about turning novices off - blank stare), signatures can be transported by copying just one file.
what if my unix sig is a device or the output of a program? (this isn't unusual) in this case it's unacceptable and impractical to store the 'signature' in a mozilla managed file.
> what if my unix sig is a device or the output of a program? Never heard of that (device?), sorry. Is it to create varying sigs each time you load? If so, maybe the user (or unix) could copy the entire signatures.moz file into a unix template file and have unix update a certain section in the template file (using variables?) and then just copy the updated file over the existing one. Mozilla would never know the difference. ;)
> what if my unix sig is a device or the output of a program? This edge case does not (by a long shot) outweigh the inconvenience and obstacles to the vast majority of users (novices and intermediates) in creating external files that must then be individually linked. Signaures must be manageable (create, edit, delete) from within Mozilla. Sorry. My previous comment might be a solution for these edge-case user.
*** This bug has been marked as a duplicate of 37644 ***
I don't think this bug is a duplicate of bug 37644. That bug suggests to put a bunch of UI at the bottom of each compose window with a *non-scrolling* signature. IMO that wastes a *lot* of screen space. This bug suggests a much cleaner approach: The signature appears at the bottom of the message itself (as the recipient will see it), and there is a button at the top called "Signature" where the user can select from previously defined signatures. All the Editing UI would be in the prefs and not waste valuable screenspace. see comment #8 and comment#14 Reopening for reconsideration. mpt, please assign to "nobody" if you are not interested in this solution.
12:19:42 AM: mpt begins reconsideration. 12:20:31 AM: mpt finishes reconsideration. Problems with this proposal include: (1) It would increase clutter to the composition window (in contrast with bug 37644, which would reduce clutter by hiding the signature by default). (2) It would add clutter to the prefs. (3) It wouldn't work if the signature had been mangled (e.g. the signature separator edited) before a choice was made from the menu. Wontfix.
> Problems with this proposal include: > (1) It would increase clutter to the composition window (in contrast with bug > 37644, which would reduce clutter by hiding the signature by default). One button on the Compose toolbar is hardly "clutter", especially when compared to using up the entire bottom portion of the compose window as proposed in bug 37644 (that is clutter). If even a button is considered clutter (which I could understand, because switching sig would not be that often), then a simple menu entry (under "options"?) would suffice: File | Edit | View | Options | Tools | Window | Help +---------+----------+ | ... |+---------------------------+ | Select Signature > || Personal (text) (Default) | | ... || Personal (HTML) | +--------------------+| Businsess (HTML) | |---------------------------| | No signature | |---------------------------| | Signature Preferences... | +---------------------------+ Also, in bug 37644, if the sig-pane is colapsed (which any sensible user will quickly do, because it takes up so much space), many users will forget that their sig is there and manually type in *another* sig into the main pane, thus the recipient will see two sigs. > (2) It would add clutter to the prefs. Useful features are not clutter. This *is* a very useful feature. > (3) It wouldn't work if the signature had been mangled (e.g. the signature separator edited) before a choice was made from the menu. This is a technical problem that *can* be solved. For instance: Selecting another sig woud *attempt* to identify the existing sig (e.g., via "-- ") and if found would replace it. If it cannot identify a sig, it would append the newly selected sig to the very end of the message. The user could then *see* if there are two sigs and delete the one he mangled/doesn't want (this would *only* be necessary *if* he already mangled the existing sig. Since all of mpt's objections from comment #21 are addressed, reopening for reconsideration. BTW. Outlook Express (and likely Outlook too) has this feature (Will attach screenshots in next post).
Created attachment 104504 [details] Screenshot - Signature Settings in OutLook Express I only have the German version of OE installed - sorry. But the UI and functionality should be quite clear.
Created attachment 104506 [details] Screenshot of Signature Selection UI in Compose Window of OutLook Express I only have the German version of OE installed - sorry. But the UI and functionality (and very limited "clutter") should be quite clear.
default assignee doesn't want to do this... (comment 21) -> email@example.com Reporter, your RFE looks a lot like bug 171744. If you think bug 171744 does what you want, please resolve this bug as duplicate of bug 171744 yourself. Please do not spam Bugzilla or the newsgroup. We have lots of RFEs open and it's not possible to implement all of them. Also note bug this bug was resolved as WONTFIX by the assignee of bug 37644 (so don't bug the assignee about wontfixing it either). For accessibility reason, please avoid using ASCII art to represent user interface. If possible, attach a XUL mock up (an example will be posted shortly).
*** Bug 90018 has been marked as a duplicate of this bug. ***
A lot of the work has seemingly already been done here (MozTweak): http://mozillapl.mozdev.org/installation.html although I still much prefer the UI as suggested in this bug (see comment 22).
Comment #8 Would clutter the ToolBar.... I Suggest under the "Message" menu have an option < SIGNATURE > A submenu would show +--------------------------+ | Signature Preferences... | |--------------------------| | No Signature | |--------------------------| | Signature 1 | | Signature 2 | | Signature 3 (default) | | Signature 4 | +--------------------------+ This functionality would be similar to Outlook 2000's: Insert > Signature > (Signature1, Signature2, Signature3, etc...) PS: The current method of having a custom signature for individual accounts should remain the same. Where "default" in the new menu item above would reflect the specific account.
Bruno: What good would it be to put this feature under the "Message" menu in Mail&News? The user hasn't even begun to compose a message yet! Have you even read comment #22?
*** Bug 190757 has been marked as a duplicate of this bug. ***
We're not looking for new featues in a final "cleanup and polish" cycle. Please don't waste drivers time by nominating new features in final, Peter. Thanks.
Mail Triage Team: nsbeta1-
This is very much needed if it is claimed that mozilla supports more than one pop client also there are many features which are kept independent like message filters ... why not signature ?
The current (Mozilla 1.3) design of signatures (one per account) is good but does not help the power user. I respond to hundreds of e-mails per week, and in each reply, I use several of about 20 very long "signatures". (Currently this is in Outlook Express but it is **** with crashes, freezes, etc as folders get big so I want to get away from it. That is the only feature keeping me on Outlook Express, and OE is the only program keeping my Windows partition from being reclaimed.) Now granted, these are not "signatures" in the conventional sense of a 2-10 line sign-off. For me, it is more of a pre-made reply but it does include my "Yours Truly..." sign off and I do write some personalized paragraphs before using these signatures. And isn't that really what a signature is? A pre-made bit that you don't want to retype every time. My suggestion for where to put this in the UI would be in the Insert menu of the e-mail being composed (though that is the OE influence, it does make the most sense of any of the menus, I'd say). In my opinion, any design of a multiple signatures feature should have no length limit (or say, >50kb), and the option of either having them composed/stored in Mozilla or having them be a link to external txt/html files. Again, this is the OE way, but it handles the beginners (who stare blankly when you tell them to create an html file and link to it) and the power users. It should also have a way to order your signatures in the Insert > Signatures menu.
*** Bug 201434 has been marked as a duplicate of this bug. ***
Is somebody working on this? Since 0.8.1 there is a long time gone...
when will this feature be implemented in mozila's mail/news? thomi
This would be the one thing that would get me off of Outlook. Please add this to the mail client
Get the PlugIn from Comment #29 . It's working fine with 1.5 and 1.6a :)
no-way. I'm running moz 1.5 final in XP pro and moztweak (1.2.1) broke my email. The interface is a bit too clunky too. This should be a sleek feature - simple menu access would probably be best. Like I said it broke my email so I really couldn't tell if it even worked, but I didn't get the impression that it let you use images as signatures either. ps. to uninstall moztweak search for all files containing moztweak and delete (this seems to do the trick).
This bug should also have an optional FROM field. This would solve two problems. Quite often when switching signatures, you'll want to switch your FROM: field as well. Creating "dummy" accounts is a poor/difficult hack, clutters up your accounts list and doesn't always work.
firstname.lastname@example.org: in case no one has complained to you already: additional from lines are the subject of another bug.
*** Bug 241477 has been marked as a duplicate of this bug. ***
*** Bug 241477 has been marked as a duplicate of this bug. ***
please please Please! PLEASE! I'm B E G G I N G you, won't somebody please work on this feature! This bug was opened in 2001. 2001 people! Please, I'd just like to see a way to insert a signature of my choice from a set of several signatures into a given e-mail before I die. Look at all the similar bugs that could be wiped out with some intelligent work in this direction: https://bugzilla.mozilla.org/show_bug.cgi?id=73567 https://bugzilla.mozilla.org/show_bug.cgi?id=257972 https://bugzilla.mozilla.org/show_bug.cgi?id=218903 https://bugzilla.mozilla.org/show_bug.cgi?id=222476 (dup of previous) https://bugzilla.mozilla.org/show_bug.cgi?id=257484 https://bugzilla.mozilla.org/show_bug.cgi?id=226120 (and many many other duplicates of the above) And finally this one, which requests the inclusion of a firefox extension ( http://www.grim-world.com/miek/ ) which covers some of the features requested in a lot of the above bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=274617 This extension doesn't let you put formatted text (html or otherwise) into your signature, it doesn't let you refer to a file on disk, but it does let you put pre-made text at the cursor position from a right-click pop-up menu. THANK YOU TO THIS extension's author. You have really made my day. Won't someone who is well versed in mozilla internals massage this extension a little, perhaps allow formatted text, perhaps allow it to refer to files on disk? I love mozilla in every other way, but for replying to dozens of the same frequently asked questions over and over again every day, a feature like this is really a huge missing link. (p.s. yes I know about Drafts and Templates, but they cannot be used for a _reply_ only for composing a new message.)
There is no usability reason to put the signatures in one specillay formatted file. but there are several against it. It is more difficult to read the suggested file format compared with plain text or html. Other programs uses plain text and then you can share your sig between TB and those programs You can auto generate text files. re: Usability. Eudora lets the user edit the signatures from inside the program, (some menu has an option like New signature). When you save it the dialog automatically opens the signature-folder in the mail folder (similar to TB's profiles-folder). The signatures are then available from a menu in the compose window's toolbar. I have never heard that this has caused any problems, neither for advanced users or novises.
(In reply to comment #48) A "Signatures" directory in the profile directory containing a file (*.txt, *.html?) for each signature sounds like a great idea. How would the files be named? For usability, it would be nice to have the signature's filename be the same/similar(truncated?) as the user-given name for the signature (e.g., "Friends (HTML).html" or "Newsgroups (Text).txt"). If that is too hard, we'd have to use the unintuitive machine-generated method: sig-01.txt, sig-02.html, sig-03.txt, etc. (What hapens to the number sequencing if the user deletes a sig in the "middle"? See the way Thunderbird creates/names addressbooks for reference. PS. Is "Seth Spitzer (not reading bugmail) <email@example.com>" even working on Mozilla anymore? Assign to "nobody"? PPS. <rant> This bug (4+ years old!) reminds me of why I hardly make suggestions to improve Mozilla products anymore. Seems people are too busy adding podcasting to Thunderbird. :-( </rant>
he does actually, but he was the default assignee for so long that he has too many bugs to his name.
Undoing timeless' bugspam-causing stunt. --> firstname.lastname@example.org
*** Bug 312807 has been marked as a duplicate of this bug. ***
*** Bug 337282 has been marked as a duplicate of this bug. ***
*** Bug 350089 has been marked as a duplicate of this bug. ***
> PPS. <rant> This bug (4+ years old!) reminds me of why I hardly make suggestions > to improve Mozilla products anymore. Seems people are too busy adding podcasting > to Thunderbird. :-( </rant> I totally agree. New versions of Firefox and Thundebrid too(no security releases) appears after half of a year with spectacular new functions like 56th redesign of Preference window or with extra-useful "Install" button in Extensions window. Stop writing **** blogs saying how Mozilla products are wonderful! Where are really new features? Like this old request - multiple signatures? When it will be available? Firefox sucks too. It's only a wrapper for Gecko with "back" button. Useful functions are added only by contributors. Unfortunetly. Where is a ppsession saver? When RSS support like, please God, I beg to be excused, in IE7? Using Bloglines or other so-called Web 2.0 service isn't a way! I want speed and memory allocation improvements instead of brand-new integrated Add-ons window. New versions of Mozilla products more and more often makes me laugh. Unfortunetly, the browser market share sucks, becuase there is no good alternative.
Well, I feel ashamed of posting here any comments after my last post. Please forgive me as my last comment (posted very long ago, BTW) was caused by really strong emotion and certainly bad mood. Unhappily, not much changed since then. I think Bug 324495 is a duplicate, but it shouldn't be deleted, because it has many latest comments and UI research.
Some related extensions, but not mentioned here: "Signature Switch" http://addons.mozilla.org/thunderbird/addon/611 http://mozext.achimonline.de/signatureswitch_about.php "Quicktext" http://addons.mozilla.org/thunderbird/addon/640
Filter on "Nobody_NScomTLD_20080620"
I think it will be great to have all to manage signature without any extension !
You do not have to worry about design or how to implement multiple optional signatures, just COPY this feature from Eudora v.7.0.1, which I still use because NO OTHER e-mail client can do all it does. (See wikipedia PT-BR for Eudora Advantages - Vantagens do Eudora).
We are moving from Pegasus (which is better than Eudora :-) and we all miss this important feature. We have a corporate signature and a signature to be used internally, with alternative formats in HTML and plain text. Besides, everyone has other signatures, such as signatures in English (not Spanish), Chinese or French, depending on the addressee. I will vote for this.
Created attachment 426464 [details] Screenshot - Signature selection in Pegasus Could be used as an example
Why not merely integrate the Signature Switch extension into Thunderbird as a basic capability?
Multiple signatures are clearly a long standing request & are needed if Thunderbird is to truely be an viable alternative to M$, Eudora or Pegasus The key is that any email message is a 2 part message, text & HTML So for each of the multiple signatures there need to be two parts, text & HTML so that both formats present the user properly which is not the case at this point in time
Re comment #70: Don't forget those of us who choose to send only ASCII-formatted E-mail. And then there are all those newsgroups that reject HTML-formatted E-mail. In those cases, I believe that the messages are 1-part with no HTML parts. No, this is not an argument about whether ASCII-formatted E-mail is better than HTML-formatted E-mail. This is merely a reminder that, when implementing this RFE, 1-part ASCII-only messages should also be properly handled.
Happy Ninth Birthday Bug 73567!!! Also you're coming up on your 20th duplicate, I'm so excited for you!!! (and how many grand-dupes you must have within those dupes!). I've been watching you since you were just a toddler, back when I was so used to having this feature in Outlook Express in Windows 98 on my ThinkPad 510 Blue Lightning processor. And I so optimistically took up Linux and Mozilla Mail. Also you're coming up in just 2 weeks to the 5th birthday of comment #47. You must be so proud. Although it has been nice knowing you and watching expectantly as you grew and grew, I must say I have long since given up hope of you amounting to anything, and given up waiting for you. I'm sorry but I've met somebody else and it is called the Quick Text plug in. Sorry it has been going on for 5 years already. I've even lost all interest I might have had 8 years ago in getting more involved in the project in general. (What are the normally cited baby-steps of starting to get involved? - beta testing - filing bugs - giving feedback - helping with documentation. I tried all those baby steps and instead of feeling the synergy and progress and wanting to help more, you let me down. At this rate I will have seen ONE bug I cared about and tried to help with ever get anywhere before I die, and that's an optimistic estimate of ONE assuming this bug gets anywhere in the next 4 or so decades I might live.) Finally - my main reason in filing this comment (forgive the above rant) - after reading hopefully (hope springs eternal, eh) into several of the dupes and Depends-On's and Block's seeking some sense of progress... can somebody explain to me why at the top of this bug is the setting "Depends on: 488469" ? I don't see why "put signature editing in UI (rather than select a file)" is a pre-requisite of this bug, the "ability to select from multiple signatures". And even if it was somehow contingent on editing being in the UI, I don't see why the already-implemented text version of that bug, Bug 324495, wouldn't be sufficient. How would the text- or HTML-ness of it be relevant to whether there could be multiple of them? Please, bug 73567, restore my optimism just once.
I use "signature switch. When I reply that I want to change my signature, it ranks as the message which I answer that does not meet the standards institutions. It would be great if we could choose, as in Outlook ...
Hmmm... Well, at this point in time, in TB 3.1 and SM 2, we have multiple identities, where each identity may have a different signature. We also have the ability to edit signatures in the UI vs only calling an external file. Obviously, multiple identity support isn't *exactly* what this bug involves, as making several identities, each with a different signature but with the same name, i.e., Joe Bloe <email@example.com>, it wouldn't be very easy to select the proper one, given our current UI. Thus, it may be possible to implement this via multiple identities as we have, with just a minor change to the UI to make locating the proper one more intuitive.
If eventually somebody will try to implement this feature, there should be a check whether the mail is html-formatted or not and a feedback if a sig in the other format should be used or not. However, I highly recommend this feature, and it makes me upset that for such a long time nothing happened about such a highly useful thing.
This is a feature that Thunderbird should definitely have and multiple identities is just a workaround, not the real solution. Apart from the problems highlighted above, each identity besides the signature also has a lot of settings (corresponding to the account settings tabs named Settings, Copies and folders, Composition, Security) that should be set separately for each identity: for example, if I have multiple identities and I want to change where the IMAP Sent folder is located or my digital certificate I have to do this for every single identity I have, not just in the account panel as I would do if I had a single identity with multiple signatures, as Outlook and Apple Mail do from a long time.
Multiple signatures are implemented using the Flexible Identity extension (see https://addons.mozilla.org/en-US/thunderbird/addon/flexible-identity/). I've been using this for some time on both SM and TB. I just realized that I'd last posted to this bug before I started using Flexible Identity. This does not address bug #553958, however, so if there is a dependence upon bringing this into core, then the extension is merely a workaround (unless the extension developer could be persuaded to add the HTML vs text auto-switch behavior, of course).