One of the common reasons people want to avoid P tags in content is because the field is designed to hold just a single paragraph, so having multiple P tags inside the content would break the template layout when it’s rendered. Usually the template renders the content as something like:
<p><%= fieldContent %></p>
In that case, where the output is the only thing within the paragraph, the best solution is to leave the paragraph tags in editor content and remove them from the rendering template. That gives the editor the context it needs to work well and avoids a lot of potential problems with rendering the content. If however, you’re including some extra content in the same paragraph then the situation is more difficult, e.g. your rendering template is more like:
<p>Summary: <%= fieldContent%></p>
In this case, you need to include the P tags within the rendering template and need to ensure that any functionality in the editor which requires inserting a block tag is disabled. Many people think that just switching to insert BR on enter will achieve that, but it’s quite a long way short. For example, if the user creates a list, the template would output:
<p>Summary: <ol><li>Content</li></ol></p>
which is invalid. Similarly since alignment must be on a block tag, it would create:
<p>Summary: <div style=”text-align: center;”>Content</div></p>
which is also invalid. Headings, tables, margins, blockquotes and many other functions will cause these problems. Instead of trying to disable the problematic things, it’s much simpler to only enable the inline formatting options that you need – it should be very limited since you’re only editing a small snippet of content:
- Bold
- Italic
- Underline
- Strike-through
- Font face
- Font size
- Font color
- Background color
- Superscript
- Subscript
- Images
- Hyperlinks
Depending on your editor, there may be a couple of other functions that can work, but most things will need to be disabled. Notably, all these functions work regardless of whether there’s a P tag present or not, because they work “inline”, directly on the text.
Once you’ve restricted yourself to these functions, it’s usually ok to switch the enter key to insert a BR instead of a P, but carefully consider whether having line breaks in the content makes sense with your template anyway. If you want users to be able to insert multiple paragraphs, you should design your template to let them use P tags rather than using BR as a substitute. Consider using a plugin to disable the enter key altogether since the field is designed for a single line response.
Finally, using a plugin or validation when the user submits, check that the content has only one paragraph and isn’t too long to fit within your template. With many editors it will be better to work with the content inside a P tag within the editor and then use JavaScript or server-side filtering to remove them when saving the content.
The bottom line is that when restricting content to a single paragraph, you should ensure that all functionality which works at the paragraph level is disabled in the editor as it cannot be made to function correctly. You should also carefully consider whether users should be allowed to insert line breaks in the content and if they are, whether these are really paragraphs and users would be better served with a slight change to the rendering template, allowing them to use the full functionality of the editor.