Closed Bug 97284 Opened 20 years ago Closed 18 years ago

allow page to make arbitrary elements user-editable in browser (contentEditable attribute)


(Core :: DOM: Editor, enhancement)

Not set





(Reporter: glazou, Assigned: cmanske)


(Depends on 1 open bug)


(Keywords: css-moz, ecommerce, topembed-, Whiteboard: [Hixie-P5] [Hixie-CSSUI2] EMBEDDING)


(11 files, 1 obsolete file)

I think we could add in the future a wonderful feature to the product : allow
any element in a browsed document to become editable. For instance, allow user
to directly modify in the browser the textual contents of a paragraph, or even
add elements and style them. Used in conjunction with DOM Load & Save, that
could be a killing app, letting us put two feet instead of one finger nail into
web publishing and/or collaborative edition.

I found that Microsoft started doing something like this during the CSS WG
meeting in Cleveland in 1999 when the first mention of the |isContentEditable|
proprietary extension to js appeared on their developer's web site. See below
for (a) technical data about the feature (b) a demo you should **really** try
with IE5.5 or higher.

We have a good browser, a powerful DOM, a clever editor based on the browser and
the DOM. It should be possible, at quite low cost, to add such a feature to
our product (me is perhaps dreaming at loud but, hey, that's a part of what I
am paid for, right ?-)


We already have this, it is called Bug 96604 =)
This should be done in a way that embedders can use it.

The real issue here is user experience. How do you indicate to the user that 
certain parts of a document are editable? How do you manage focus and keyboard 
navigability of editable elements?

I think, if we are to do this, it needs to be keyed off of CSS (-moz-editable or 
This is what hixie has proposed in his CSS UI draft.  A property called
user-can-edit, I think.  (Goes along with user-can-focus, etc.)
Simon: in my opinion, the only feedback the browser should give is changing the 
mouse cursor.  The rest of the UI should be the responsibility of the server. The 
'contentEditable' elements should be out of the tab list and without focus 
indication (a bit like word processors: there is no focus and you cannot tab from 
a paragraph to the next)

For instance in a groupware application, the host would serve documents depending 
on the user access level that could be read-only, partially modifiable or fully 
editable.  The author will have to decide what visual feedback better represents 
the user access level, and it is nice to imagine that the whole mechanism (making 
things modifiable and providing feedback) can be implemented by a simple switch 
of stylesheet depending on the user.
Target Milestone: --- → Future
spam composer change
Component: Editor: Core → Editor: Composer
I think what this RFE is talking about is basically what IE does with <DIV
CONTENTEDITABLE>, but to implement it on a broader scale. This would indeed be a
definate IE killer. Implementing a CMS would be several orders of magnitude
easier with this!

If this is so, why is this in de Editor: Composer component?
Because the Editor component has been divided in two after the bug was filed,
that's all.
Component: Editor: Composer → Editor: Core
Keywords: css-moz
Whiteboard: [Hixie-P5]
Original question send to Sujay:

Is there, or going to be a way to access the composer components via JavaScript
from html documents ?
Like the execCommand("command") and .contentEditable='true' methods used by
Internet Explorer 5.5 ?
These commands are the remains of what used to be Frontpage Express which have
become accessable via 
Jscript, VBscript, Visual Basic and C++.

added comments:
Currently we're using the IE components as a clientside browserbased content
Editor. Developers set the editability 'freedom' via contentEditable. Editing is
done via Wysiwyg interface run via JScript execCommand('commandname').
Edited webpages are submitted to a database which does the actual content
management. Content management is done via database.
*** Bug 122158 has been marked as a duplicate of this bug. ***
If this functionality is ever implemented, I would suggest trying to match 
Micro$oft's syntax whenever possible. Not because Micro$oft's syntax is 
especially great, but simply because hundreds of web applications are 
currently being written with it.
I have, unfortunately, to agree with last comment...
The syntax doesn't have to be the same. 
Currently working systems that rely on this feature will use other IE centric
features as document.all, filters, etc... so it's not likely that just by adding
some of the syntax to deal with the editor it will automagically work in every
CMS around.

What's most likely is that if the people is interested in support Mozilla then
they will add a second page and will redirect the user according to the browser,
and to design that second page they will use some sample that in the future will
be developed to test the implementation by Mozilla developers.

So there's no real reason to try and force the development of this feature to be
guided by the current syntax of IE. It can use whatever the Mozilla's developers
like. Just do it wisely and everybody will be happy.
Is this actively being worked on?  

As for IE syntax, etc.  It would help if it was maybe similar, but I don't think
it's necessary to be exact.  It may be good to even implement just the methods
used in the example for this bug.  My reasoning is this:

If a developer of an existing IE application sees that the example above works,
they may consider "supporting" Moz.  If they do support it, they will maybe read
a little more to get the rest of the functionality working on IE and NS.  

Unfortunately it's too easy to slap a "IE Only" label on and app.  So this
halfway compromise may get Moz's foot in the door.

BTW the editing stuff in IE doesn't even work on the Mac side, which is typical.
 At least we know if it's done in Mozilla it will work everywhere.
Yes, I am very interested in support the MS interface. We have to see how it fits 
in with our current embedding re-architecture work.
Assignee: brade → cmanske
Whiteboard: [Hixie-P5] → [Hixie-P5] EMBEDDING
The most complete implementation of this feature in IE can be seen at  Something that looks very
similar to this is what is used in Hotmail.  If this could be implemented I am
sure that is most of the features that are necessary.
To call this "the most complete" is an insult to everyone out there who have 
made superior editors compared to this one.

Basically Mozilla has all the features needed to support this the only thing 
to do is to bring back the possibility to edit the document using the 
keyboard. This was available in early previews of Gecko. I have no idea why 
this was removed.

The range methods of DOM Level2 Ranges would allow the developer to insert 
images and change formats and all that stuff.
What I meant rather, was this is as complete as I've seen an implementation of
this particular technology that is available in IE.  I am not talking about
having an editor as complete as Composer embedded in the page, but more a basic
editor so the user can have a WYSIWYG editor within the page, but those changes
they made could still be submitted as a form element.  

After a review of the embedding work being done by mjudge, we are confident that
we will be able to support this, but probably not for 1.0.
Target Milestone: Future → mozilla1.1
Whoo Hoo! A target is set after just a little talking to the developers.  This
is why Open Source developer is great.
In the nightly builds there is a menu item called "Editable mode" - si it
possible to add a javascript method on frames/iframes that toggles/switches this

IMHO it's not a big deal to add this feature and it give us a lot. Using DOM/js
a much better (say HTML4.x compilant) editor component that the IE Frontpage toy
could be easily done. Please!

Jaro v. Flocken--I think it's a great idea too.  We would love it if you or
someone else would submit a patch to address this rfe.
Keywords: helpwanted
I'm a very poor C++ programmer, more into the HTML /java and javascript stuff.
Howerver I could assist a coder during the implementaion (building a sample
Editor app etc.)

What do you mean actually? A javascript hook to open the current page in
Composer, but within an iframe in a certain page (with or without the menubar)? 

This could be a good idea, but as is illustrated in the example there should be
a way for the HTML on that page to be "captured", that is, allow the
iFrame.body.innerHTML (and innerText) to be assigned to a JS variable in the
opener page.  This way the edited document could be sent back to the server as
raw HTML to be stored in a database, file, etc.

Also, just editing the whole page would be no good.  It would be better to
specify what would be edited, meaning

In XUL you can add a simple <editor> Tag to get a WYSIWYG Editr area. 
At the moment it stops at the sandbox - if one tries to pull such a XUL document
from another location or using http: instead of chrome: a js security exception
will be fired.

A simple solution is indeed switching a completed document object into the
editor mode because we con use frames or - much better: iframe. The source
attribut of the iframe tag gets another document, this can be retrieved with
*.body.innerHTML or whatever (I'm sure there is a way to get the complete html

Please correct me if I completly wrong :-)

What this bug refers to is not using <editor> or <HTMLArea> or anything. It's
about allowing arbitrary content in a web page to be editable. Imagine:

<p>Hello there. Type something here:</p>
<div editable="true">
Type here...
I thought that the Css3 proposed properties user-input and/or user-modify are 
supposed to do these. (Maybe user-select and user-focus as well in some way?)

These seems to be implemented using -moz-user-input and -moz-user-modify but 
these only work for input[type=text] and textarea.
Where do you see a menu item for "Editable mode"?  I just checked both the
MacOSX and Windows builds for today, and cannot find it. 

For what it is worth, I would love to see this feature and would immediately use
it, but the real issue for me is to be able to submit edited HTML content in a
form. So if it worked completely differently that would be OK too - for
instance, click a link and a page opens in Composer, click the Composer "save"
button and the HTML gets written to a form value, click the "Submit" button to
send it to wherever. Whether the page is edited within an iframe or in a
separate composer window is immaterial (for me at least). 
This is my exact need also.  I think the menu item he was talking about is Edit
Page.  I too have an urgent need as we are releasing a new feature as a major
part of out application and right now it's an IE only feature.
A <div> would be also great, ther is no need for proprietray tag's here, I just
tried to explain what I mean. I definately don't mean "auto open" a page in
Composer, it's more an embedded widget or area (call it what you like to) that
enables editing the innerHTML (or source in case of IFrame) in a WYSIWYG style,
excatly what <editor> is doing in the composer XUL File.

Many users want to edit parts of pages in content managment environments or
bulletin boards in the same way like a textprocessor (say Word or Staroffice here).

Another benefit is storing the edited content using any POST method, I doubt
thta this is possible/wished in Composer.

Well, that's what the original reaquest is for, exactly what you described.  I
thought you were originally suggesting a temporary work around until the full
fix is implemented.  As of right now, I think the leap from adding the <editor>
tag in XUL to implementing all of that in a <div>  is more diffucult then it
seems, because of code issues, not architecture.

I've been reading things about just using composer(-like inline elements),
complete with buttons and all. I thing it would be really important to be able
to control the mark-up with javascript. Sure, it would be easy if we (the
webdesigners) don't have to add buttons and javascript anymore, but it would
certainly limit the fexibility.
One thing I don't see you do without javascript being able to control the text
is add an image (one that's on the server or that can be uploaded by the user
This is the code currently in use by our company to implement this
functionality in IE.
removing myself from the cc list : the "Editor mode" menu item is not in the browser but
   in viewer ; on windows, try mozilla\dist\win32_d.obj\bin\viewer

But that's not, as Simon pointed it out, the main purpose of the current bug.
Interesting idea, though. Btw, that menu item does not "toggle" editor mode, it
turns editor mode on, that's all. There is no way in viewer to turn it off.
Whiteboard: [Hixie-P5] EMBEDDING → [Hixie-P5] [Hixie-CSSUI2] EMBEDDING
Not allowing arbitrary elements to become editable is totally sucking the
monster bug wang. This bug being fixed would be of great use to not only myself,
but developers around the world. I will feed you beer by the bucket if some kind
heart will consider implementing|correcting this.
See also:
bug  96392 [RFE] Exposing HTML Editor commands to Browser Dom
bug 130796 HTML editor for <textarea> (HTMLArea)

I think both should be duped to this bug or wontfixed in favor of this bug.
Summary: [RFE] allow arbitrary elements to become editable by user in browser → [RFE] allow page to make arbitrary elements user-editable in browser
This is *not* a dup of bug 130796. They are rather different issues. I think bug
96392 should be dupped against bug 130796.
Simon, can you explain why you think they aren't dups of this bug and why you
think they're dups of each other?
Bug 130796 is about <htmlarea>, which is an HTML-capable <textarea> (though
closer to an editable <iframe> in implementation). HTML editing is limited to a
specific frame in the page.

This bug, and bug 96392, are about making arbitrary parts of the content of a
document editable via script, or CSS attributes. The implementation would be
I'm the lead programmer on a popular OS CMS called WebGUI ( I
can't even fathom the amount of effort you guys have already put into Mozilla,
but I can tell you that in the CMS world, there is no higher priority than
trying to find a cross-platform inline editor. I can tell you that you do not
have to strive for compliance with IE or Opera or any other browser provided
that the functionality works on all versions of Mozilla. 

I can also tell you that IE will immediately be replaced by Mozilla as the
browser of choice by all of the WebGUI users (including some Fortune 500
companies) if this functionality were implemented. There is no hotter topic than
CMS as far as browsers are concerned in any company we've dealt with. And every
one of them wants to be able to publish content in their browsers from Windows,
Mac, Linux, and Solaris desktops scattered throughout the company.

There are a couple of commercial companies out there trying to make this work
(as java plugins), but we've purchased both of them and they both fail in many

No matter which of the bugs (listed above or this one) you follow as an
implementation method, you will knock IE on it's can, as long as the resultant
HTML snippet can be passed back through a form.

I cannot wait to see this type of functionality implemented.
JT Smith, would an editable iframe be good enough, or do you really need
aribitrary elements in a page to be editable? Those are pretty different things,
from our perspective anyway.

I'm thinking that if the Java solutions are an option then an editable iframe
would be good too.
An editable IFRAME may do the trick, but I think there's really more to it than
that. We need methods through javascript to be determine what is highlighted,
perform some manipulation on that (like add style information), and then replace
the highlighted text with our new text.

There is a great open source DHTML editor here:
that you could take a look at. However, they're using some other IE only
functionality like modal windows.

We have another editor that we got from some DHTML site. It works very well too
and doesn't appear to use as much IE specific code. You can see it in action if
you go here: and
you can download the source from here:

However, the thing that I think would be absolutely ideal would be to see
Composer loaded as a form element (instead of a textarea). That way users would
have all the power of Composer at their fingertips, and CMS developers could
integrate the output of composer into their form post without any trouble.
There are a couple other advantages to using Composer as a form element that I
forgot to mention.

1) If all that power were implemented, there'd be no reason to reinvent the
wheel. That way developers could spend their time working on something that
hadn't already been done.

2) It would give you an edge over Internet Explorer (until they copied it by
creating a form element that used Front Page).

3) It would be fast as hell because there's nothing else to download (unlike
java and dhtml based solutions).
Composer as a form element could be a option. Composer today works by making a
document editable, but all the editing UI is wrapping that editable document. 
Another option, one that was explored in the now defunct 5.0 codebase was to
have floating editing palette available that we implemented. Like you said, this
has download speed advantages among others.

However, what some people want is the IE style ability to create your own
editing UI with HTML that listens for selection as you described. The core
functionality could be the same, but we'd have to allow custom or canned UI
selection somehow. 

This is one of the big things both internal and external customers have asked
for post 1.0, so now is the time to weigh in on exactly what you need, and want
(noting that they can be different things).
I work mostly on the server side components of WebGUI. I've asked our resident
DOM/JavaScript guru to put together a list of what he'd need to make things work
properly if we built our own editor. I'll post that list as soon as he gets it
to me (a day or two). 

I have to say though, that even with the functionality added to create our own
editor, I think I'd rather use composer as a form element, because it would be a
monsterous effort to try and recreate the power of composer in our own editor.
Then again, if we could just extend/alter one of the open source editors that I
mentioned previously, perhaps it wouldn't be so big a deal.
If you view the attachment to this bug
(, IE 5.5+), you
will see how we implemented the editor.  One feature that was hard to do for us
was to allow certain text to be inserted at caret via a double-click with the
.value (or innerText) of some other element in the page.  This is an important
feature for us because we would like to use Moz as an HTML editor, mainly for
creating form letter templates that then get values swapped in for keywords. 
This would eliminate the need for an external word processor (Word,etc.) and
keep out application entirely browser-based AND cross platform (all this IE
stuff only works IE for Windows).

So we are less interested in customization of UI and more with solid Javascript
hooks into the embedded Composer element, especially the ability to figure out
where the caret position is and insert something (text, HTML) there.
As mentioned before, there are two different features being discussed here.

1. The editable IFRAME or <HTMLAREA>. This would be a nice feature if it has a 
toolbar. It would make a great rich text input field for forums etc. IE 
(windows only) has this feature (DHTML Editing Component) since version 5.0 (or 
as plugin to 4.0) and it is used in various input forms. See for instance for an editor demo using that feature (IE 5.0+ on windows 
only). The site is in dutch, click in "demostratie" for a demo, click on "log 
in" to activate the editor and on the wrench to start editing.

2. The ability to make abritrary elements editable. IE (windows only) has this 
feature (contentEditable="true") since version 5.5. This feature really moves 
browser technology out of the input form era and paves the way for real 
applications in the browser. See for instance an editor comparable to ecop 
using contentEditable="true" at (IE 
5.5+ on windows only). Click on one of the images to edit that page.

As i said, contentEditable paves the way for real applications. An other 
example which shows some of the power of contentEditable is Xopus. Xopus is a 
browser based in-place WYSIWYG XML editor. For a demo see: (again: IE 5.5+ on windows only)

Implementing just an editable IFRAME would limit us to input forms.

Implementing contentEditable in the same way as it is done in IE would make it 
possible to make these applications, and applications we haven't even thought 
of, available for Mozilla users.
Er. Apparently the '-moz-user-input' property already works to some extent.
Hixie: I can't figure out how to use -moz-user-input (and -moz-user-modify and
-moz-user-focus) to let a visitor edit a page.  Do you know how?
PLEASE PLEASE PLEASE - just do it!  Do it with a <HTMLEDIT> tag, do it by making
any element editable - do it with propriaty extensions of HTML - do it by
emulating IE - Do it ever which way - But for the sake of having a truly viable
alternative to IE, and for the love of the Internet - DO IT - Please.

How can I as a web-developer convince my marketing/administration/power guys
that Moz is the way to go, when they cannot use the fancy editor they are used
to from Hotmail, Yahooo mail etc? To them that spells 'inferiour browser' and I
can whine for days about platform-independance, standards conformance etc. What
do they care? They all use windows anyway.

The Internet is moving from a Server/Client model to a P2P model - Still more
and more websites become dynamic, and less tech-savy users are beginning to
provide content on a massive scale. CMS is THE THING on the WWW part of the
Internet right now (much like real P2P is the buzz at the moment), people are
Blogging, chatting and providing content like never before. I've just
implemented a cool editor in IE - and it carves holes in my soul that I can't do
it in Mozilla but have to resort to a textarea and bbcode. My mother will never
get bbcode, and she'll never understand the connection between raw text with
some strange markings in it and a nicely formatted piece of text.

Listen to JT Smith - he has got more than just a point

I beg you - please do it - do it for the sake of Linux/Mac users, for the sake
of my mother, do it to bash IE and all of it's security holes, do it to help rid
us all from the Microsoft way of thinking, do it for your own reasons. 

I swear that if I could - I would, but I am not a C++ programmer, merely a
humble web-developer.
One more thing

All this XUL business is really great, and extending the editor is great too -
but first things first. If Mozilla is going to make it, it has to cater for the
users, then the web-developers and then the application-developers, not the
other way around.

You cannot underestimate 'sex-appeal' in the user-interface when it comes to
swaying users, and a textarea just isn't very sexy!
Just to add my 2ps worth to this  RFE. 

I have been advocating Mozilla over IE for 2 years now at every opportunity.
Perhaps the most common request I ever get hit with is - give us an alternative
to MSHTML - we want to do rich HTML editing via a web page and post back the
content - but without IE.

This feature would truly, truly rock my world and the worlds of shitloads of
other people. I have been playing with SOAP im Mozilla and the GoogleAPI all day
and it is superb. Now if only I could  press "Save HTML" and get my rich WYSIWYG
HTML  saving via a SOAP call to a backend. How cool would that be? 
Hi again,

I don't wanna start a flame war but using the DHTML Editor of IXplorer is a pain
in the ass, nice html code will be scambled without logic and for no reason.

But, as Esben pointed out: Users first - in my case customers first. And they
make changes on a html page like writing a letter on a Word(processor).

I love mozilla and still dream about such a tool for moz. I strongly feel that
it can fight back some lost market share just about this feature (Mac users!)

Again: Most of the fuctionallity is already build in - so it cannot be such a
big deal. Please!

Just my 2c, Jaro
Hej Esben,

> You cannot underestimate 'sex-appeal' in the user-interface when it comes to
> swaying users, and a textarea just isn't very sexy!

Well we can. It's just a question of priorities. (before flaming me, please check
that I am the reporter of this bug). The list of priorities and the prioritization
(we need to invent P12N acronym for this word :-) of these priorities made it
impossible to have the current bug on top of list.
if there is a commercial need for this feature i think we could go and 'sponsor'
a developer to build what is needed (i saw this happening with the roaming
Hey Daniel!
>Well we can. It's just a question of priorities. (before flaming me, please check
that I am the reporter of this bug). 

Oh - I never flame people :) Unless, of course, they want me to. RC2 is
wonderful - it's slimmer, faster and generally a darling in all respects. IE6
still makes a big white flash when rendering a new page - sometimes with Moz -
you have to actually read the page to be sure it changed :) And the javascript
engine is a little wonder. I am doing rather javascript intensive project and it
is IE 5.5 and IE 6 that comes with strange errors all the time, Moz just does
what I tell it to do :) 

Sometimes IE6 and less just plainly "forgets" to load something that you wan't
included, and it changes readystate of elements before they are ready -
sometimes (but not all of the time ) it fires onload before the page-elements
are ready and so on and blablabla 

But this is not things that an average user appreciates. The average user is
primarily concerned with features - 

    User: Can it do this, can it do that ?
    Dev:  well yes but it leaves a giant security hole on you computer !
    User: Cool - I always wanted it to do this and that !
    Dev:  errh... yes but it leaves a giant security hole on you computer, and
the mac-users won't be able to do it !
    User: Do you think that we could make it do some other stuff too?
    Dev:  *shrug* yes I think that it is possible

My motivation for working with Moz is a mix-up of microsoft resentment, and the
fact that Moz comes on all platforms (the latter being the most important). Moz
makes my work easier, more creative and more enjoyable. Therefore it is very
important to me that people actually start using it on a massive scale. That
would have a direct and positive impact on my professional live. However people
do not understand 'pipelining' and they don't care. Which is not to say that
pipelining is not important and not cool - it is. In my book however it comes
second to editable elements, because editable elements will have a direct and
positive effect with the userbase, a thing like pipelining has a more subtle
impact and can therefore wait.

I am sure that there is a lot of important issues, and what I am doing here is
trying to put some weight in behind the editable thingy - to make that more
important, because to me and a lot of other web-devs it IS very important.

I really think that it should be done the most easy way - expose the elements as
editable to the scriptable part of the DOM, and let the web-dev community take
care of the rest. Very soon you will have an abundance of editors with toolbars
and all sorts of cool stuff. If you force some sort of toolbar with it you will
only restrain web-devs and their creativity.

Imagine me saying: "Oh your company prefers IE on the intranet? Well we can work
with that, but it puts certain limitations on the project... Have you considered
Mozilla? It's free and it is superiour and it will even work for those of you
who uses Mac " :) ?

>if there is a commercial need for this feature i think we could go and 'sponsor'
a developer to build what is needed (i saw this happening with the roaming

There is a commercial need, and it is currently being met by IE, I am only
representing myself and my one-man-company so I won't be able to sponsor it -

With the advent of 1.0 and Mozilla 1.0 (and KDE and Ximinian
evolution and...) Microsoft will be getting a run for their money. There is not
one thing that an average medium-sized company is doing right now, that they
can't do on a Linux desktop. 

Now what is left is making sure that the advocates gets some ammo - and cool,
eyecatching features is precisely that sort of ammo - hence I'll reiterate:

    "You cannot underestimate 'sex-appeal' in the 
    user-interface when it comes to swaying users"

And I'll boldly continue

    "...and a textarea just isn't very sexy!"

And this feature is not only cool and eyecatching, it's actually valuable!

Priorities is what it is all about, and I am doing what I can to make this
edit-thingy seem more important, because to me it IS  important !

I love Mozilla - and I feel very grateful towards all actively involved in
creating it. I am part of the layer between Mozilla-developers and end-users. I
am one of the guys whose job it will be to sway users - that is why I speak my
mind on this matter, and that is why I think that editable content-areas are
>I love Mozilla - and I feel very grateful towards all actively involved in
>creating it. I am part of the layer between Mozilla-developers and end-users. I
>am one of the guys whose job it will be to sway users - that is why I speak my
>mind on this matter, and that is why I think that editable content-areas are

Me too. I feel exactly the same way. And I can add even more weight to this on
two counts: 

1) I'm the Director of Technology at a Fortune 500 company in Chicago (to cover
my butt I won't say which one). Therefore I'm in a position to help mould the
direction toward products like Mozilla. Before I came to this company, almost no
one had even heard the word open source. They are now using Apache, Linux, Perl,
Java, Tomcat, JBoss, MySQL, Net Beans, WebGUI, and many other open source
products. And now I'm making a push for the desktop.

2) I'm the leader of WebGUI (, the open source CMS. There are
many big companies, universities, and schools using WebGUI and for the most part
they'd drop IE in a second if it would mean they could use our Rich Edit
functions in one common browser among every platform they use. Desktop-wise that
includes every flavour of Windows, Mac, Linux, and Solaris you can imagine.

If I had any programmers I could spare at either company you can bet I'd be
sponsoring this myself. As it stands I'll do whatever I can, though I'm not sure
what that is. Except maybe to say what I just said.
FYI, we have internal customers as well for this so it has a high likelyhood of
happening, although not before 1.0 goes final. Perhaps 1.2 depending on how
timing goes and what ends up being implemented/needed first. So please be
specific about what you need and what you want ideally, and thanks to those that
already have said as much.
What our organization needs at a minimum is shown in the example attachment ( ).  I thought
the target was 1.1 ...

target is as soon as we can get done whatever we need to get done :-) That may
be 1.1, maybe 1.2, won't know for sure until we decide on a course of action
What I'd like from an editable content-thingy.

1.  First and foremost I'd like it to be there!
    Silly point perhaps - but I can eat any solution,
    as long as it gives users a familiar word-processing-
    like environment in which to supply content.
2.  I'd like it to set me free - I am a web-developer
    I can judge my users needs when I talk to them. I'd 
    like to be able to respond to those needs, and not the 
    needs of the majority of browserusers in general.
    Any embedment of the composer should give an absolute
    freedom in regards to toolbars etc. Keybindings should
    be the standard, I have no need to introduce CTRL+SHIFT+F12
    when people are used to CTRL+C (or APPLE-C or whatever), but 
    all that has to do with the appearance and layout should be 
3.  I'd like to be able to tell where the caret is, so that I 
    can mangle the text as I please, and put the caret back where
    the user expects it to be (dynamic creation of URLs is a good
    example). Why this isn't in the W3C standard is beyond me. 
4.  The idea of a TEXTAREA with a new propertytype is in a sense OK,
    but not as an only option - I mean if it is somewhat quicker to 
    implement, then perhaps this is where it should start - but I 
    think that the idea of a 'contentEditable' property of div and 
    other block-tags (or any tags at all) is really the way to go. 
    Somewhere inside the belly of the Browsers memory it's all just
    data anyhow, and everything is just a node on a tree - why not
    be able to access it? I mean click on an image and turn it into
    a text - or, at the webdevs discretion, pop-up some imagechoosing
    The argument that the TEXTAREA will let older browsers display it
    as a plain TEXTAREA really isn't that good. If you are doing some
    serverside-programming (you'd have to in order to make the thing work), 
    you can do a quick serverside browsersniff and give people what they need 
    (you'd probably have to anyway - there *are* IE users out there :).

5.  All issues in the direction of 'how will the user know that this is editable'
    and 'how do we deal with linebreaks in a non-block element' is up to the 
    webdevs. They can use this poorly and fail, or they can use it brillantly
    and prevail, it's really not the concern of the people making the browser.
So to sum it up - what I pine for is FREEDOM to develop what I need/want.
A solution that makes a lot of choices for me, is also dictating what I
can offer my customers. I'd like to dictate that myself :) This is also
one of the charms of the whole OSS scene, that freedom where the only restriction
you meet is that of your own limitations. My limitation is that I haven't got
the time nor the skills to just download Moz-source and start hacking it myself.

I'd be happy to participate in a more implementation-centric discussion, but the
headline for my wishlist is FREEDOM!
I add my votes to Esben's post (esp. to p 1)

A div (with css-p) or textarea would be cool. 
Access over the DOM to the inner content of this node is a must to make fancy
dialog bodex/buttons etc (I think this is already the case in composer)

Moving the caret the the key arrows CTRL+X/V/C DEL BACKSPACE PG UP/DOWN POS1/END

Optional: An event/command for paste/copy from the lokal clipborad would be
great (For the usual toolbar) -- but this can be a security issue.

Esben: #3 has a W3C standard. Try this:
var range=window.getSelection().getRangeAt(0);
var nodeAfter=range.startContainer.splitText(range.startOffset);
nodeAfter.parentNode.insertBefore(document.createTextNode('hello'), nodeAfter);

range.insertNode(document.createTextNode('hello')) should work too, but it has a
bug (I think)

A lot of things can already be done through javascript. The most important
missing feature is a visible caret. And it would be nice if user input handling
would be taken care of by Mozilla. (Moving the caret one position to the left
when the left key is pressed can be done with javascript, but you don't want to
script those things) These two features should be enabled when the css property
-moz-user-modify is set to read-write, for any element.
> The most important
> missing feature is a visible caret.

Have you tried caret browsing mode? Press F7 and you have a visible caret in the
browser window. It enables you to select stuff and move the caret with arrow
keys, but you can't edit anything.
Caret browsing: That's sweet. Shouldn't there be a menu item for this in Edit 
or view?

When was this added? Is there any way to set this using scripting?
Look at for editing
text in Mozilla
This is a very basic, but I think a good script to start
Sjoerds example combined with caret-browsing is very exciting. It goes to show
that mozilla is actually not far from there. I agree however that scripting
key-events in order to produce content is not optimal 

Funny thing that caret-browsing, it may be buggy though, try it here:

My caret runs around inside the same element and cannot escape (I'm using RC2) -
I am not sure whether to file this as a bug, and I request that some of you go
have a look and decide if it is a bug.

It seems to me that all the functionality needed, already is in Mozilla, and it
only has to be fitted together?
To turn on browse with caret (read only) mode:

prefs->SetBoolPref("accessibility.browsewithcaret", true); // or false to turn
it off

Most of the "caret browsing gets stuck" bugs are actually editor bugs.  The same
bugs appear while typing an e-mail message or editing a page in Composer, and
will appear in <div style="-moz-user-modify: read-write; height: 5em; border:
2px inset #ccc; overflow: auto;"> or <htmlarea>.  If you find "caret browsing
gets stuck" bugs, please file them after searching the Editor components,
because that will make Composer and -moz-user-modify suck less at the same time
it makes caret browsing work better.

By the way, have you tried the "edit page" bookmarklet in IE?
   javascript:void(document.body.contentEditable = 'true')
It has many of the same problems as Mozilla Composer on complex web pages
because it's intended for creating simple content.  Many bugs that show up while
editing forms and tables on don't show up often when you're typing an
e-mail message.  That doesn't mean we should ignore bugs found while editing (they do interfere with caret browsing), but those bugs don't prevent us
making -moz-user-modify work reasonably well.
>Most of the "caret browsing gets stuck" bugs are actually editor bugs.

I believe most if not all of these types of bugs are actually in the "selection"
component (not in an editor component).
If simply specifying a contenstype of text/html to a textaria 
eliment brougt up the composer for that textaria it would be 
a killer.

Its easy to use for webdeveloper, its easy to implement in different 
ways in different browsers (ie, call upp an extern app in an browser
only browser).

Browser not suporting it would give the raw HTML to edit so it is 
transparent to older browsers (it shuld require quoted HTML in the 
textaria to maintain that backwards compability).

Thanks /LaH
Hey folks,

I've been following this bug with interest for a while now. I have a client who
asked for a way to edit and/or add to pages in house, so recently embarked on
the journey to furnish them with such. I don't like doing platform specific
development, and generally do all my development in Mozilla, but after much
research it seemed that IE was the only browser which had all the functionality
I needed. I've never done any "IE only" development before, so it was an
interesting learning experience.

I've developed an application which basically lets certain parts of a page be
set editable, wraps them in a WYSIWYG editor with standard toolbar buttons to do
the formatting, and publishes the changes back to the server. It works a treat
if I do say so myself. It uses W3 standard DOM wherever possible, and for those
areas where it isn't possible I wrote thin wrappers which do the right thing
depending on which browser is used. All in all, it turned out much better than I
ever anticipated.

The thing that's really great (or really a shame, depending on your viewpoint)
is that it's almost totally cross platform. I did 90% of the development work in
Mozilla (and let me say now that development in Mozilla, while not perfect, is
at least an order of magnitude less painful than doing the same thing in IE);
save for the actual editing of text, everything looks and works exactly the same
in both browsers, including instantiating the editor and publishing changes. All
I'm missing for it to be completely cross platform is the ability to make a
block editable in Mozilla.

I've thought a lot about what form I'd like that to take. I think I agree with a
previous poster that exposing the basic functionality and letting the developer
build the actual editing application is the best way; it has the maximum
flexibility, and it's just not so hard to do that we need the Mozilla team to
present us with a fait accompli. I know there has been a lot of discussion about
simply putting in a tag and having an instance of composer show up, but that
would actually be bad for me. It's much heavier than I need or want, and almost
certainly wouldn't give me the control I need.

What I'd like is to be able to set a div, say, to editable and be able to do
operations on entered text. What that would mean is that I hit a key, the letter
shows up and the caret moves. Behind the scenes, I'd like to be able to either
set formatting on highlighted text (through an API ala IE perhaps) or wrap it in
tags of my choosing and have it rendered it accordingly (I've actually managed
to do this in Moz, but it's a little clunky because of problems with the range
object and it's not worth much if I can only use it with existing text).

As I say, I've gotten everything I described above with the exception of
entering text working, and I have a feeling that if I wanted to write some
really hairy Javascript, I could probably make that happen too; I may just try
it. The whole functionality is so damn close I can taste it, and it's really
frustrating not to be able to carry through. It's especially frustrating because
I have clients who would be willing to buy this from me tomorrow if it worked on
Macs, and it doesn't look like MS intends to expose this functionality there
anytime soon.

I know you want to focus on end users, but I can move a fair number of people
from IE to Moz immediately if you just make this functionality available. Moz
doesn't have to do all the work for me, it just needs to make it possible. I'll
take care of the rest. Before I go, I'd also like to say that I've more than
once stumbled across functionality in Moz that I didn't know was there and had
never seen documented; if something I'm wanting is already available (in any
form, as long as it can be used without hacking C++) please let me know where to
find info on it.
Can I just echo the sentiments expressed above.

I also have done a fairly complete editor that works in Mozilla. All I need to
polish it and make it better than IE is to be able to insert text at the caret. 

I do not want an embedded Composer - although I could put that to good use as well.

I want to be able to set a DIV on the page as editable, so that my keystrokes
will insert text at the caret or, it can take a selected range of text and wrap
or unwrap tags around it. 

Even if it was possible to calculate where the caret was in a DIV declared as
editable, I could hack some JS to insert my keystrokes.

Incidentally, the mshtml feature of IE is kinda nice. but it has a weakness that
Mozilla could exploit by the aforementioned caret enhancements. That is, the
code the various execCommands() produce is not valid XHTML. So, if you are
trying to produce well formed XHTML, mshtml  is of little use. You have to
resort to using the textRange object in a textArea or in an editable DIV. We
already got a range object in Mozilla, and we already have a getSelection() - we
just need to go that last half step and allow an editable area where selections
and ranges and caret insertion is possible. 

As the previous posts have said, give us that and we will do the rest. Hell, I
will even stick my editor on Mozdev and let everyone finish it and use it.

We needed contentEditable now to build a proof of concept of our Xopus editor 
on Mozilla. So we have made a very crude implementation ourselves.


This implementation is by no means complete nor stable but only meant as a case 
study. We still hope contentEditable will be part of Mozilla 1.1. 

Comments and additions are welcome.
Just previewing this brings tears to my eyes - *snort*...

Can't wait to download and play with it

Esben Maaløe
Depends on: 96392
*** Bug 147575 has been marked as a duplicate of this bug. ***
Im just gonna agree with all of the above we have a IE only app for editing web 
sites that we would love to make platfrom independent

plz plz plz put this in soon
The Xopus implementation is very close to my version.

It is obvious that very little really needs to be done to get this working. For
me the following is enough to  allow an explosion on HTML editors to appear:

1). Introduction of a contentEditable Tag 
2). The ability to identify the caret position inside an area where
contentEditable=true, in relation to the area. EG report that the caret is 10
characters along in the string representation of the content.
*** Bug 150609 has been marked as a duplicate of this bug. ***
See also bug 151765, which asks for a way to open Composer using javascript in a
web page (4xp).  I prefer the method in this bug: allowing the page to make a
div editable, and giving the page a way to ask the browser for a hovering
composer toolbar for functions like Copy and Paste that can't be done using
I have recently implemented a simple XML editor in mozilla using -moz-user-input
styles. This CSS3 approach shows great primise. I have sent a copy of the editor
to Ian Oeschger for him to review. Unfortunately the CSS3 -moz-user-input styles
are only partially completed. Missing are:

1. A caret in input cable areas.
2. Tabbing between input capable areas.
3. A keyboard interface for character insertion/deletion.
I have managed to get around some of these limitations in the prototype.

I have been persuaded to place this project on MozDev with the intent of adding
XML dialect specifiec editors/viewers. E.g. Docbok, XUL SVG, XSL etc.

The editor also currently has a partial implementation of RelaxNG for document

I really need for some progress to be made in resolving the above problems
before any further progress can be made.

Any ides of What and When?
Would someone like to bump the target milestone?
Sounds like "Future" to me. No point in having it set to a milestone that's already passed.
Target Milestone: mozilla1.1alpha → mozilla1.2beta
I run a Linux shop.  Do development in PHP/MySQL CMS Tools mostly.  However in
looking for a way to allow users to do basic WYSIWYG I was damn impressed with
what you could to with IE and javascript (that isn't possible in Mozilla).  

Something like this would kick ass:

The ability to specify a textarea which would allow folks to write as they would
in a Word Processor..

Wondering the discussion on dhtml, htmlarea, htmledit etc. I agree with Laurens
van den Oever and Peter Wilson, XML is the way forward.
Microsoft uses execCommand in contentEditable areas.
execCommand('command')places tags around or opens a tag depending on the
command. For instance execCommand('Bold') places <STRONG> tags around the
selection or opens the tag for new inserted content and closes the tag when the
command is called again. These commands are browser buildin (Dhtmled.ocx IE5+)
so your stuck with what micro$oft grants you. It would be more usefull if
execCommand can envoke commands based on the DTD used by the document your

When is the release date (when Mozilla starts supporting functionality similar 
to IE contentEditable=true property)
there is no release date yet, we're scheduling the work and figuring out what
exactly we'll do in the first go round and who will be doing it
I also hope for this: 
My Reason: 
At this time it is not possible to use Mozilla for ANY Content Managementsystem
which use a web-based WYSIWYG Editor. ALL CMS i know only support Internet
Explorer for use.
You also can not develop an WYSIWYG Editor for Mozilla with JavaScript or DHTML
because there is no Engine which you use for this.

See my attach at: Bug 163249
*** Bug 163249 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
Having the same view as stated in comment #89.
This is highly needed, as leading content-management-system vendors are all 
facing this problem and major companies won't decide for Mozilla if they are 
not possible to use their web based cms systems.

Keywords: ecommerce
Major European companies have asked about such a beast as well, so making topembed
Keywords: topembed
Add dependency on edembed
Alias: editable
Depends on: edembed
if this was then wrapped in an activeX control, this could be embedded in IE for
a consistant cross browser toll too
Looks like someone just put a bounty out on this bug...or its kin...the bounty
includes a monitary sum (bout 1/4 of the way down search for 'I Just
Can't Take Internet Exploder Anymore'

Looks like someone just put a bounty out on this bug...or its kin...the bounty
includes a monitary sum (bout 1/4 of the way down
search for 'I Just
Can't Take Internet Exploder Anymore'
That's interesting! 
I've made editor embedding topics such as this (tracked by bug 157128) a major 
priority during the next few months (and didn't need any monitary incentive :-)
I studied the MS/IE HTML editor interface carefully today and we will have no
problems supporting this once the editor embedding goals are fulfilled; but if
you design an editor to our interfaces, there will be much better capibility,
of course!
I would be happy to throw in a case of beer to add to the bounty. I'm so sick of 
recommending that our clients use Explorer if they want to use our web apps. And they 
still don't work on Mac, only under Windoze. Whoever resolves this bug is making 
inroards against two monopolies. They certainly deserve all the support we can offer.
so contentEditable doesn't work in IE mac?
This editor functionality in IE definately does not work on IE Mac.  This is a
real stopper for us because we would like to do a fairly large rollout of MacOS
X. Mozilla/Netscape is preferred, but IE would have been adequate.
*** Bug 166987 has been marked as a duplicate of this bug. ***
changing alias per cmanske, akkana, glazman
Alias: editable → midas
The content-decoding issue should not be an issue. You spool the raw stream,
then once you know the target location, you move the file and pass it through
the chain of decoders (and this should all be happening on a non-UI thread of
course). If the decoders are HTTP-specific then that should be changed, since
other protocols may well want to do content decoding.
er, wrong bug, my bad.
Midas, because everything it touches becomes (Netscape) Gold :-)
Sounds interesting.  1.1 is out the door.
Keywords: mozilla1.1
------- Additional Comment #106 From Alex Vincent 2002-09-12 18:36 -------

Sounds interesting.  1.1 is out the door.

Why? There is nothing about contenteditable in 1.1 or 1.2 or at least nothing I
can see from the release notes.

Is the problem making it work on all platforms? If so, make incremental releases
that work on whatever platform allows. hopefully those that don't (apple...)
will expose things that allow their users to enjoy the same benefits as windows

I EARNESTLY and completely vote for this functionality to be added to mozilla 

This would be nirvana for our application - but it MUST work across platforms. 
We currently use IE contenteditable for our CMS to allow users to edit their 
page content. 

I implore you to add contentEditable to Mozilla. It will have a much greater 
impact than any other single thing that you can do and it will pay huge 
dividends in user base and increased downloads of mozilla. I have several 
thousand customers alone who would be encouraged to download Mozilla in order 
to edit the CMS content on Macs.
yes, yes! This is the holy grail of the editor. We are working hard on this!
We need to fulfill basic embedding requirements such as "removing editorshell"
(architexture restructuring) and conversion to command-oriented API, then we'll be 
able to make the jump to "in place editing" or what I like to call it, "editing 
added nsbeta 1 kw.
This feature will have numerous benefits leading to increased Mozilla browser
usage and added value for embedded browsers:

1) Webmail sites (AOL, Netscape, Yahoo, etc) can easily offer parity with IE's
functionality, where you can compose messages with a WYSIWYG editor

2) AOL Hometown and other sites that host web pages could include HTML editing
capabilities in their page creation GUI. 

3) Companies that manage their intranets and websites using content management
systems can support Mozilla instead of or in addition to IE. Several
"evangelists" inside top 100 companies are trying to get their IT depts. to
support Mozilla instead of IE or Netscape 4 only. This is another critical
feature that will help them in this effort.

It is important to get more people using Mozilla inside companies so they then
want to use it at home etc. I know I'm preaching to the choir here!

This comment from a content management vendor:

Everyone from Vignette to Broadvision uses IE for their online editing tool
because of "contenteditable". There is nothing else available for this task
short of a java applet. Mozilla's adoption of this feature should naturally be
embraced by this market as well as countless developers all around the World who
expose editing functionality for their clients in this manner. Mozilla would
allow this functionality to be exposed on the macintosh platform which is used
by better than 90% of the design/ad agencies, which would further drive adoption. 
Keywords: nsbeta1
*This feature will have numerous benefits leading to increased Mozilla browser

I really wonder if the Mozilla folks know how true that statement is. This
feature has been a long time coming, and I've seen a lot of statements along the
lines of "we're concentrating on features useful to end users instead." Right
now I'm recommending IE to my end users, many of whom prefer Netscape 6.x,
because of the lack of this one thing. Not only is Mozilla not gaining users,
it's actively losing them.

The combination of browser based editing and Mozilla's cross-platform nature is
a killer app, people. There is a huge opportunity here, for both Mozilla and
developers. I've been following this with increasing frustration (I have one
client who's a Mac user who asks me when I'll have something he can use every
few weeks) and I've about given up hope. I wish I could help, but I've tried
several different ways of doing this in Moz (as well as the Bitflux and Xopus
editors), but nothing works nearly well enough to actually be usable by my
clients. I assume it requires hacking in the core Moz code and I'm no
programmer, so I'm useless there (go ahead, I gave you the opening, smack me
down ;).

Give me contentEditable functionality and I can (and will) have my editor ported
in less than a couple of hours. Once that's done I will have recommended IE to
my clients for the last time. I *know* I'm not the only one that's true of. If
you want to see an overnight explosion of new end users, it's right there waiting.
I hope the mozilla developers are listening to this latest round of requests. It
is really true that this is the thing that could really drive adoption forward.
The request should given much more priority.

We have many designer clients who do not have Windows machines. We keep a couple
of laptops around to loan out to them. One of our designers who is on his 3rd
project with us finally broke down and bought VirtualPC (we have been telling
him Mozilla will have this functionality soon...).

The people who are requesting this feature should not be counted as a single
user (if that is the determing criteria for working on bugs). Rather they should
be counted as 10s or 100s or possibly 1000s of users because they would directly
cause the spread of the browser. When this feature is implemented the browser
will grow much stronger roots.

Is there any kind of a status report from the moz devs on where this feature is?

Likewise, we have a site that is in use by thousands daily and have a feature
that I am not comfortable really pushing unless it can be offered
cross-platform. I would be behind the feature if I could recommend
Netscape/Mozilla for it.
As one of the main editor engineers working for Netscape, I will again say we 
are working very hard toward this goal. I'm very sorry we don't have andy specs
up, but basically we plan to support the MS/IE interfaces.
I'm talking with our own evangalism people today and also with the DIG group on
this issue. We are making good progress in 1.2 timeframe to have major editor
embedding work done that will enable this to proceed.
That is great news.  I'm sure there are many like me subscribed to this bug that
over the past couple months have seen many users subscribing to the bug, but
haven't really gotten any update on the fact that developers were actually
working on it.  The last few posts I'm sure will give many of the subscribers a
lot of hope that we will soon see this appearing in nightly builds and releases.
 Thanks again for your efforts developers.
Great News Charles!

Just to clarify though, are you saying that the contentEditable attribute is 
scheduled for inclusion in the 1.2 final (October 30, 2002)? Or are you saying 
that you will have made the necessary modifications to the editor that will 
ALLOW contenteditable to be worked on and included in a future release? If the 
latter is the case, what is the projected date that we will see this in 
release? And perhaps when in a nightly build? 

Someone Please alert the list when this appears in a nightly build!!!
"contentEditable" attribute will probably not make it by 1.2, unless we are 
exceedingly lucky. And don't worry! You'll know when anything appears in a 
nightly build.
We need to investigate some security and events/focus issues besides the basic
editor work we are now doing.
We'll post time estimates as soon as we can.
For all people cc'd who want to use this functionality, you can help in a
couple of ways:

1) Please read this attached file, which contains the potential base set of
features that would be available.

2) Attach a text or HTML file with any additional "must have" and "nice to
have" features that would make content editable acceptable for you. 

Any example URLs that illustrate your requested functionality would be really
helpful. Or you could attach additional screenshots illustrating features
you're using in your systems today...or whatever you think will help.

(Please make sure to use Create an Attachment instead of writing in Comments,
which could very well get lost in this long bug.)

There's no guarantee all requirements will be met but your input will provide
great direction. Thanks.
I think the features listed in the attachment are heading in the wrong
direction.  By simply allowing javascript access to the selected text or the
word under the insertion point, and the ability to wrap/unwrap any arbitrary tag
around that text, or find out what tags inclose that text, it would be easy to
implement all these features and more in javascript.  Then a simple .js file
could be included to simulate the microsoft functionality for those who want it,
but those who want to do more will (like me) will have the power to do it.  
I agree that inserting arbitrary text or HTML at the current cursor position or
around the current selection is a must-have feature. But I also think that
providing easy methods for performing the functions mentioned in the previous
attachment isn't a bad idea, especially if it facilitates compatibility with
currently implemented web apps (that use the M$HTML functions).
We at Bitflux ( don't need all those HTML
Capitibilities, either, but I see certainly use for them for a lot of people.
But what we really would like is to get rid of our
now-written-in-js-character-inserting-with-caret-mode :) It works, but a lot of
people complain, that it's not the "Real Thing". For example, we can't simulate
the common use of the "end" key and going onto the beginning of a line.
Therefore what we (not speaking for others) really need is just good character
editing possibilities (as typing, deleting, moving around and maybe copy/paste)
within dedicated notes. If we then still can use the standard JS/DOM stuff
within that nodes, we're all more than happy and satisfied. And we should be
able to use it on non-html-namespace-nodes, as well, please :)
Just my 2 cents and thanks for your great work.
Ditto the bitflux guys et al. That is all we are looking for too. We would not
use anything in the list posted a few messages ago.
One thing I like about IE is the ability to click an item and the control
(outerHTML) is selected. When you click again you are inside the element. 

Also, I would want the ability to tab through the nodes.  Example:

<div class="article">
  <div class="section">
    <h2>Sub title</h2>
    <p>Some <strong>para</strong> stuff</p>

I can click on the article div which gets selected - when I hit tab it goes to
the H1, next to the section div, then to the H2, then the p, then the strong.
The tabbing selects the entire node/element. If the enter key is pressed focus
goes inside the selected element. I will get an example up tomorrow sometime.

Attached file 2 extra wishlist items
I agree with the sentiment that it would be better simply to expose a usable API
for caret browsing and so on, because that will better lever the skills of the
wider mozilla community - i.e. javascript coding and UI design.

However, I'd rather have a suboptimal solution that it largely compatible with
IE contenteditable in the next few months, than an optimal solution in a couple
of years.  I don't care if it's written in *machine code*, if we can get it soon :-)

Thanks for the feedback, netscape people.
One of the greatest features of MSIE WYSIWYG Editors is a capability of pasting
a richtext from a clipboard -- it is particularly important for cut-n-paste from
MS Word. This is needed for those site administrators, who don't create a text
at  webpage, but transfer texts to the web.

If it is possible (at least, on Win32) to implement such feature, it will be great.
> One of the greatest features of MSIE WYSIWYG Editors is a capability of > pasting richtext from a clipboard  If this get implemented, you must be able to _turn it off_! We have so many problems, where clients paste their text in times new roman, and then a piece of Times text appears on a Verdana site. 
>We have so many problems, where clients paste their text in times new roman,
and then a piece of Times text appears on a Verdana site. 

It is so simple to remove any unwanted tags and attributes...

I can tell you about it.

>If this get implemented, you must be able to _turn it off_! 

Yes, you are right.
Attached file contentEditable API
I have been working with contentEditable since it was first introduced. My
company produces a commercial CMS that uses this functionality. Here's an
suggested API for Mozilla contentEditable:
Why not just implement it the same way as IE?
Attached are my thoughts on a contentEditable implementation. I do want to
point out that I don't want or need Composer or FrontPage level functionality.
The page layouts and styling will already be set; I just need to be able to
give my clients the ability to change some of the content within the site, and
give them some functionality as far as structural markup goes. They don't need
to decide that a heading is +1 font size in dark red; they just need to be able
to mark it as a heading.

I should also probably point out that one of the reasons I'm so hot to have
this is that I've found that Mozilla is a vastly superior development
environment to IE. I actually do most of my development in Moz, then tweak as
necessary to make it work in IE. Having to tell people they need IE to use the
end result just kills me (I just had a client yesterday tell me she'd use IE if
it was absolutely necessary, but she'd really rather find another way).

Cross platform in-browser editing is my current holy grail, and you guys are so
close. I really do believe making this available will make Mozilla *the*
browser to use for content management, and given that there is no question in
my mind that this is where the Web is headed, well... hopefully it'll come

Thanks folks.
Here is my list of wishes
Here is my list of wishes
Attachment #102484 - Attachment is obsolete: true
also has some ideas of how one might implement editable content... 
IE emulation through Javascript, etc...
A summary from attached the document:

An emulation of content-editable is *not* required, just the building blocks to
allow developers to make something similar. A proper implementation of
something like the (now-defunct) CSS3 UI WD withe the above features would be
Comment #130 and it's attachment say exactly what I was trying to say, but much 
clearer.  I really think this would be the way to go.  And as someone already 
said, you could implement IE's functionality in javascript and automatically 
load that script when a page designed for IE is viewed.
I will be seemingly one of the few voices *against* this proposed "feature",
mostly because suddenly adding contenteditable attributes will not allow pages
to validate  as valid HTML.  

In addition, while we're adding contenteditable, can we please get <blink> back,
and maybe <marquee> since IE has that, too?  

All that I ask is that everyone stop for a second, and think of the standards,
and the possible repercussions of another browser war.
> I will be seemingly one of the few voices *against* this proposed "feature",
> mostly because suddenly adding contenteditable attributes will not allow pages
> to validate as valid HTML.

You can add this attributes dynamically via JS for contenteditable user-agents, no? 
> I will be seemingly one of the few voices *against* this proposed "feature",
> mostly because suddenly adding contenteditable attributes will not allow 
> pages to validate as valid HTML.  

Alright, I take that back, my main reason for being opposed to this idea is
because of the factor of playing "catch-up" with IE. Please don't do it. Stick
to the W3C specs, and only the W3C specs. Otherwise, In 8 years, we'll be stuck
rewriting another browser from scratch.

Don't get me wrong, I *like* this idea of being able to edit a page's contents
directly in the browser, and I've played with XOpus and have been very impressed
with what it can do.  

However, I can't agree with a browser (or the group of people who are
responsible for it) that adds a feature for rendering or interacting with a web
page that is not in the W3C's specs, or tries to compete with another browser.

Say no to war on IE.
I don't see how the goal of this RFE, allow page to make arbitrary elements
user-editable in browser, violates html validity or a spec.  IE's use of a
contentEditable attribute does this, but there is no reason that mozilla can't
expose a simple editing API that doesn't violate existing specifications.

mozilla's mission is not to only implement things that are standardized.  There
is no standard for how to create an e-mail compose box (as far as I know at
least :) ), yet mozilla still implements one.  Likewise, there is no standard
for how an html (or xml) editor should work.  There is a standard for its
output, so provided that the result of using mozilla's implementation for this
RFE is valid html/xml, this should be a non-issue.
> I will be seemingly one of the few voices *against* this proposed "feature",
> mostly because suddenly adding contenteditable attributes will not allow 
> pages to validate as valid HTML.  

Actually this is a valid concern and Mozilla should indeed not implement a 
contentEditable attribute. A CSS property is a much cleaner approach, and more 
useful. If you still want the attribute then you can do that with one line of 
------- Additional Comments From  2002-10-11 01:35
>> I will be seemingly one of the few voices *against* this proposed "feature",
>> mostly because suddenly adding contenteditable attributes will not allow 
>> pages to validate as valid HTML.  

>Actually this is a valid concern and Mozilla should indeed not implement a 
>contentEditable attribute. A CSS property is a much cleaner approach, and more 
>useful. If you still want the attribute then you can do that with one line of 

A little less than a year ago I asked both the W3c CSS and HTML lists about
this. The CSS list powers that be said it was an HTML concern. The HTML list
powers said it was an UA's problem - it should not be part of the spec. Here is
a post I found in a quick search:

As to those who do not know how to use this without creating invalid markup, I
say you don't know how to use it. You can assign these items on page load or at
other events. There is no need to write your HTML markup invalidly.

I don't think the question here is creating valid XHTML documents and it is not
a question of being backwards compatible.

The goal is to provide the functionality to get away from a static document to a
document (or part of a document) that can edited by the user directly inside the
browser. (Universal Canvas?)

The goal is not extend HTML. The goal is to allow developers to create
applications that allows editing.

I agree that the idea to use an contentEditable attribute is a bit stupid. It
was most likely done that way because it allowd MS a simple implemenation. MS
has a history of using attributes when CSS is more suitable.

The way to go in Mozilla is of course to use a CSS property. How about
-moz-user-modify or is that only for inputs? This also fits well with how IE is
doing it with contentEditable wich uses the inherit value by default which
follows the CSS semantic for the same value.

Just like -moz-binding is ignored by non Mozilla browsers, -moz-user-modify is
ignored as well. Going this way will allow any XML document to validate and it
will also make all old browsers being able to display the significant information.
> All that I ask is that everyone stop for a second, and think of the standards,
> and the possible repercussions of another browser war.

Standards are not standards until they are standardized. That's true for
everything in our world. Everything. And standards can becom extinct and
replaced by another one. And standards can change, Eric Meyer saying that
in that case, they are not standards any more until they are standardized again.

There is no current standard for making an element editable. And there is
no standards body currently working on this. It implies that in the meantime,
all vendors are going to find the best implementation they can have, and the day
they have it, they'll ask for a standards body to be the battlefield.

Being committed to standards does not mean not being pragmatic.

Daniel, Netscape's rep at CSS WG
as there is no w3c standard for this and a very wide spread existing
implementation, just do it simple.. as mentioned before, implement contenteditable

forget all the xhtml/xml blah stuff for the first cut... we just want something
simple which works...

honestly, if the xopus code was reliable it would be enough...

the direction of all the editor rework is cool, but that is not IMHO what this
bug is about... its about simple basic editing of text

KISS principle...
But what does it mean to "just implement contentEditable"? Because surely this
attribute does not have a well-defined semantics: all we can do is say how it
works on any specific version of Internet Explorer - but Microsoft may well add
arbitrary new functionality in future releases.
>------- Additional Comments From  2002-10-11 05:43 -------
>But what does it mean to "just implement contentEditable"? Because surely this
>attribute does not have a well-defined semantics: all we can do is say how it
>works on any specific version of Internet Explorer - but Microsoft may well add
>arbitrary new functionality in future releases.

So what? The basic functionality needed is to be able to select nodes or partial
nodes and affect them with JS. Most of the stuff you should be handling yourself
(especially if you are trying to validate the content).

Aside: Since contentEditable did not exist before MS created it, then they
defined it. It is defined.

> Being committed to standards does not mean not being pragmatic.

YES! that is it. Mozilla is being caged into standards which are already 
subsets of another browser ruling the planet. What are thet chances that 
mozilla will be adapted widely in its present form?-> uhm almost 2% jump to 5% 
perhaps. By the way, is Microsoft sleeping at the moment? NO! they will come up 
with even more unignorable features pushing Mozilla back to its oblivious 
stage. By the way, who is more active in w3c anyways? MS?
Keywords: topembedtopembed-
Alright, I understand that it's possible to mark up a page that will validate
and still use the attribute.  Now convince me that this won't spark another
browser war.  Why should Mozilla care what IE does?  By implementing nonstandard
things that IE does, the developers are admitting that IE is better, and they
want Mozilla to be more like IE.  Am I way off base here?
This discussion is destined to degenerate into a flame war. I suggest moving
non-development related comments to the newsgroups. This bug is already spammed
enough as it is (not that I haven't contributed to this myself).
Tony, see comment 10 and comment 114. The plan is to implement the IE interface 
and for good reason: Microsoft IE 5-6 have more than 90% of the browser market 
(That's being generous to non-Microsoft browsers). Microsoft extensions such as 
contenteditable are de facto standards. This isn't the first time (see the some 
of the DHTML properties) and doubt it will be the last time that Mozilla 
implements a Microsoft extension. If Mozilla wants to even be a viable 
alternative, it needs to support a number of Microsoft features. Otherwise the 
switching cost is too great, both for web site developers to support Mozilla 
and for users to use Mozilla (or derivatives).

Also see comment 108, comment 110, and comment 111, and comment 113. I see this 
as pragmatic: the more that is in common between the major browsers, the better 
for everyone.
"Alright, I understand that it's possible to mark up a page that will validate
and still use the attribute.  Now convince me that this won't spark another
browser war.  Why should Mozilla care what IE does?  By implementing nonstandard
things that IE does, the developers are admitting that IE is better, and they
want Mozilla to be more like IE.  Am I way off base here?"

My god, get off the ego trip. I say we just be compatible with IE so that
Mozilla will be compatible with more websites and maybe we'll get more then 0.8%
of the market some day.
"Why should Mozilla care what IE does?  By implementing nonstandard
things that IE does, the developers are admitting that IE is better, and they
want Mozilla to be more like IE.  Am I way off base here?"

Surely it can't have escaped your notice that this bug's raison d'etre is that 
IE *is* better than Mozilla with respect to editable content. It may be that 
Mozilla can implement editable content in a more coherent way than through the 
contentEditable attribute, but the more market share Mozilla loses through not 
providing editable content in *whatever* form, the more unlikely it is that 
Mozilla will be able to influence *any* future direction of browser standards.
Summary: [RFE] allow page to make arbitrary elements user-editable in browser → allow page to make arbitrary elements user-editable in browser
Blocks: 174709
Alright, I still think it's a bad idea, but in the interest of letting people
get to work, I'll drop the argument.

Best of luck,
Coming very late into the game with this thread...I would have to argue:  
contentEditable would be fantastic; duplicating MS functionality using 
execCommand et al would be horrendous.  I've just finished a 2 month long 
battle with creating a CMS WYSIWYG editor, and the workarounds I had to 
perform simply because of the MS model force me to drink...

I do not know about anyone else who has created / talked about the foundation 
of a CMS, but there is one thing that client have ALWAYS wanted:  the ability 
to limit the user of the CMS to a very particular style sheet.  The MS control 
does not allow you to do this without nasty workarounds (which i have done), 
but it would be SO much better if there were a way to insert / alter / edit 
the entire node properties through assignment.  Perhaps something like 
document.execCommand, but instead of "guessing" which parameters are 
available, the method could perhaps be passed an object (perhaps even a Node), 
which would serve as the template for the execCommand.

This to me (aside from the Range object) would be the most important thing in 
a WYSIWYG editor model.
I would like to draw back attention to comment #119. Rib Rdb I think has a good 
point with what he says there. What he describes would be just enough to create 
a range of functionalities. And it would be 'clean' as well (right?), as 
opposed to the m$ contenteditable ****.
Blocks: grouper
*** Bug 177128 has been marked as a duplicate of this bug. ***
Mozilla should omit clipboard commands from whatever API it gives to web pages
for wysiwyg editing.  Since Mozilla doesn't give users cut/copy/paste buttons
on the toolbar whenever they focus non-wysiwyg text fields, I don't think this
should be a problem.
jruderman: I agree with you that the clipboard should not be scriptable, but
note that text areas and other input-fields are clipboard enabled. For example,
you can paste into a text area via the content menu, the Edit menu, or via the
platform-specific keyboard accelerator.

In the same way, I'd be looking to have the clipboard functions automagically
enabled for any elements/nodes marked as user-editable, and disabled when not

Text editing without copy and paste is pretty sucky.
It would be nice to be able to script as a result of copy/paste, not necessarily
to initiate copy/paste. A related example is dragging of images into an area
from an image repository in a separate frame.
I will take whatever the engineers are able to give us as quickly as they can. 
I am hearing this will be in the next release of moz.

However, it would be shortsighted to abandon the ability to paste to/from 
clipboard from an editable area. This is something that users consider 
fundamental to any input area.

Rich text paste would be useful.
Did this make the target milestone of 1.2beta?
Keywords: mozilla1.2mozilla1.3
Target Milestone: mozilla1.2beta → mozilla1.3beta
Hey, you should all download the latest Mozilla build (1.3alpha --- sorry, this
did not make 1.2) and try this:
Nice work. This is definately a good start.

I guess you already know that Mozilla raises an exception if this is tried twice
in the same session.

Should we start filing bugs for this or wait until more is in place?
Erik Arvidsson--
>I guess you already know that Mozilla raises an exception if this is tried
>twice in the same session.
Are you trying to create to editable iframes or do you mean if you reload?
There is a bug filed about the 'reload' problem which is a regression (Monday's
build works for that; possibly Tuesday's build too?).

>Should we start filing bugs for this or wait until more is in place?
Depends what it is.  If it's a security exploit, file the bug and be sure I'm
cc'd (  If it's a missing command, there is another bug
filed on it (look in my bug list) so add a comment to that bug.

At this point I have no plans to implement the selection api IE has since IE's
own implementation is buggy/inconsistent and the document api seems to be
*** Bug 151967 has been marked as a duplicate of this bug. ***
I've been playing around with javascript to make an inline html editor, one that
would drive off style sheets and write "proper" XHTML. It's not trying to be IE.
I think Mozilla opens up a lot more possibilities. The result so far is at: 

The basic selection handling is there. Deletion was the biggest pain due in part
to what I think is a browser bug but it's largely there now but for debugging.
Styles et al should come before christmas.   
Hey folks,

I just got the chance to check this out a little, and it looks as if it only
works in an iframe? Is that so, and if so, is it going to stay that way? That
would make it next to useless for the way I use this functionality; I really
need a way to make a fragment of the currently loaded document editable.

Is a contentEditable attribute coming, or is setting an entire document to
designMode all there going to be (my apologies if these questions are already
answered somewhere; I've searched, but not found anything outside the midas spec
page)? (comment 167)--

You are correct that right now the rich editing is only available on an iframe's
document.  When that work is completed, someone may be able to undertake the
content editable aspects which will be much trickier.

Will it stay this way?  Hard to say for sure.  If someone steps up and writes
the code and tests it, it can go in.  If not, then it won't.  Personally, I
won't be able to undertake this task for the foreseeable future (next 3 months).
 Are you sure you can't use iframes which contain the data you want to edit?

> setting an entire document to designMode all there going to be
Setting designMode in mozilla is done on an iframe's document (not the parent
Thanks for the info.

>  Are you sure you can't use iframes which contain the data you want to edit?

Well, I was hoping to duplicate the operation of my editor for IE, which depends
on the ability to set certain (and arbitrary) blocks of a page editable in place.

I might be able to fake it with iframes, but not easily and not without writing
a completely different implementation, which I was hoping to avoid. I'll spend
some time looking into it.

> Setting designMode in mozilla is done on an iframe's document (not the parent
> document).

Yes, I understand that; sorry if I wasn't clear. Again, though, for me to be
able to avoid maintaining two totally separate code bases (which I'm not sure I
have the time for) I'd need to be able to have only certain parts of that loaded
document be editable, or be able to load fragments of an existing document as
the iframe's doc. Doable, but not easily with my current backend, and given that
IE works now I just don't know that I can justify the time and effort. I'd love
to have something cross platform, but all my current clients have Windows
available or can delegate to someone who does, so...

In any case, thanks for the prompt answer; I do appreciate it. (comment 169)--
>  ...duplicate the operation of my editor for IE...
You might want to look at the samples at these locations (which I'm told work in
both IE and mozilla):

The above don't use contenteditable but do use designMode and iframes.  It may
not work for you in your situation if you have a complex process which involves
multiple editors etc.
> You might want to look at the samples at these locations (which I'm told work in
> both IE and mozilla):

I'd already seen both of those, but thanks. My problem isn't that iframes don't
work in IE; it's that I tried and abandoned that approach a long time ago, and
my current setup isn't really compatible with doing it that way.

In essence, making an editable iframe is doing things the old way, only instead
of having just a form on a page to enter plain text into you have something that
can create html. An improvement, but the other features of modern browsers make
so much more possible, and I'm loathe to go back to that way of doing things. It
may be fine for something like a blog or posting to a message board, but get
beyond that and things start to get clunky.

I've played with the iframe stuff a little, and unfortunately it's not going to
work for me. I may do something with it in the future so those who can't or
won't use IE on Windows have *something* to work with, but as it won't be nearly
as seamless or as usable as what I already have I fear my best bet is to keep
recommending that my clients use IE. Disappointing, that.
so do you want inline editing, of HTML as HTML? Say user-modify=read-write for a
section, say any id'ed section, let's you type away in that section. That's what
I want. 

As I said in a previous comment (#166), I'm playing with javascript to allow
inline editing like that. It's basic now but it should support styles and spans
by christmas and there's a focus bug in the browser that can kick in after
deletion. I don't think you need any custom widget per se, just something to
push the DOM around as you click away. 
conor play:

Yes, I took a look at what you have and that's very much along the lines of what
I need. I had tried to do something like this in Moz some time ago, but various
bugs in the range object prevented it from working well enough to be usable.

What you've got done so far is too basic for my uses, but where you plan to go
with it sounds good. Given that it doesn't look like Moz is going to get a
contentEditable attribute, I'll take another look. I dislike having to deal with
all the keystroke handling manually (and using caret browsing *really* feels
like a nasty kluge), but if that's the way it is then that's the way it is.

If this looks like it'll eventually work for me and I can budget some time, I'd
be happy to contribute to the effort if you'd like. In any case I'll take a
closer look at it within the next few days.
Flags: blocking1.3a?
Flags: blocking1.3a? → blocking1.3a-
We have today released a new sub-release of Xopus: contentEditable for
Mozilla. Please look it up at

Mozilla 1.3 supports editing of pages, but only by entering designmode
for a complete page. This obviously isn't how you and me would want it, but 
still it's a start.

Our unsurpassed moz2ie.js library has now been extended to tweek this
designmode behavior and make it look like true contenteditable the way
Bill intended it to be.

You can make almost any HTML element editable using one of two ways:
1.  <div contenteditable="true">you can edit this!</div>
2.  <div id="test">you can edit this</div>
    <script language="javascript">
      document.getElementById('test').contentEditable = true;

We hope this will help developers build richer Mozilla based internet

Our implementation isn't complete yet, of course. Please feel free to enhance 
the code.
Flags: blocking1.3b?
Flags: blocking1.3b? → blocking1.3b-
here's another iteration of inline editing using a tweeked DOM: Use either -moz-user-modify CSS or
ContentEditable and include one file, wrap.js, in any page you want to make
editable. This works in the currently released browsers - it doesn't rely on
"DesignMode". Of course, it needs a lot of work still and a good reliability
pass is in order.

My two pence worth on inline editing in Mozilla is:
- with some fixes, the core Mozilla DOM can easily and cleanly support editing.
Mainly this amounts to a few extensions and fixes to Range.
- cross browser compatibility should mean nothing more than supporting IE's
proprietary contentEditable attribute. It does not necessitate emulation of
every IE DOM routine and attribute. ContentEditable should be supported but
support should mean letting end users set this property to activate and
deactivate native DOM editing appropriately.
- fragmenting the code base by maintaining a proprietary "editor" DOM is a waste
of resources and of the core DOM's potential. It will probably mean never
pulling ahead of IE, at least in the area of editing. With all the work in XML,
XHTML and CSS, there is a ton of room to leap frog current IE-based editing. It
seems a shame to just "me too" old IE features rather than supporting more
through fixes and small extensions to the core DOM.

Happy holidays!
Why the cursor is visible on the entire content? Isnt it suppose to show up if
the  purpose is editing only? It is good to have contentEditable feature for
Mozilla ,but Users should not get the feeling that they are on editmode for all
the web pages they browse. Is there a way to turn it off or it is there to
stay(hope not).
Never mind, it is fixed on today's build.
If I understand this bug correctly, then it would make Mozilla meet one of
TimBL's visions for a browser.  It could also edit.  See which
is a browser/editor that works in this way. 
(added myself to the CC list)
I'm very interested in this, but only really if it can give proper XHTML editing
as a minimum, and free XML editing (with CSS formatting of XML elements) in the
best case. The former would allow me to use XSLT to get the output into the
correct format without doing any messy HTML->XHTML conversions first, which
would be great, and the latter would just be fantastic. Still, the progress made
so far is good.
Yes I agree with that it should generate proper XML compliant code. This allows
us to do:

Editor => XML

or even:


And all without the need of cleaning up HTML code inserted via the editor.
This prevents us from the garbage in garbage out routines ;-)

Microsoft's contentEditable also has some "support" for this:
When you copy/paste data form Word 2000 into a contenteditable div is shows up
as xhtml-ish code...

Keep up the good stuff
Oh Please JP,

You're right Microsoft insert word data as xhtml ****, in the meaning that it
has a XML-valid markup. It does however include all kinds of proprietary garbage
tags and a lot of Markup that is very inefficient. I sure hope the Mozilla crew
will make something that produces valid XML, and it would be very nice to get
CLEAN XHTML, but I'm not throwing away my garbage cleanup routines just yet.
Sorry for the sarcasm, but I think it VERY hard to produce clean HTML,
considering my cleanup routines(and others I've seen) aren't altogether perfect
yet either.
I know, I know. My clean up regexz are starting looking like the Himalayas to
straiten Micro$oft pastes... 
*** Bug 191833 has been marked as a duplicate of this bug. ***
Flags: blocking1.3?
minusing request for 1.3; there isn't even a patch to land here!

Some of you watching this bug may be interested in trying this in a recent 1.3
also see:

Any issues found should be filed as new bugs (assuming they aren't already
filed).  Updates to the above documentation are welcome too!
Flags: blocking1.3? → blocking1.3-
Thanks for the very nice example. There are some errors being reported in IE6
(Windows XP pro) regarding the InitToolbarButtons(); functions as well as when
trying to view source. Anyone else see this?

Overall though, a very nice example and glad to see this finally available. If
anyone has any more examples and contributions, please post them - this is very
exciting stuff!!!

I am curious if anyone besides myself is in the process of creating a flash
based toolbar for the editor? I think this would be perfect since you could
execute the function calls using the getURL() syntax from flash and it would
atleast insure that your toolbar would look exactly the same in IE as in Moz.
I found that IE 6.0 has a problem with addEventListner.

I used thist construct which works for me.

  if(!document.addEventListener) { 
	document.onmousedown = dismisscolorpalette;
	document.getElementById("edit").contentWindow.document.onmousedown =
	document.onkeypress = dismisscolorpalette;
	document.getElementById("edit").contentWindow.document.onkeypress =
  } else {
	document.addEventListener("mousedown", dismisscolorpalette, true);
	document.getElementById("edit").contentWindow.document.addEventListener("mousedown", dismisscolorpalette, true);
	document.addEventListener("keypress", dismisscolorpalette, true);
	document.getElementById("edit").contentWindow.document.addEventListener("keypress", dismisscolorpalette, true);
In order to prevent this bug from getting more spammed than it already is, I've
set up a Midas listserv to facilitate discussion among web application
developers regarding Midas implementation and troubleshooting. I will send you
all an invite shortly.
Sorry if I invited some of you twice, I was having trouble mass inviting
everyone at once. Anyway, here's the info regarding the mailing list...

You can subscribe or unsubscribe to the list here:

If you are a member, you can post by emailing
re: comment 186, IE does not implement addEventListener. If memory serves me
the equivalent call is |window.attachEvent("onload", myHandler);| (for the case 
ofsetting an onload handler). Note there is no 'capturing' parameter, and the 
event identifier includes "on".
I don't know if this bug is still "active" given Midas' release but to the
interested I've added to the pure DOM-based implementation of ContentEditable
that I'd posted here around Christmas (comment #175). My main goal is an
XHTML/XML editing module that builds on the w3c DOM - among other things, such a
module provides for a straightforward implementation of standards-conformant
ContentEditable. Demos and scripts and more information at
for those interested specifically in "contentEditable" as opposed to
"designMode", the contentEditable/mozUserModify implementation I posted about
before is now a mozdev project called "mozile" for Moz(ila) i(n)l(ine) e(ditor):
adt: nsbeta1-
Keywords: nsbeta1nsbeta1-
*** Bug 209553 has been marked as a duplicate of this bug. ***
OK, I'm now running 1.6b and this was targetted for 1.3b. What is happening with contentEditable? 
Yes, we have Mozile, but I would much rather have it in Mozilla (and Safari, but that's another 
(In reply to comment #194)
> OK, I'm now running 1.6b and this was targetted for 1.3b. What is happening
with contentEditable?

It appears to be dead. Nobody in the Mozilla organization appears to have a clue
as to why it would be useful, nor do they appear to be willing to get one from
those who are more informed.

> Yes, we have Mozile, but I would much rather have it in Mozilla (and Safari,
but that's another 
> case).

You may get your wish wrt Safari. Dave Hyatt has said that contentEditable is
near the top of his list of things to implement, and I read within the last
couple of weeks (can't remember where or I'd give a link) that Safari will be
getting cE in the not too distant future.

IE and Safari users will therefore be moving ahead with the functionality that
users are demanding while Mozilla argues about important stuff like who gets to
use what icon...
This is great news! Finally we will have a browser on OS X that will support contentEditable. I actually 
did think that Mozilla would get there *much* faster than Safari, but how wrong I was! Time to degrade 
features for Mozilla or drop Mozilla completely from our CMS-product then.

Quite sad actually... that it takes >2.5 years to implement a heavily requested feature (it's not magic) in 
Has this perhaps been silently solved - at least for some people's needs - while
we weren't looking?:-) Mihai Bazon's HTMLArea (currently at version 3.0 RC 1)
works with both IE 5.5+ and Mozilla 1.3+ - apparently using the "MIDAS"
component in the latter case. Works with Firefox as well as Mozilla. See: 
HTMLArea - A replacement for TEXTAREA elements.

You are right, it will work for some people, but not for those wanting to, for exemple, edit certain parts 
of a web page, but not others.
The Midas component in Mozilla 1.3+ and Firefox 0.6.1+ implements "designMode",
which is very similar to MSIE's "contentEditable". It works great for editing
content in web content management systems etc. and it is quite easy to make a
simple web content editor with basic functionality. (However, cross-browser
support and more advanced functionality requires a lot of additional
Javascipt/DOM programming to handle differences and limitations).

We have supported it in our own cross-platform web content editor product
( ever since Mozilla 1.3, and we would
love to hear from you if it does not work with your version of Mozilla 1.3+ /
Firefox 0.7+ (on Macintosh, Linux or Windows).
If HTMLArea doesn't meet your needs, see the Bitflux editor
Insults about cluelessness from people who spam bugs with advocacy comments are
a good reason to revoke bugzilla access from those clueless people.

Clueless Safari fans can cling to every word from the mouth of hyatt if they
want to, but let's get real and talk again (and not in the bug system) only
after Safari actually ships a working content-editable support.

This bug is being degraded by childish noise that does not help get it fixed. 
Since I still (in spite of being insulted by the likes of comment 195's author)
value content-editable, but have no time to implement it myself, I am actively
looking for volunteers who can do the hacking to make it work in Mozilla.

However, most of the talented hackers I know dislike bugspam intensely, so I'm
inclined to close this bug, open another one, and revoke bugzilla access from
anyone who spams that bug.  How's that for vending a clue, hmm?

(In reply to comment #201)

> This bug is being degraded by childish noise that does not help get it fixed. 
> Since I still (in spite of being insulted by the likes of comment 195's author)
> value content-editable, but have no time to implement it myself, I am actively
> looking for volunteers who can do the hacking to make it work in Mozilla.


I think it would be useful for people like me that would like to help in having
this feature in place but have no strong knowledge of the mozilla internals to
have a few pointers on how this should be done.

I mean, mozilla is a relatively complex piece of software and content-editable
is not something you get from a side (like an few XUL and javascript files), but
a rather intrusive feature that will probably have to deal with a lot of the
mozilla internals.

Personally, I'm scared by the complexity of this task. But it would be
*extremely* helpful to have an insider view of the problem and guide people
inside the jungle so that they don't have to explore it themselves.

I think this is the reason why this bug hasn't been fixed yet: those who know
how to implement it are busy doing more important things and those who really
want this feature are normally javascript programmers and have no clue on how to
deal with the mozilla internals or are scared by the complexity of the task.

All we need is a little bridge across these two islands so that we can walk to
your side and help.
(In reply to comment #202)

> Personally, I'm scared by the complexity of this task. But it would be
> *extremely* helpful to have an insider view of the problem and guide people
> inside the jungle so that they don't have to explore it themselves.

I agree. I think I know how to implement contentEditable in Mozilla.
But the current bug went totally out of control, from a comments point of view.
I am just fed up with reading noise, and seeing the useful comments in this bug
drown in an ocean of spam.

> I think this is the reason why this bug hasn't been fixed yet: those who know
> how to implement it are busy doing more important things and those who really
> want this feature are normally javascript programmers and have no clue on how to
> deal with the mozilla internals or are scared by the complexity of the task.

This is the case for all bugs.

> All we need is a little bridge across these two islands so that we can walk to
> your side and help.

Eh. We don't need "a little bridge". We need 60 hours days. 
More contributors, less trollers.
Closing (see comment #201).
Closed: 18 years ago
Resolution: --- → WONTFIX
*** Bug 249692 has been marked as a duplicate of this bug. ***
Summary: allow page to make arbitrary elements user-editable in browser → allow page to make arbitrary elements user-editable in browser (contentEditable attribute)
I was wondering, have we gotten any closer to a working contentEditable solution?
(In reply to comment #206)
> I was wondering, have we gotten any closer to a working contentEditable solution?

It's unfortunate that scanning this case I don't recall seeing anyone mention
the killer reason for having something like contentEditable.

This is to allow Mozilla to become the 'universal canvas' for UI design across
platforms. With SVG as well, you can then design complex UI that is controlled
by an outside business application, written in something stronger than a script
language (e.g Java, Mono etc).

Commercially, this is what the company I work for has done. We use IE as the
rendering surface for our UI and we also use it as the print and reporting
engine (there's a 'DrawToDC' method that allows anything on the browser to be
sent to the printer, though I doubt Mozilla has anything directly comparable
with this.

The business logic communicates with the UI via Javascript (using execScript).
This provides a very elegant tiered layer which can be customised in the field.

Using behaviors we have UI widgets like tabbed dialogues etc (though XUL would
obviously be an acceptable replacement for that). But I need to be able to mark
individual fields contenteditable and I also need a working textRange object and
good Javascript hooks before I could consider doing anything like this outside
of IE.

So that's the real reason for contentEditable; not just in-place HTML editing of
web pages. In our application, in fact, all HTML is loaded from local files. But
HTML provides everything that Avalon promises - only here and now. 

PS: If I had to vote, I would much prefer contentEditable was a style, so that I
could use CSS to control which fields are enabled rather than have the rather
ugly contenteditable=true attribute.
No longer blocks: majorbugs
*** Bug 322335 has been marked as a duplicate of this bug. ***
*** Bug 340375 has been marked as a duplicate of this bug. ***
Fixed on trunk in bug 237964, so unless something surprising happens, this will be in of Firefox 3.
Alias: midas
No longer depends on: 96392, edembed
Keywords: helpwanted
Duplicate of bug: contenteditable
Depends on: 1496769
Depends on: 1497480
You need to log in before you can comment on or make changes to this bug.