Improving the small viewport post editor.

[#1]

Is there any possibility of changing the HTML generated by the small viewport post editor please?

For paragraph breaks can 

...<br><br>...

Be replaced by

...</p><p>...

If [at]tag can be converted from text to HTML on save, why can it nor be preserved on editing?  Strip the <a>@text</a> to @text which will then be reprocessed on save.

Can the processing of &chars; be fixed please, so that editing...

Word[double space]word

Where double space is a nb-space followed by a space, does not get rendered as below after editing on a small viewport

Word  word

[#2]

We are not able to intercept written content in the plaintext editor and process it before it gets sent to the server. All the text processing is done server side by Lithium.

Processing of text afterwards, at a post view stage was met with heavy criticism by the users - remember I had removed empty <p>&nbsp;</p> tags when a user had hit return many times - as there was an issue of 'if I want multiple spaces between content then that is my right to do so' which is fine so we compromised and had the script remove the empty paragraphs after the last bit of actual text. Which leads me to the next thing...

There is also an issue with the way that some users like to compose messages or display certain types of content. We have staff posting graphs, stats and other types of content, there are also blog posts that may need certain formatting done to make the text be viewed in a certain way (elements such as the double <br> come in handy in such situations).

I'd rather not mess with text as it was criticised before for tinkering with their written word.

I'd like to add that coming from an agency background - I had some really big clients who had access to a text editor in the CMS and they would often makes a dogs dinner of it all so I am no stranger to making changes to text in the name of conformity and consistency... but its a bit different here and I don't like to mess with a users text if I can help it.

Sorry that I can't do this, I hope that my post above explains a little bit about the reasons why I can't.

[#3]

But Jack, I am asking for consistency.

If I type "text[return][return]text"

On a full size screen editor, the generated html is

...text</p><p>&nbsp;</p><p>text...

On a phone screen, the generated html is

...text<br><br>text...

What I am requesting is that wherever the text is manipulated that it be done consistently.

If on a small view port device I type "text[space][space]text", the generated html is

...text[space][space]text...

On a full screen editor it is

...text  text...

If I then edit a post originally made with the full screen editor on a small screen editor, the above is exactly what is displayed as editable text.  On saving the generated html becomes … I went off to check my facts … and I see that you have already found my play-pen topic on this somewhere else.

It might well not be in your space to fix, but Lithium should seek to ensure that there is better compatibility when processing posts from the two different editors.