On 02 Apr 2016, at 16:13, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: Several points: * The change above could be rationalized as fixing a bug since it’s not normal that an XHTML/1.0 renderer would generate invalid XHTML * It’s potentially going to break some scripts. For example if you have in a custom vm: $services.rendering.render($panelUix.execute(), "xhtml/1.0”) Thus if we want to make sure that we don’t break backward compatibility we should instead: * Deprecate the “xhtml/1.0” renderer * Introduce 2 new renderers instead of one: “xhtmlfull/1.0” and “xhtmlfragment/1.0” * The problem is that this is not going to work nicely since it would mean we would also need to have parsers for those and the admins would need to decide which syntax to allow in his wiki amongst: xhtmlfull/1.0, xhtml/1.0, html/4.01, xhtmlfragment/1.0. That’s a lot to choose from… So we have 2 real choices I think: * Do as I suggested above but break backward compat in some places (we need to assess more precisely where it would break) * Or instead make the xhtml/1.0 parser support reading fragments. The advantage with this is that it won’t break backward compat. The cons is that it’s quite hard to implement since we have a stream/reader as input and there are plenty of ways to write xhtml. But we could decide that we only support the following use case: ** Read the first char and if it’s not ‘<‘ then add declaration + doctype + html ** If the first char is ‘<‘ then don’t add anything Right now I’m going to try implementing this. Let me know what you think.