My initial idea was to implement behavior:htmlarea (WYSIWYG editor) as editing behavior that manipulates elements in existing DOM tree. This approach is not working for many reasons.
Main reason is following:
In presence of CSS the same rendering result (pixels in the view) can be achieved in many ways – by using various CSS attributes. (Think about spacing between paragraphs – they can be done as margins or as paddings or as trivial <br>s.)
WYSIWYG editing behavior is aimed to solve task that is somehow opposite to rendering : to change DOM structure by using current view (what user sees).
So current CSS and DOM that are good for rendering prevent good WYSIWYG implementation. I have never seen any editor based on contenteditable=”true” in browsers that I can consider as a good WYSIWYG editor. It is just impossible because of such same-DOM/multiple-ways-of-rendering-by-CSS.
Perfect WYSIWYG assumes that you can change DOM structure by using solely toolbar and keyboard – without any knowledge about underlying CSS. But current state of CSS makes perfect WYSIWYG almost impossible. Some CSS attributes and abstractions are extremely hard to present to non-css-educated user.
Solution that I am working on now:
behavior:htmlarea will be based on my blocknote editing engine.
Blocknote editing engine is using so called “flat DOM” – linear sequence of paragraphs and tables. I am just adding there limited support for CSS so htmlarea will use separate CSS file for content representation:
<htmlarea content-markup=html|wiki content-style="editing.css" />
That editing.css is a linear set of style rules that use simple tags and class selectors:
strong { font-weight: bold; }
strong.very { font-weight: bold; color:red; }
No other type of selectors will be allowed. Reason is simple: “predictable WYSIWYG”.
Think about following selector:
div.some > p { margin-top:40px; }
and user editing text with it. ENTER will cause the paragraph to be split into two:
<div.some>
<p>first</p>
<p></p>
</div>
That will create margin-top:40px; spacing between them. ENTER in other paragraphs (not in div.some) will create produce different spacing. There is no way for the user to explain why here it is 40px and there it is 10px or so.
That is why HTML WYSIWYG content editing widget, I think, shall use not-exactly-html DOM and CSS.