On Sat, Apr 2, 2016 at 4:25 PM, Vincent Massol <[email protected]> wrote: > >> On 02 Apr 2016, at 16:21, Vincent Massol <[email protected]> wrote: >> >>> >>> On 02 Apr 2016, at 16:13, Vincent Massol <[email protected]> wrote: >>> >>>> >>>> On 02 Apr 2016, at 15:38, Vincent Massol <[email protected]> wrote: >>>> >>>> Hi devs, >>>> >>>> One issue we have ATM is that the xhtml/1.0 parser requires valid XHTML >>>> but the xhtml/1.0 renderer generates invalid XHTML (it generates fragments >>>> only). This causes https://jira.xwiki.org/browse/XWIKI-13278 for example. >>>> >>>> I’m proposing to: >>>> * Modify "xhtml/1.0" renderer to generate valid XHTML (i.e. xml >>>> declaration + doctype + html element) >>>> * Introduce a new "xhtmlfragment/1.0” renderer >>>> * Have annotated versions of both for the WYSIWYG editor >>>> >>>> WDYT? >>> >>> 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. >> >> I’ve thought about another possibility. Implement a "xhtml/1.1” >> parser/renderer instead. It could also comply with XHTML 1.1. >> >> We would “deprecate” the xhtml/1.0 syntax and favor using the 1.1 version. >> >> This seems the best to me, wdyt? We’ve already added an html/5.0 renderer >> recently FTR. > > To be clear this would mean: > * Introduce "xhtml/1.1" parser and renderer > * Introduce a “xhtmlfragment/1.1” renderer
We mostly moved to html 5 in XWiki UI so I don't see any value for XWiki in adding more xhtml/* renderers. > > Another option is to do the same but with xhtml/5.0 (especially since we’ve > introduced html/5.0 already). A cleaner but a bit more expensive alternative is to refactor renderers/parsers (maybe just renderers first) to filters which among other things support configuration (technically similar to macros). This mean you could easily set a boolean to indicate you want a fragment or complete document, and many other things. Since filters would still implement org.xwiki.rendering.listener.Listener interface in practice it's usually easy to reimplement existing APIs without breaking them. This is something we need to do at some point anyway. > > WDYT? > > Thanks > -Vincent > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
