For simple values ofc. More complex displayers should still return standalone content.
XWiki rendering goes: wiki syntax → XDOM (a tree of blocks) → XHTML. In that tree, content is either inline (words, links, inline macros — things that live inside a line) or block (paragraphs, lists, tables — things that stack vertically). A document's top level is always a sequence of blocks.
A macro like velocity…/velocity or include/ is parsed as standalone (block) when it sits on its own line, and inline when it's embedded in a line of text. The AWM Date customDisplay is exactly this, alone on its own:
include reference="AppWithinMinutes.DateDisplayer" /
→ standalone macro. Its inline output (31/01/2024 …) therefore gets wrapped in a paragraph block → <p>31/01/2024 …</p>.
Why fixing the displayer itself can't remove the <p>
This is the key point, and it's why I went to the core. The wrapping paragraph is not added by the AWM displayer — it's added one level above it, by the generic machinery that renders any property's customDisplay. The chain is:
PropertyClass.displayCustom()
└─ getRenderedContent(customDisplayContent, …) ← renders it as a document
└─ a document's top-level inline content ⇒ ParagraphBlock ⇒ <p>…</p>
The crucial bit: rendering inline text as a document always wraps it in a top-level paragraph. To prove it's not the displayer's fault, imagine forcing the macro inline by putting a character in front of it:
x{{include .../}} → XDOM = Paragraph[ "x", include ] → <p>xvalue</p>
Still a <p>. The paragraph is intrinsic to "inline content sitting at the top of a document," not to anything the displayer writes. So no edit to Date.xml / DateDisplayer.xml / Title.xml can remove it — the displayer produces inline content (correct), and the wrapper is slapped on above, where the displayer has
no reach.
The displayer's only escape would be to emit block HTML (a <div>…) so no paragraph is added — but then it's a block element, not the inline plain text the issue asks for. Or it would have to render its own output, re-parse it and strip the paragraph in Velocity — which is exactly the core fix, just duplicated
awkwardly into wiki code, and it still can't strip the outer paragraph.
A related dead-end: AWM can't switch to a paragraph-free template: displayer (which is how the standard date displayer avoids this — templates bypass getRenderedContent), because an XClass property with customDisplay content is always routed through the wiki-document rendering path. And it can't drop
customDisplay either, since that's what gives the date its edit-mode picker and emptyIsToday behavior.
So the layer is correct
Because the <p> is introduced by the shared customDisplay rendering, the fix belongs in displayCustom — and that's precisely why the same one change resolves both XWIKI-21845 (Date) and XWIKI-21846 (Title): they're the same wrapper, not two separate displayer bugs.
