Wiki editor now riddles html with unwanted div clutter
This is a behavior that seems to have changed in the past week. In Zoho Wiki, in the past, the WYSIWYG editor produced quite vanilla HTML. Now it's wrapping many tags in superfluous divs.
This is with Firefox, which, like most browsers, relentlessly updates, so could be an interaction with a Firefox update. At any rate, this is on Windows 7, latest update, with Firefox 60.0.1 64-bit.
Repro: Create a new page, and the content starts off as:
<br>
Now (in WYSIWG mode) type something in at the initial cursor position, like 'Hello', now the html shows:
Hello<br>
Now hit return after Hello. The HTML becomes:
<div>Hello</div>
<div><br></div>
As the doc gets more complicated, divs seem to get added around some elements, and newly inserted text may or may not get wrapped in its own divs.
Meanwhile, something which IS needed, a <p> tag to wrap "Normal" text, does not always seem to happen automatically, but instead must be applied manually using the Normal style.
For example, after typing in a list, then using an additional Enter to finish the list and start on a normal paragraph, the WYSIWYG editor fails to wrap the new text in a p tag, and instead applies a div. So you now have to manually apply "Normal" style. Which retains the useless div, and applies a p tag inside it.
After numerous edits, this kind behavior proliferates divs all over the place.
And for what it's worth, the Style control
still fails to track the actual style at the cursor position, as I have reported numerous times over at least two years.
Why does this all matter? Because it's frequently necessary to edit the HTML source directly in order to compensate for something that the WYSIWYG doesn't do properly. And trying to do so with the html cluttered with divs (which have to be matched when copying/pasting) and excessive uninformative indentation is a headache.
Don't get me wrong. In other respects the WYSIWYG is pretty good, compared to competing environments. However this proliferation of completely unneeded divs makes it substantially less favorable.
I also note that the WYSIWYG behavior varies in Chrome and IE, and has been sufficiently worse there to make Firefox the environment of choice for editing purposes. Unfortunately, this new div proliferation makes editing painful in Firefox.
For reference, in previous posts regarding the WYSIWYG editor I have shared some simple CSS for the editor so that WYSIWYG html structure problems become immediately visible. This is a great aid to keeping the html clean, and for troubleshooting. Please see:
I hope you can identify what's changed, and get us back to the previous tolerable, if not ideal, behavior.
Thanks -- Graham