[whatwg] Authoring Re: several messages about HTML5

[Adrian Sutton]

> | > 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.