> | > I agree that HTML DOM is not suitable for WYSIWYG editing. > | > | I beg to differ. It is true that an editing style sheet may be > | needed to avoid problems with delivery style sheets that use the > | display and visibility properties to hide content, or which use CSS > | positioning to layer things in complex ways. But apart from that, > | The HTML DOM is just fine as it is. > > So this means relaxation of requirements - strictly speaking > it will not be WYSIWYG anymore. If "editing style sheet may be > needed" then what you will see is not what you will get.
There are a couple of problems here. Firstly as far as I know there is not and has never been an editor that does What You See Is *Precisely* What You Get, they all have various ways to help the user understand the structure of the document or visualize physical elements such as page boundaries which don't exist on screen. Furthermore, users don't want to see precisely what they'll get, what they want and what WYSIWYG is really about, is that they can see and work with the document in visual form instead of having to learn a mark-up language and for the rendering to be close enough that they don't need to use preview (or don't have to use it more than as a final check). HTML editors in particular don't provide a precise rendering of the document because no two browsers render a document precisely the same and even the same browser on different machines will render it differently depending on user settings, screen resolution etc. Secondly, HTML DOM is not suitable for WYSIWYG editing because it is an inefficient and difficult representation to use for editing operations. It is perfectly possible to use it to write an editor - it's just not the best representation. For instance, if you have content like: <p><em>This is <strong>my content</strong></em></p> If the user then selects "is my" and applies an inline style (<span class='stuff'>), with a DOM representation you have a couple of tree operations to perform, plus you probably should do some normalization to ensure that the generated tree structure is consistent regardless of how the content got to this point. However, if you represent the text as an attributed string, you simply add "span class='stuff'" to the attribute set for "is my" and it's done. When you serialize the model you have to construct a valid DOM out of it, but it's fairly trivial to make the DOM come out in a consistent form and speed is a lot less of an issue at that point. The attributed string model also has the benefit of better matching the way the user thinks about the document - they rarely think of a tree structure, they think of text with formatting. A good example of the problems caused by the backend model not matching the user's model is http://www.codinghorror.com/blog/archives/000583.html also see my response http://www.symphonious.net/2006/06/12/the-invisible-formatting-tag-probl em/ - there's a whole series of back and forth responses if you have nothing better to do, I seem to write about this far too much. > | Manipulating the DOM is a straightforward matter of tree walking > | algorithms. The really difficulty is understanding what the users > | would like to do. For example, you might type some text and click on > | the list bullet button. The enter key then starts a new paragraph > | within that list item, whilst enter followed immediately by another > | enter starts a new list item. Pressing enter on an empty list item > | closes the list. When it comes to the markup produced, you can > | conceptualize this in terms of a collection of critics that look for > | and fix particular problems, e.g. merging adjacent ul elements, or > | for moving leading and trailing whitespace out of inline elements. True, the challenge is always to 1) find out what the user meant and 2) do it. The model you choose can make that task easier or more difficult - in fact it generally does both because no single model is ideal for every editing operation. In our editor, we have a specific list model which is different to both the attributed string model and the DOM model - it simply has a list of LIs that are indented at different levels and have attributes like list type (OL/UL), style attributes etc. There are then a relatively small number of atomic changes users can make to lists (change indent level, change list type or attributes or merge items) and the model knows how to perform them on itself. The model also knows how to serialize itself in terms of a valid HTML document structure. The challenge is then simply mapping user actions to list operations in a way that is intuitive and consistent for users. By picking an appropriate model you can save a lot of effort in terms of keeping the model sane and correct. Lists and tables are excellent examples of where the HTML DOM is not ideal for editing because there are too many extra elements around that the user doesn't want to think about. Reconciling this difference in HTML DOM to user expectations is one of the reasons why lists and tables are so hard to get right. > HTML and its DOM has logical/semantic elements that > have no visual representation at all. Think about DIVs that > are used for wrapping portions of textual data and has no > visual representation. Your style sheet may rely > on some containment in some DIV - so the same > sequence of editing actions made by the user produces > dramatically different (for the user) visual results. This is why it's so useful to have a visual representation - the user can *see* that with the DIV there it renders one way and without it, it renders a different way. Of course, getting the user to understand the inherent tree structure that DIVs work with is difficult, so is the rules for how CSS applies. I don't have a good solution for this, but we're continuing to try to find one. > Let's take a look on example you've provided: > "The enter key then starts a new paragraph within that list item" > So after enter you will have: > Case #1: > <ul> > <li>First paragraph. > <p>Second paragraph.</p> > </li> > </ul> > > *or* Case #2: > > <ul> > <li> > <p>First paragraph.</p> > <p>Second paragraph.</p> > </li> > </ul> > > So even in this "simple" case you have two options how to make > mapping of "action -> dom structure". > > And now imagine that you will get following markup: > Case #3: > <ul> > <li>First paragraph.</li> > <p>Second paragraph.</p> > </ul> All three of these are completely wrong. When the user presses enter in a list item, the editor should insert another <li>. There is simply no excuse for doing anything else. A startling number of editors get this completely wrong though. Another very popular error is indenting a list item and generating: <ul> <ul> <li>Item</li> </ul> </ul> > Visually and by default this is indistinguishable from the Case #1. > So looking on these two list items user has no clue of > what he/she just did by pressing "Enter". Enter press is the most > unpredictable action in all WYSIWYG editors in the wild. > For the simple reason: there is no single unambiguous way > of changing DOM for such an action. Again tree-alike > DOM is simply not suitable for that. The DOM isn't ideal for this, but it's still quite possible to get it right, it just takes a lot more effort. It also helps if you run the HTML you start with through something like Tidy so that it starts out sane and you don't have to deal with the infinite range of completely broken HTML as a starting point. I suspect, but don't know for sure, that many JavaScript editors struggle with this, but our Java based editor has thankfully managed to avoid this particular set of problems. > | p.s. one missing feature in CSS that would really help would be a > | means to add a forced line break symbol to the rendering of <br> > | elements. It is already easy to add a paragraph symbol, but CSS > | balks at <br> elements for inappropriate reasons. We just changed the renderer to put it there without CSS, but I guess that's cheating. Regards, Adrian Sutton PS: My apologies, I've lost track of who actually said what above.
