The trickiest problem of all for a DOM-based Wysiwyg editor... I already wrote multiple times about it, but once more is not worthless. Here are some of the requests I currently have on my BlueGriffon radar:

  1. don't mess with my indents and CRs
  2. please don't wrap long lines for asian languages since that introduces an unwated whitespace in the rendering
  3. I want a checkbox in the source view allowing me to toggle on/off the line wrapping
  4. don't touch my original source code but if I insert new paragraphs, I want a paragraph per line, not an endless line with all my new content

Eh. Only that... Let me give one answer per item above:

  1. in just a few words, that's impossible in the general case. The simplest case a DOM-based editor will never handle is the following one
    <img src=foo.png"
    alt="my image" />

    where the user wants to preserve the indentation of the alt attribute in the source code... In the DOM, the carriage return and the indentation just cannot be preserved. There is no way the HTML serializer can output the same source code from the DOM. Yeah, well, it could nicely indent the second attribute. But then it will do it for all attributes. And some other users will complain about it, in particular if the two attributes fit into one single (not too long) line.

  2. that one is doable modulo the fact people wanting this also always want request number 4 to avoid endless lines. So see item 4 below please.
  3. that request implies a deep misunderstanding of what is the source view of a DOM-based editor... The source code is serialized from the DOM tree before showing the source view. If the source view shows line wrapping for instance at 72 chars, it's impossible to go back to the unwrapped view without reparsing the source and reserializing the DOM tree w/o the wrap option ; same thing if you have an unwrapped view, the list of operations needed to switch between unwrapped and wrapped is not trivial at all. In all cases, the result will very likely be not exactly in line with what the user expected.
  4. sigh. So if you original source contains in one single line <p>a</p><p>b</p> you want to preserve that as it is, but if you create the same two paragraphs in the Wysiwyg view, you want the created paragraphs to generate one line each in the source view. There's only one way that could be done: give a special attribute or user data to the nodes created in the wysiwyg view. Why? Because there is no other way the serializer can make a difference between a node that was in the document at parse time and another node you created by hand... Then during serializing in Raw mode, output a CR before blocks' start tags for blocks that do carry that special attribute/user value. Of course, those special data should not be visible in the source view. So when you go back to wysiwyg view, they're lost. Hum, to say the least.

I said it multiple times in the past, a DOM-based Wysiwyg can try its best to keep your source code readable, indented, nice. But it cannot, it just cannot preserve an original source code whatever that source code. Serialization will always drop some whitespaces/CRs from the original source. It will always have to make compromises between the various - and opposite - wishes of the user. Wysiwyg is still hard.