Stefano Mazzocchi wrote: > Dear Mozilla-Editor group, > > first of all, thanks for the outstanding job you guys are doing on such > a difficult project. I'm positive that in the future, Mozilla will do > for the client-side web what Apache did on the server-side, keeping open > standards "open" and keeping other players "sane".
:-) > I'm writing you because I'm the author of an XML publishing framework > called Cocoon (see http://xml.apache.org/cocoon2/ for more info) and we > are getting close to hit the big wall of digital publishing: how content > is edited. Yes, I've been following the progress of Cocoon from time to time; excellent project. Some very big corporations are following in a much closer way (just wanted to let you know that people like what you are doing ;-) > After looking around for a tons of editing solutions, both open and > closed, I came to the conclusion that inline-editing is the key, after > having used an editor called "Xopus" (look in Google for more info) > which uses special IE 5.5+ inline-editing functionalities of the MSHTML > component, along with in-place XML/XSLT transformations. > > The concept is *way* cool, even if Xopus had to jump thru hoops to do it > in IE and for sure there are many things that could be improved, but the > idea is simple: > > current Composer is done for people that want to write their own HTML > pages, but nowadays, there is absolutely no need for that in a closed > environment (think of intranet, extranet): editors (here I mean the > people that edit) should be given a structured-WYSIWYG tool that allows > them to edit content, but *ONLY* the content they are responsible for > (thus avoiding changing the other parts like sidebars, banners, etc...) > > IE 5.5 has a special attribute contentEditable="" which, if set to true > (even thru scripting) turns the element editable. [see attached a demo > page cloned from a CNN.com page, of course, it works only on IE 5.5+] > > While their current implmentation has major WYSIWYG limitations (text > doesn't go around images, for example), the concept is, IMO, a great > one. It's not a wysiwyg limitation, it's a feature limitation. We don't have yet a CSS model allowing to achieve such effects with correctness AND efficiency. > The ideal tool for structured-content editing, in my personal vision, > should be something that "forces" the editors to write the content only > in the position allowed, but with the full visual simplicity of WYSIWYG > (not with forms and stuff like that). > > Even more, the editor should not even open/save the content using normal > files, but sending back the content to the server. This allows for This "should" is of course from your perspective. If you allow some content on a page to become editable because you want to annotate the document, saving locally is also very important. Please take a look at the work being done by Kathy Brade about publishing. > *true* distributed editing environments and for *true* content workflow > management. > > Ok, this said, I have a couple of questions: > > 1) is there anything like the IE feature of contentEditable="" for > Mozilla? Not for the moment. I filed a RFE (marked "Future" for the moment) about it (see [1]). This is exactly about what you are looking for. > 2) if not, did you guys already plan to implement it? I certainly did not file the RFE to leave it forever in a black hole. I do think we have most of the core technology to implement this RFE. But please understand it is a question of priorities and timeframe (like always *sigh* :-) ) > 3) if not, would you be willing to do it after my suggestion? See above. > 4) if not, how hard do you think that would be for external people to do > it? That's not so easy and the answer clearly depends on the level of "editability" you want. The low profile feature is about modifying the text nodes. The high profile feature is about being able to do whatever is allowed by the DTD in the the editable element... > 5) do you see/plan/imagine equivalent solutions that are possible with > today's code or with planned future additions? Not for the moment, unfortunately. > 5) moreover, it is possible to us the Composer to edit generic XML > content? I mean, associating with some event the creation of a specific > element and use CSS to present it? Composer is not XML-aware for the moment and I am finishing my work about the integration of CSS into it. > 6) finally, what is the current status of embeddability of the editor? Ah, that's outside of my scope and I defer to Simon for instance ? > Sorry for the long email, but I see great potential in Mozilla and if > something like this structured-WYSIWYG on XML editing could be possible, > Mozilla will instantly turn into the "browser of choice" for intranet > and extranet that are based on XML content published and transformed on > the server side. (which is the trend that most companies are initiating > right now) No problem Stefano... Very nice to read your input and that's clearly the kind of projects we could address. Are you based in Italy ? If that's the case, I just wanted to let you know I am not far away (Paris, France). [1] http://bugzilla.mozilla.org/show_bug.cgi?id=97284 </Daniel>
