Hi,
First of all thanks for your support. You're completely right I should
have refered to XHTML and not HTML.
I have actually been playing with the editor harness and started working
on a doodad but I just wanted to get a best practices advice before
mooving further.
We want to support DOM editing and we're using XHTML as a sample trial.
The goal is to extend the approach to other schemas like SVG, X3D, etc
so we need a renderer and can't just use the source code directly.
I understand that expressing these operations as DOM operations comes at
a cost but the rendering comes free. So, what you're saying is that we
should optimize the document model for OT and worry less about the
rendering, right ?
On 28-02-2011 23:47, David Hearnden wrote:
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]
<mailto:[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
