[DiapDealer]

The problem with "hiding" html tags in something like Code View is that it still doesn't address one of the biggest hurdles faced in synchronizing the current Book View with Code View: accurately/consistently "guessing" the real cursrsor postition in a rendering of the actual (and often times very convoluted) html markup. Hiding markup would only likely exascerbate the problem. When faced with a nightmare of nested spans, divs and blockquotes, where IS the cursor, really, when you place it next to the letter 'V' in a wysiwg view? Next to the innermost preceding inline element? The outermost block-level element? Somewhere in between them? This has to be known (or "best-wild-assed-guessed-at") to be able to convert your wysiwyg changes into html that's then merged (with any luck--gracefully) back into the pre-existing markup. This issue is also what makes splitting/merging in Book View ill-advised.

Sometimes I think people don't understand that there is no seperate, text-only version of your document that exists within Sigil to be edited. There is only the markup (CV), and then the Webkit rendered markup (BV) that gets crammed into a text editor--the changing of which requires figuring out the best (often meaning least destructive) method of incorporating those "blind" edits back into the real document.

A wysiwyg editor in which the ability to edit (or even influence) the underlying markup is entirely forfeited .... piece of cake.

A code view editor which provides the ability to produce markup exactly the way you want it (while being able to preview your work--but not change anything in it) .... another piece of cake.

The ability to do either without depriving both wysiwyg users AND codemonkeys of features that would otherwise be relatively simple to impliment, can actually be quite the nightmare. Most of it down to cursor position and Webkit quirks/bugs that don't allow certain things to survive the transition.