Thanks for the submission, Prashant. Could you perhaps add some of the XSLT filtering logic or describe what it does, especially when the editor has multiple paragraphs?

The <p> tag wrapping behavior in the Classic UI has a bit of nuance worth mentioning to make sure any potential change handles all the scenarios.

By default, in the Classic UI, rich text fields do indeed start without a wrapping element. And I have seen this lack of a wrapping element as desired and even expected, especially when the website needs rich text that might be placed inline or in a wrapping element such as a <div> or <p>. A paragraph in a div is okay, but you wouldn't want nested paragraphs.

As an editor years ago, I would explicitly use backspace (or the source tab) to remove any accidental <p> tags. 

However, the rich text format area can also store multiple "blocks" of text. And when needed, I would want wrapping <p> tags around each paragraph.

As a side note, one challenge in the Classic UI, is that without some additional XSLT filtering logic, the wrapping element would vary based on the browser, resulting in a <p>, <div>, or line break (<br/>) depending on the browser. Experience Space's rich text format area now "plasters over" the differences between browsers.

Anyways, I think it could be worth exploring if a single line/paragraph rich text field option might be interesting as an alternative solution. Perhaps this type of field could only allow line breaks, but no <p> tags. That way editors or developers wouldn't need to manage or filter/template the desired output.

I would say that an (X)HTML <p> (paragraph) tag is the best thing you can use to semantically represent that the text should not keep flowing, but start a new line/paragraph.

So, you could try to suppress the use of this tag, but you could also leverage it and ensure it renders as you would expect (e.g. in your CSS). If you *really* want to replace <p> tags with other HTML markup, you could consider doing the replacement in your templates/views.