incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nelson Silva <nelson.si...@gmail.com>
Subject Re: Pure HTML Doodad
Date Tue, 01 Mar 2011 09:40:13 GMT
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 <nelson.silva@gmail.com 
> <mailto:nelson.silva@gmail.com>> 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
>
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message