cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Wyona / Xopus (IE vs.Mozilla)
Date Fri, 08 Mar 2002 13:12:46 GMT
Matthew Langham wrote:
> > "Mozilla can now be used as a content editor" but could be "we
> > have a content editor, and the code is based on Mozilla, by the way".
> >. . .
> This I like. An XML Content Editor as a separate application based on
> Mozilla code.
> I was pointing out that Cocoon is being widely used in environments where MS
> IE is the browser running on the client - so a solution that would only run
> _inside_ a Mozilla browser would lock out a lot of potential.
> Sounds like a new project to me.

This is my thinking:

 1) I want an userfriendly semantic-based editing solution that *must*
run on any platform. 

 2) I believe that browser-based inline editors provide the best

 3) I believe that element-granular editing behavior provides the best
solution (unlike fully WYSIWYG editors like Frontpage, Mozilla's
Composer or IE hotmail-like <iframe>s) 

 4) Currently only IE 5.5+ implements this using the
contentEditable='true' attribute on every element. Mozilla has scheduled
such a feature for version 1.1 to be released in July. See

[please, go there and vote for that bug so that it ends up in the tree

 5) Xopus uses contentEditable="true" as a in-place editing widget and
adds a layer of driving logic based on client side XML/XSLT/XMLSchema to
implement MVC. This is a possible solution but, for sure, not the only
one. The same processing (creating a editing controlling javascript for
the page) can be done on the server side. No, Ugo, we don't need to do
it on the client side.

I fully believe that once mozilla implements contentEditable that can be
controlled via javascript, the rest is just a matter of writing the
DHTML (or, even better, XUL/XBL-based pages) that drives the process.

I've done it for IE and it's not that hard.

Also, I believe that there is no need for XSLT on the client side (CSS
styling is enough for most inline editing needs, since the hard-core
transformations normally don't happen at the content level but at the
page structure level, which is normally *never* edited this way!)

So, the best solution I see is:

 1) both IE 5.5+ and mozilla 1.1 implement something like

  <div contentEditable="true">
   edit text here...

 2) we have editing views in Cocoon that wrap pages using
javascript/XUL/XBL things generated out of XMLSchemas that control that
page. Depending on user-agent, we can *tune* the javascript on specific
functionalities, just like we do for HTML style.

[in case we have older browsers and no contentEditable feature is
present, we have to resort back to form fields, with this architecture
it's just as easy]

 3) the generated controlling code is also responsible for driving the
user experience and also to XML-format the results back on the form post

 4) the server receives back a XML payload which can be fed into cocoon
pipelines for further elaboration/storage/whatever.

As you can see, all we need to make this possible is:


and I'm currently working to make this possible in first person and any
help will be very appreciated.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

To unsubscribe, e-mail:
For additional commands, email:

View raw message