Thank you Randall for bringing this up.

Thing is that the code that handles html formatting was written several years ago and involve 4 components: Our server code handling database exchange, Tidy service, CodeMirror service and Browser component itself. While we control our code and semi-control Tidy and CodeMirror, we have no control over browser component.

So frankly we do not know why it does not work the first time. And as the contour worked as a whole we did not payed attention to it. Especially with browser changes it was hard to follow them.

But you brought this up and today we discussed it within our team we think that time have changed since the last time we did it. And maybe we can easily fix this.

Now we can not promise you that we will fix this soon or that we will have the exact fix date for you. But what we can promise you is that we will look at it during our work with next new features and maybe we will find a quick way to fix it. We will update this topic as soon as we do this.

Once again, thank you for bringing this up. Without it we would of continue to neglect it.

I suppose in my workaround suggestion the "not all process" I mentioned were those that are gadget-based.

Further note: the workaround needs doing only once per editing session. Do it once, and you can open HTML code repeatedly anywhere in your content, and it will display correctly. However, when you save your session and re-open it, you will have to run the workaround again.

IMO, there is no excuse for not having fixed this long-standing bug by now, but FWIW, here's the work-around:

Click the HTML editing icon. In some WA processes (oddly, not all, IIRC), the code will be without linebreaks -- a big block of run-on code, impractical to read.

Add a space somewhere where it will not affect the HTML output. E.g., as the first character of the code, or in any HTML tag where an extra space will be ignored.

Save the "revised" HTML.

Re-open the HTML. Whatever linebreaks were in it will now be visible.

Since the code IS shown properly on the second opening, how this indicates a problem with "modern browsers" is a mystery to me.

I would propose, as a kludge, that WA make the edit itself, except I suppose WA would not be able to save the edited code transparently? If WA can transparently run this workaround, what are we waiting for?

Thank you for bringing this up.

Problem is that one of the external components in our system that we use to validate and repair html code works inconsistently with modern browsers. We will run an investigation on this behavior and put it in our road-map. Ether we will find the source of the problem or we will think on replacing this component altogether.

For now, one can always use custom html gadget. It does not provide WYSIWYG functionality and does not colorize the code but custom html gadget always saves your formatting style.

Regards,

WA CMS crew