As in title. Setting an explicit p tag in the basic text element inside a query loop triples the number of p tags. An empty p tag with the classes, a middle p tag with the text, and finally a completely empty p tag. Furthermore, not setting it explicitly loses the p tag classes.
See images below.
Not setting an explicit p tag gives us only one p tag as is expected.
Also, if you decide to give the basic text element an implicit p tag, please reflect that in the placeholder HTML tag field because right now it shows div and we have a div but we also have a p tag.
This is the expected result, as the post content already contains p-tags. p-tags within p-tags are not allowed in HTML, so the browser will do everything it can to fix the problem.
If you are unsure whether dynamic data contains p-tags (or when using a wysiwyg dynamic data field), leave the basic text HTML tag set to div, use the rich text element, or, in your case, the post content element.
OK, reporting one more finding about this and a bit of an inconsistency:
If one uses {post_content} without a max count inside the basic text element, it generates (pulls?) the extra p tags. If one uses {post_content} with a max count, e.g. {post_content:35} it does not generate the extra p tags.
As I said, there is a dedicated element to render the post content: the post content element—or alternatively, the rich text element, which handles rich, aka formatted text.
The basic text element is not called “basic” text without reason, as it should contain simple, preferably unformatted text, which isn’t the case 99% of the time with {post_content}.
PS: If you trim the text, the HTML tags will be removed (see helpers.php).
