Hi everyone, I've started implementing this on the WYSIWYG editor side and there are two constraints that we need to be aware:
(1) Macro#supportsInlineMode() must be false The CKEditor handles macros as widgets <https://ckeditor.com/docs/ckeditor4/latest/guide/widget_sdk_intro.html> and widgets can have nested editable parts, which is great, BUT these nested editable parts must have a block-level element as parent. The list of elements that are accepted as in place editing hosts can be found here https://ckeditor.com/docs/ckeditor4/latest/api/CKEDITOR_dtd.html#property-S-editable . This means that only block-level widgets can be edited in place. As a consequence, only block-level macros can be edited in place. There's an open issue about this https://github.com/ckeditor/ckeditor-dev/issues/1091 but I can't tell if it's going to be fixed soon or not. What options do we have? (a) enable in place editing only for macros that have supportsInlineMode false; that's the easiest but it excludes from the start macros such as info, error, warning, which is a pity. (b) activate in place editing only when the macro generates block level content; this means that the users will be able to edit in place a warning macro that is standalone, such as: -----8<----- before {{warning}}message{{/warning}} after ----->8----- but not a warning macro that is inside some paragraph text, such as: -----8<----- before {{warning}}message{{/warning}} after ----->8----- The issue is that we don't always know if the macro output is block-level until we render the macro so hiding the macro content text area when inserting a macro is not easy. (c) Try to implement https://github.com/ckeditor/ckeditor-dev/issues/1091 ourselves, but I don't think it's easy (d) Don't use widgets to support macros and implement something custom. I think this is crazy. (2) The second constraint is that the macro content must not be mandatory. ATM both {{info/}} and {{info}}{{/info}} generate "The required content is missing." and so do the other macros I've tested. So it seems there's no distinction between empty content and no content at the implementation level. Thus, if we want to hide the macro content text area when inserting a macro such as {{info}} then we need to make the macro content optional. Either by changing the macro descriptor or by changing the implementation to differentiate the empty content from no content specified. Thanks, Marius On Mon, Sep 10, 2018 at 2:05 PM Simon Urli <simon.u...@xwiki.com> wrote: > Hi everyone, > > I'm working on the roadmap issues related to the inline edition with > WYSIWYG editor for macro content and macro parameters. > > The first step is to add a flag to allow user specify that a content or > a parameter can be edited inline with the WYSIWYG editor. > > The second step is to allow the CKEditor to detect where the content > and/or parameters should be edited. > Let's take the exampe of a simple macro without any parameter, which > currently produces this code: > > <div class="box infomessage"> > <div class="title"> > <span class="icon info"></span> > some title > </div> > Some content > </div> > > We propose (me & Marius) to ask users to add a wrapper with a specific > class around the content to tell the editor it should only allow editing > this content, e.g.: > > <div class="box infomessage"> > <div class="title"> > <span class="icon info"></span> > some title > </div> > <span class="editable-content">Some content</span> > </div> > > About parameters, our idea was to define a new metadata attribute and to > ask users to use it for specifying the content is editable, such as for > a parameter named foo: > > <span class="editable-content" data-parameter="foo">my foo parameter > value</span> > > However I don't know right now how the editor would manage cases such as: > <span class="editable-content">Some content with <span > class="editable-content" data-parameter="myparameter">a > parameter</span></span> > > So: > 1. Do you agree on the usage of a class named "editable-content" > which would be used as a tag to allow inline edition? > 2. WDYT about using a data-parameter and this class for inline > editing of parameters? > > Thanks, > Simon > -- > Simon Urli > Software Engineer at XWiki SAS > simon.u...@xwiki.com > More about us at http://www.xwiki.com >