as HTML entry into web forms is increasingly common, It would be nice/great/wonderful to be able to easily generate that HTML in the composer. A right-menu item would seem to be the cleanest way to invoke this crossover functionality...
We don't have an <htmlarea> bug, so this will be it.
Assignee: asa → syd
Component: Browser-General → Editor: Composer
QA Contact: doronr → sujay
This is something that embedding customers want too.
Severity: enhancement → normal
Summary: HTML editor for <textarea> → HTML editor for <textarea> (HTMLArea)
Target Milestone: --- → mozilla1.1
<htmlarea> is fine/good/great but even <textarea> should have an upgrade path so that the user determines when HTML editing is desired.
To run the test, you need to save these 3 attachments to your hard disk, in the same folder. You should name them: htmlarea.css htmlarea.xml htmlareatest.html then load 'htmlareatest.html' in the browser.
Attachment #74411 - Attachment description: Proof of concept patch. Don't check in. → Proof of concept HTML file. Don't check in.
Dup of bug 97284?
no this is not a duplicate of that bug. In fact, this will block that bug.
over to sfraser
Assignee: syd → sfraser
*** Bug 168530 has been marked as a duplicate of this bug. ***
This is a patch file that I've been playing with on my Macintosh mozilla build. I'm not sure if I have all the unix/windows makefile stuff correct but it's a start. (I may also be missing some changes for embedding users.) NOTE: This version is not to be checked in.
Shouldn't it support the "htmlarea" element as well as an "editor" attribute in an iframe as to be compatible with html for MSIE? (an "htmlarea" would really be an "editable iframe") It would be nice to have this for 1.2final, but it's probably far to late for that...
*** Bug 176956 has been marked as a duplicate of this bug. ***
Perhaps we could do something like in the IE version of hotmail, a menu bar inside of text area that would do basic text formatting?
Thanks for the kind words and votes! Supporting an <htmlarea> tag would be fine, but I think it's more important to also support this capability as an optional attribute for <textarea> (and maybe <input type="text"...> or <isindex>). That way, website developers can simply use the <textarea> tags they ALREADY use; users of the latest version of Mozilla will get the nice HTML editing, and other users (including users of older versions of Mozilla) can still use the website. It's hard enough to be a website maintainer; giving website maintainers something that they can insert but gracefully degrades to work on other systems is a Good Thing (TM) :-). Vladimir Ermakov suggested "a menu bar inside of text area that would do basic text formatting"; for at least a textarea I think that's a very good idea. It doesn't need to support all possible options; I'd suggest at least <i>, <b>, <p>, <br>, <ol> and <ul> and <li>, <blockquote>, and <a href="">. Slashdot, for example, allows the following tags: <B> <I> <P> <A> <LI> <OL> <UL> <EM> <BR> <TT> <STRONG> <BLOCKQUOTE> <DIV> <ECODE>
*** Bug 185639 has been marked as a duplicate of this bug. ***
Not mine no more.
Assignee: sfraser → composer
Is it better to build this into Mozilla, or use something like this?: http://www.interactivetools.com/staff/ben/htmlarea3_demo/example.html
Target Milestone: mozilla1.1alpha → Future
Assignee: composer → nobody
QA Contact: sujay → composer
Target Milestone: Future → ---
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.