There is also a 3rd category:
It's not about the looks and it also isn't about the naked markup. It's all about structure.
Personally, I think this is pretty much ideal. This is how you should create the content. But of course it's nice to have some "raw" editor thingy like Code Mirror as alternative available.
There is a hypothetical middle ground. It's called WYSIWYM (What you Mean). It's similar in functionality to a WYG, but with a fraction of the functionality (custom styling) in favor of more robust output. The premise is that the user can specify what an item being edited is, not how it looks. You can have all the headings, ul-s, ol-s, paragraphs and other semantic tags. You can use strong or emphasis. You can even apply meta information (for html it's usually classes) to the tags. What you cannot do is change appearance-related attributes, like color, font style and size, alignment and the like.
While the premise is beautiful, the implementations are lacking. WYMeditor is the best of them, but it's development seems to have ground to a halt, and it still has a lot of issues. It basically uses the standard iframe method, and then thoroughly cleans up the markup before saving, but there are a lot of cross-browser quirks still. When I developed my first custom CMS, I used it instead of a WYSIWYG editor, and although the end results in the public-facing pages are well-controlled, It's a bit frustrating for my clients to use.
Even those WYSIWYG text editors don't work very well. The problem with those is that the look of the content is actually secondary. What matters is its structure. (See: WYMeditor
On a higher level it can also somewhat work, if you use pre-built components/bricks/legos, which can be somewhat customized.
So, you could for example say that the min height of the layout shall be fluid or 100%... and the footer should be sticky or not. Then you could add some left/right columns (multiple are possible). Then you could add some grids and fill them with content or widgets and so forth. (A CMS could provide this kind of functionality.)
That would be pretty damn close to WYSIWYG. However, it would be kinda limited. It would only work if you do the same type of website (with the same or similar functionality) over and over again. Otherwise you'd need new bricks all the time.
WYSIWYG all the way doesn't work, because there are just too many properties you might want to change for some element. Using some UI for that is simply too slow and unproductive. Additionally, it would be pretty difficult to create some sort of architecture this way. It's too indirect for that.