Hi, Stefano Mazzochi wrote: > 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.
Yes, much more potential than a mozilla based app. We are not even talking about Netscape, just mozilla... I hope Stefano can help to get contentEditable to work in mozilla, but it *has* to work the same as IE. <snip/> > > 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) This does not work for anything other than simple editing. > > 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 > > http://bugzilla.mozilla.org/show_bug.cgi?id=97284 > > [please, go there and vote for that bug so that it ends up in the tree > faster!] I voted! > > 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. ughhh, way to slow - too many trips to the server. I thought Xopus uses an ActiveX to control the editing. I could not even see their pages because I don't not browse the internet with them on anymore (especially sites made by guys like you :) > > 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!) Yes, totally agree > > 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... > </div> This won't work unless you have extremely simple DIVs. What happens when you want to edit bold text or a link in the DIV? By setting contentEditable to true at the DIV level everything that is not explicitly set to contentEditable=false will be editable. And wouldn't you want this? E.g. <DIV CONTENTEDITABLE="true"> <SPAN CLASS="title"> My Title </SPAN> <P> The para text with <STRONG>bold</STRONG> and <A HREF="#">links</A>. <P> </DIV> Or are you saying you make editable 'islands' on the page set of by each styling of a XML content piece into an editable DIV? ---- A serendipitous feature I have noticed is the ability to cut and paste from a text, html, Word (etc) doc. The IE browser parses it (sometimes for a long time...) and throughs it on the page as best it can. You just need to know what it throughs down and parse/freshTrip it back to your XML strucutre and send it to the server. ---- One other thing: MACR is about to release the next version of Flash with much better XML parsing speed (better than v.5). You *could* create a one pixel flash movie and use that to control logic, flow, aggregation on the client-side. [just joking :)]. <snip/> best, -Rob --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
