Closed
Bug 130796
Opened 22 years ago
Closed 14 years ago
HTML editor for <textarea> (HTMLArea)
Categories
(SeaMonkey :: Composer, defect)
SeaMonkey
Composer
Tracking
(Not tracked)
RESOLVED
EXPIRED
People
(Reporter: stig-moz, Unassigned)
References
Details
(Keywords: embed, topembed-)
Attachments
(2 files, 2 obsolete files)
1.48 KB,
text/html
|
Details | |
19.32 KB,
patch
|
Details | Diff | Splinter Review |
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...
Updated•22 years ago
|
OS: Linux → All
Hardware: PC → All
Updated•22 years ago
|
Whiteboard: DUPEME
Updated•22 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 1•22 years ago
|
||
We don't have an <htmlarea> bug, so this will be it.
Assignee: asa → syd
Component: Browser-General → Editor: Composer
QA Contact: doronr → sujay
Comment 2•22 years ago
|
||
This is something that embedding customers want too.
Severity: enhancement → normal
Keywords: topembed
Summary: HTML editor for <textarea> → HTML editor for <textarea> (HTMLArea)
Whiteboard: DUPEME
Target Milestone: --- → mozilla1.1
Reporter | ||
Comment 3•22 years ago
|
||
<htmlarea> is fine/good/great but even <textarea> should have an upgrade path so that the user determines when HTML editing is desired.
Comment 4•22 years ago
|
||
Comment 5•22 years ago
|
||
Comment 6•22 years ago
|
||
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.
Updated•22 years ago
|
Attachment #74411 -
Attachment description: Proof of concept patch. Don't check in. → Proof of concept HTML file. Don't check in.
Updated•22 years ago
|
Comment 8•22 years ago
|
||
no this is not a duplicate of that bug. In fact, this will block that bug.
Updated•22 years ago
|
Keywords: mozilla1.2
Comment 10•22 years ago
|
||
*** Bug 168530 has been marked as a duplicate of this bug. ***
Comment 11•22 years ago
|
||
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.
Attachment #74409 -
Attachment is obsolete: true
Attachment #74410 -
Attachment is obsolete: true
Comment 12•22 years ago
|
||
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...
Comment 13•22 years ago
|
||
*** Bug 176956 has been marked as a duplicate of this bug. ***
Comment 14•22 years ago
|
||
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?
Comment 15•22 years ago
|
||
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>
Comment 16•22 years ago
|
||
*** Bug 185639 has been marked as a duplicate of this bug. ***
Is it better to build this into Mozilla, or use something like this?: http://www.interactivetools.com/staff/ben/htmlarea3_demo/example.html
Comment 19•21 years ago
|
||
>Is it better to build this into Mozilla, or use something like this?: >http://www.interactivetools.com/staff/ben/htmlarea3_demo/example.html I think using javascript editors makes sense (as opposed to adding more proprietary features). Now with Midas (http://www.mozilla.org/editor/midas- spec.html) it's fairly straightforward to implement everything requested in this bug. In fact, I believe our "htmlArea" already does, although it's currently alpha. Some of the additional benefits of would be having an editor that works in both IE and Mozilla and much more flexability for developers to decide how various aspects should be implemented. In any case, we (as well as many others) see the need for a ubiquitous in-page wysiwyg editor so we're developing htmlArea (the javascript library) under the BSD license. Meaning it's free for anyone to use or modify for any project they like. You can download a copy, visit the forums, and/or get involved, here: http://www.interactivetools.com/products/htmlarea/ Dave, interactivetools.com
Updated•20 years ago
|
Product: Browser → Seamonkey
Updated•16 years ago
|
Assignee: composer → nobody
QA Contact: sujay → composer
Target Milestone: Future → ---
Comment 21•15 years ago
|
||
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
Comment 22•14 years ago
|
||
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: 14 years ago
Resolution: --- → EXPIRED
You need to log in
before you can comment on or make changes to this bug.
Description
•