DOM space is the set of all web pages that you can express in HTML. All pages can be represented as a tree of elements, with text nodes as the leaves of those trees.

Visible space (“what-you-see-is-what-you-get”) is the set of all visible pages — what you actually see on the screen when a browser renders a page. We say that two pages are the same in Visible space if they look exactly the same.

The browser’s rendering engine is a mapping from DOM space onto Visible space. By “onto,” we mean that all Visible pages are the output of Render(x) for some DOM tree x.

When we say a mapping is well-behaved in an editor, we mean that the mapping preserves all edit operations (see footnote 1). More precisely, if Render is well-defined, then

for all edit operations E, and DOM pages x and y

Render(x) = Render(y)

implies Render(E(x)) = Render(E(y))

This is a way of formalizing the “what you get” part after “what you see.” If two pages look the same, and we make the same edit on them, then the two results should look the same. (again, see 1)

I’ve been surprised how many “WYSIWYG” editors on the web break this rule. It may sound like an obvious principle. But it leads you into weird existential questions about what “same” means, which are best explored with examples.

Well-Behaved Content

Consider a sample sentence:

Baggins. The hobbit was a very well-to-do hobbit, and his name was

The Medium editor renders this sentence as, roughly, below.

The <a href=”http://en.wikipedia.org/wiki/The_Hobbit">hobbit</a> was a very well-to-do hobbit, and his name was <strong><em>Baggins</em></strong>.

There are many, many ways to encode that last word, Baggins, as both italicized and bold. (see footnote 2)

<strong><em>Baggins</em></strong>

<em><strong>Baggins</strong></em>

<em><strong>Bagg</strong><strong>ins</strong></em>

<em><strong>Bagg</strong></em><strong><em>ins</em></strong>

These forms should be equivalent, editor-wise. Any edits you make to this post need to treat all these forms the same. It is surprisingly tricky to write an edit action that knows about all the different DOM forms.

For many ContentEditable implementations on the web, some invisible character or empty span tag may slip into the HTML, so that two ContentEditable elements behave totally differently (even though they look the same). The experience can be maddening to users, and hard for engineers to debug.

Even if we knew how to write an edit action that is well-behaved, how would we check it? If we limit our HTML to simple tags, proving that two forms are visually equivalent is…complicated. Your best bet is to iterate through each letter, assign it a style, and compare the results.

In an ideal world, we would have some high-level API for making “visual edits” to the DOM. Each operation would guarantee that it is well-behaved, and does the “same” thing for all visually equivalent pages. Then, as long as your editor only used these APIs, you could guarantee that it is well-behaved.