Stefano Mazzocchi wrote: > "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 :)
How many mozilla users are looking for WYSIWYG editing? How many IE users? Even if we went with percentages, the % of IE users would blow away mozilla users. If it works the same way in both browsers then you let the user decide. I just don't see what is broken (though I do have some bugs with links and images). > > 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. [arrrggghhh: I am just rereading what I wrote. It is a wonder you could understand with my grammar errors :(] First, anything visible on a computer screen is in a rectangle :) Anyway, I get what you mean but is not true. Try: <DIV CONTENTEDITABLE="true"> <IMG SRC="boo.gif" align="left"/> blah b;lah blah blah b;lah blah blah b;lah blah blah b;lah blah blah b;lah blah blah b;lah blah blah b;lah blah blah b;lah blah </DIV> Or: <DIV CONTENTEDITABLE="true"> <IMG SRC="boo.gif" STYLE="float:left"/> blah b;lah blah blah b;lah blah blah b;lah blah blah b;lah blah blah b;lah blah blah b;lah blah blah b;lah blah blah b;lah blah </DIV> Is this what you want to do? > > 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. I don't understand. I don't see this. My pages are pretty complex and I can have text wrapping an image. They look the same with or without contentEditable. > > 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). Other platforms is the killer. Many people I know won't use anything other than a Mac. > > 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. I have never tested on Mozilla before (never had the req). I am using it now. Very cool, but the memory... There are a couple of other IE features that would be good to have (don't know if they already have it...): - control over the right-click (context sensitive menu) - modal and modeless dialogs > > 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. I believe there is a better one out there :) > > 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! Yes! They want Word in a browser. We cannot give them this much freedom, but if you break it down into small content chunks it gets easier to give them a good deal of freedom without sacrifing validity. e.g. I give the user the option to right-click on the image or double-click it to launch an image modal dialog that gives the user the chance to move the IMG above or below, or float/align left or right. This does what you want, I believe. > > And this is *NOT* currently possible in any browser in the world! > I must be missing something. > 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? I will discuss this further down and throughout the post. > > >>> 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) This is from Lon (I use IE6): ======================================== Hi Rob, we are using some ActiveX controls, yes. But only those that are standard in IE. It could be that you have installed MSXML4 in replace mode? The Xopus demo online uses the MSXMLSDK that originally shipped with IE5.5. Maybe it isn't present on your machine. > I am going to the xopus page in IE6 (not enabling activeX > controls, but > JS is enabled) and I get a 'please wait while loading' - and nothing > ever loads. Are you using ActiveX? Have you DISABLED ActiveX controls? That could be a problem. We are using the XMLDocument and XMLHTTP ActiveX controls. Those are save and do normally require a prompt. Unless of course you have played with the security settings of IE. We have NOT put a custom-made ActiveX control in it! And we never will! > I want to look at how your editor works. I am working on an > editor that > works with IE's contenteditable attribute. I have had > specific problems > with images and links. Do you knowe if there is a list or > other forum to > discuss these issues? I don't. But I do have a lot of experience using the MS edit control. Take a look at http://lime.platvorm.com/lime (click the Webmonkey image). This is our HTML editor. I hope you like it. greetings Lon ======================================== > > >>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> Yes, I agree. There are many different types of documents to edit! For example an article should be much more free-form than a use-case :) The transformation determines which javascript parser script to include; parser_article.js or parser_use-case.js > >>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) > I personally like to use a modeless window AND context sensitive menus. I hate floating DIVs - very ugly and jerky. I had played with a FRAMESET but that intrudes on the look of the page. >>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> > If you go this route, then you will be giving up some nice 'free' features. For example, the user is in a P tag -> they hit enter -> a new para is created. Or even better, they are in a numbered list -> they hit enter anywhere in the list and a new item, numbered correclty, is inserted. You could catch keys-presses, of course, and duplicate the functionality. Why are you worried about setting contentEditable at the outermost DIV that wraps the content piece? You can have a kind of freeform editing and still control what the user does. Aside - about HTML and case: I hate that XHTML and XSLT both require lowercase. This ruins a very simple but effective 'separation.' When I create XSLT I use uppercase for all HTML. This way an HTML person can jump in and know exactly what they can affect. Anything in lowercase they should not touch. Anyway... >>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/> Ramblings: In my site.xml config document (and a corresponding content.xml that further describes each individual content piece) I describe the site hierachically with folders and pages (mirroring what the site structure would be if not dynamic). At the folder and page level I set the columns for the page. Inside of the columns I put XML content pieces which determine the rows or individual CONTENTEDITABLE regions in each column. The content pieces at the folder level cascade down to the page level (unless overridden). By having the hierarchical representation you can build nav's and links on the fly (either dynamic or static depending on whether you are in dev or generating). Each content piece has an owner. When a user hits a page they can only edit those pieces that they own (rollover editable area and user sees a light outline, click on an editable area and the background color changes in that section). Once they click on the editable area, setup what you need to and let them have at it. I give the user the oppourtunity to generate the site (SAX ContentHandler going through the site.xml triggers transformations on cahced XSLT). So for a simple site you can use the same virtual host to see the Dev (and QA) version which is dynamic and using the config to guide the transformations pulling content from WEB-INF or a DB (I like text files). When ready to go to QA they generate the site to static HTML which populates the docroot writing out pages according to the config. When QA'd they can just copy the generated site to the live server. > >>---- >>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. This is really simple to achieve. When you traverse the DOM just take the things you want. > > >>---- >>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 th >o 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. > I am not sure I understand what you mean by the rectangle problem. But I would rather cutoff my left nut then try to develop something complex in Flash. But ActionScript is coming along. There are some cool things you can do... What I was jokingly implying was that you could still use JavaScript to do the editing work. the one pixel Flash movie would act as a server in the browser. On click in the HTML you send a message to the one pixel flash movie and tell it to get certain XML files or POST edited ones to the server. this would never fly because you would only get one page hit per site :) best, -Rob --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
