"Robert S. Koberg" wrote: > > 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.
Well, no, I *strongly* hope it doesn't :) If you refer to the syntax, I think it would be pretty stupid to choose another attribute 'just because' and anyway, patching the tree to make it react on 'also' the IE 'contentEditable' attribute it would probably be a few lines of code. (finding the place will be the hard job :) About behavior: IE's contentEditable widget is rectangular. *ALWAYS*. All versions of IE. I hate this! You can take your favorite news page with complex layout, turn editing on with a javascript-powered DOM crawler and, voila', the layout of the page changes if the text blocks are non-rectangular. This sucks! My *biggest* reason to work on Mozilla is to *fix* contenteditable, not to recreate it on other platforms (that's the second biggest reason). If you try Mozilla Composer, it is fully capable of performaing non-rectangular editing of text... for example, text flows around images, so my wild guess would be that by merging the editing capabilities of the editor XPCOM component and the rendering capability of the Necko XPCOM component, we can have the behavior we want. Even the best inline editor existing (q42's LIME, see www.q42.nl/products/lime) is based on contentEditable and thus inherits this 'rectangular only' behavior that messes up layout. Sure, many of you might not give a damn about a small layout change, but almost *all* the writers I've showed a demo to, they say they would be *much* more interested to see a *fully* WYSIWIG semi-structural editing solution... the goal is to *remove* their need to 'preview' the page. Completely! And this is *NOT* currently possible in any browser in the world! I want this to change. > <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. What do you mean? > > > > 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. No, it's not slow at all. They ask for the xml, the xslt and the schema. Note that the XSLT and the schema rarely change so are client-side cacheable. > I thought Xopus uses an ActiveX to control the editing. No, it's everything javascript based (with calls to MSXML) > 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 :) Exactly, ActiveX is potentially too dangerous but no, they don't use this technology and nobody is planning to use it. > > > > 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. This was only an example. And, BTW, I think you could do *very* powerful semi-structured editing with just <div> and <span> > What happens when > you want to edit bold text or a link in the DIV? Via javascript. You can either have: 1) keyboard shortcuts (CTRL-B for bold, contentEditable does this automatically and also places 'semantic' tags in there! <strong> instead of <b>, <em> instead of <i>) 2) floating toolbar with buttons (you could do it with an absolute-positioned <div> with draggable controls, or with a frameset (LIME does this), or with reactions on other parts of the same page) 3) context menu (right-click and follow the menu, Xopus does this right now) > By setting > contentEditable to true at the DIV level everything that is not > explicitly set to contentEditable=false will be editable. Yes, this is a feature, not a bug. It's up to the server to generate a page with contentEditable set to true *only* in those parts which should be editable by the current page-requesting user. Ranging from *none* (reading user) to any level, due to workflow constraints. > 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> I would use <div> <span class="title" contentEditable="true">My Title</span> <p contentEditable="true"> 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? That could be possible as well even if currently CSS isn't supported enough to style an XML document to every required layout, so I'm thinking more of something like this: 1) there is an XML document on the server (stored in an XML database probably) 2) depending on the user identity, a different stylesheet is applied to indicate the areas that are 'editable' by that user (sets namespaced attributes) 3) the editing-enabled stylesheet turns those attributes into the contentEditable flags to true in the locations indicated 4) the page contains javascript that is capable of creating a semantic XML tree back from the editing process when onSubmit() is called on the page 5) the server receives the XML document, validates it and, if valid, stores it into the database [the validating javascript might be generated by XSLT-transforming the XML schema of the document!] I'm working for a demo to insert into the Cocoon samples, maybe working on top of Jeremy's <slash-edit/> > ---- > 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. It's entirely possible to have javascript that 'repairs' this pasted dirty HTML by crawling the DOM and removing/adapting things (like <b>-><strong>, the remouval of Office PIs, remouval of <font> tags and the like) LIME does this. > ---- > 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 :)]. Well, since this flash-based logic would need to be automatically generated from the server, I'd much prefer a javascript solutions where, at least, the transmitted content is not binary! Moreover, this doesn't fix the rectangular content-editable problem either. -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. <[EMAIL PROTECTED]> Friedrich Nietzsche -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
