Hi Nelson, Is your goal to allow collaborative editing of the full HTML spectrum in a wysiwyg fasgion?
HTML is a mismatched hybrid of content and presentation, and does neither of the two particularly well except for the particularly narrow purpose for which it was designed (single-column paragraphs of text with mild markup). I'd recommend focusing on what you want to use HTML for (e.g., documents, or diagrams, or spreadsheets, etc), and design your product around that. When it comes to collaborative editing, it is vital for the syntax of what's being edited to have a form where mutations of that syntax have close correlation with user intent, in order to have conflict resolution rules (i.e., OT) that make sense. e.g., imagine using raw HTML tables for a spreadsheet-like experience, and one user moves a row while the other deletes a column. If you look at the individual HTML-table mutations to express those actions (deletion of a tr with lots of tds, insertion of a tr with lots of tds, plus deletion of a sparse range of tds), it is difficult to write HTML-element-mutation-based OT resolution that would result a favorable outcome. Even for document editing, the trivial action of hitting enter in the middle of a paragraph (in order to split it) can only be expressed in HTML syntax as the deletion of an entire paragraph plus the insertion of two more paragraphs. If someone else was concurrently typing in that original paragraph, it is unlikely that OT rules could produce a desirable outcome. There are many other trivial examples (e.g., selecting some text and styling it while someone else is typing in it, or two users selecting intersecting regions and applying independent styles, etc) that demonstrate why raw HTML's syntax can be problematic for concurrent OT-based editing. For any kind of collaborative editor, I'd discourage using HTML as a content language, and think of it only as a rendering language. If you're not fussed on the content language, and you just want an editor that renders as HTML (but without the full wave client around it), then I'd recommend taking a look at the editor test harness (run it with 'ant editor-hosted') as a starting point. Alternatively, if your goal is to allow multiple HTML programmers to edit pages collaboratively, still giving them the full spectrum of HTML, then I'd consider using any collaborative text editor (of which Wave is one) to edit the HTML source directly as text, rather than using a DOM-based HTML editor. HTH, -Dave On Tue, Mar 1, 2011 at 10:06 AM, Nelson Silva <[email protected]>wrote: > Hi all, > > I'd like to know what is the best approach to create an editor to > manipulate a pure HTML DOM element. > > If I wanted to be able to support collaborative edition of pure HTML how > should I approach it? > > I could use an HTML doodad but I'd have to add support for the full HTML > schema and would have a one to one mapping between my document model and the > view... > > The idea is to use Wave and OT but not the client interface to create a > collaborative HTML editor. Should I just skip gadgets and doodads and create > a simple editor or would it be best to use doodas even with a direct mapping > between the document and the view ? > > Thanks >
