HTML editor for <textarea> (HTMLArea)

RESOLVED EXPIRED

Status

defect
RESOLVED EXPIRED
18 years ago
9 years ago

People

(Reporter: stig-moz, Unassigned)

Tracking

({embed, topembed-})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

Reporter

Description

18 years ago
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

18 years ago
OS: Linux → All
Hardware: PC → All
Whiteboard: DUPEME

Updated

18 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Keywords: topembed
Summary: HTML editor for <textarea> → HTML editor for <textarea> (HTMLArea)
Whiteboard: DUPEME
Target Milestone: --- → mozilla1.1
Reporter

Comment 3

18 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.
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.

Updated

18 years ago
Keywords: topembedembed, topembed-

Comment 7

17 years ago
Dup of bug 97284?

Comment 8

17 years ago
no this is not a duplicate of that bug.
In fact, this will block that bug.

Comment 9

17 years ago
over to sfraser
Assignee: syd → sfraser

Updated

17 years ago
Keywords: mozilla1.2
*** Bug 168530 has been marked as a duplicate of this bug. ***

Comment 11

17 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
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...

Updated

17 years ago
Blocks: grouper

Comment 13

17 years ago
*** Bug 176956 has been marked as a duplicate of this bug. ***

Comment 14

17 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

17 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>
*** Bug 185639 has been marked as a duplicate of this bug. ***
Not mine no more.
Assignee: sfraser → composer

Comment 19

17 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

Comment 20

16 years ago
retargeting
Target Milestone: mozilla1.1alpha → Future
Product: Browser → Seamonkey
Assignee: composer → nobody
QA Contact: sujay → composer
Target Milestone: Future → ---

Comment 21

10 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

9 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: 9 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.