Closed Bug 97284 Opened 23 years ago Closed 21 years ago

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

Categories

(Core :: DOM: Editor, enhancement)

Product:
Core
Component:
DOM: Editor
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 237964
Milestone:
mozilla1.3beta

People

(Reporter: glazou, Assigned: cmanske)

References

Details

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

Attachments

(11 files, 1 obsolete file)

Example of Implemented Editor in IE
23.10 KB, text/html
Details
Discussion on netscape.public.mozilla.wishlist
20.46 KB, text/html
Details
Baseline content editable features list
272 bytes, text/plain
Details
2 extra wishlist items
34 bytes, text/plain
Details
contentEditable API
1018 bytes, text/plain
Details
contentEditable wishlist
2.21 KB, text/html
Details
contentEditable wishlist by Erik Arvidsson
1.32 KB, text/plain
Details
GED's Wishlist for Moz Editable content
1.75 KB, text/plain
Details
Requirements for in-browser, user-editable DOM nodes.
1.57 KB, text/html
Details
some security implications of scriptable copy/paste
22 years ago
2.63 KB, text/html
Details
some security implications of scriptable copy/paste
2.63 KB, text/html
Details
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 ?-) (a) http://msdn.microsoft.com/library/default.asp?url=/workshop/browser/mshtml/reference/ifaces/element3/contenteditable.asp (b) http://msdn.microsoft.com/workshop/samples/browser/webediting/onepageeditor.htm
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 something).
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++. http://msdn.microsoft.com/library/default.asp?url=/workshop/browser/editing/mshtmleditor.asp 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'). http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/commandids.asp 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 http://www.aspalliance.com/Yusuf/Article10a.asp. 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.
Status: NEW → ASSIGNED
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 mode. 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
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.) Jaro
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 document.openInComposer.src="http://file.html/"
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 code.) Please correct me if I completly wrong :-) Jaro
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: <html> <body> <p>Hello there. Type something here:</p> <div editable="true"> Type here... </div> </body> </html>
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 or...).
This is the code currently in use by our company to implement this functionality in IE.
removing myself from the cc list
jpd@TeachX.rutgers.edu : 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 different.
I'm the lead programmer on a popular OS CMS called WebGUI (plainblack.com). 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 aspects: http://www.ektron.com/ewebeditpro.cfm http://www.realobjects.de/ 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: http://richtext.cs.ramesys.com/ 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: http://www.plainblack.com/dev_board?func=postNewMessage&wid=764 and you can download the source from here: http://www.plainblack.com/extras/ieEdit.html 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 (http://bugzilla.mozilla.org/attachment.cgi?id=73094&action=view, 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 http://www.ecop.nl 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 http://lime.platvorm.com/lime/users/editor/ (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: http://www.q42.nl/xopus/ (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 wanna 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 feature)...
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 feature)... 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 - sadly... With the advent of OpenOffice.org 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 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 >important. 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 (plainblack.com), 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 ( http://bugzilla.mozilla.org/attachment.cgi?id=73094&action=view ). 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
Keywords: mozilla1.1, mozilla1.2
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 optional. 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 functionality. 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. Jaro
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 http://www.xs4all.nl/~ppk/js/index.html?/~ppk/js/cms.html 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: http://www.geocrawler.com/archives/3/140/1999/9/0/2691449/ 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=Components.classes["@mozilla.org/preferences-service;1"].getService(Components.interfaces.nsIPrefService); 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 cnn.com don't show up often when you're typing an e-mail message. That doesn't mean we should ignore bugs found while editing cnn.com (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. See http://xopus.org/index.jsp?menu=mozce 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 javascript.
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 validation. 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: http://www.devarticles.com/content.php?articleId=90&page=1 The ability to specify a textarea which would allow folks to write as they would in a Word Processor.. Mike
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 editing... JP
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 http://radio.weblogs.com/0103807/ (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 http://radio.weblogs.com/0103807/2002/09/04.html#a535 (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 users. -Rob
I EARNESTLY and completely vote for this functionality to be added to mozilla ASAP!!! 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 everywhere."
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 usage* 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? best, -Rob
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.
Charles, 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 (http://bitfluxeditor.org) 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"> <h1>Title</h1> <div class="section"> <h2>Sub title</h2> <p>Some <strong>para</strong> stuff</p> </div> </div> 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. sleepily, -Rob
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 soon. 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 fantastic.
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 CSS.
------- Additional Comments From sjoerd_visscher@hotmail.com 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 >CSS. 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: http://lists.w3.org/Archives/Public/www-html/2002Jan/0030.html 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. -Rob
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 michael@kitsite.com 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. -Rob
> 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: topembed → topembed-
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, Tony
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 user-editable. 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.2 → mozilla1.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: http://www.kaply.com/work/onepageeditor.html
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 (brade@netscape.com). 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 sufficient.
*** 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: http://www.playsophy.com/Wrap/wrapblurb.html. 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)?
bugzilla@webwidgets.net (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? >...is 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 document).
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.
bugzilla@webwidgets.net (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): http://www.kaply.com/work/onepageeditor.html http://www.kaply.com/work/wendedit.html 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 http://xopus.org 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; </script> We hope this will help developers build richer Mozilla based internet applications. 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: http://www.playsophy.com/Wrap/wrapblurb.html. 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 www.w3.org/Amaya 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 XML + XSLT => XHTML or even: XML + XSLT => XSL FO => PDF 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 build: http://mozilla.org/editor/midasdemo/ also see: http://mozilla.org/editor/ie2midas.html http://mozilla.org/editor/midas-spec.html 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 = dismisscolorpalette; document.onkeypress = dismisscolorpalette; document.getElementById("edit").contentWindow.document.onkeypress = dismisscolorpalette; } 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: http://listserv.moses.com/listserv/listinfo/midas If you are a member, you can post by emailing midas@listserv.moses.com.
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 http://www.playsophy.com/Wrap/mozce.html.
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): http://mozile.mozdev.org.
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
*** 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 case).
(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 Mozilla.
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: http://dynarch.com/mishoo/htmlarea.epl
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 (http://editor.hardcoreinternet.co.uk/) 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 http://bitfluxeditor.org/
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? /be
(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. Brendan, 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).
Status: ASSIGNED → RESOLVED
Closed: 21 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
Resolution: WONTFIX → DUPLICATE
Depends on: 1497480
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: