Hi everyone,
On 10/3/18 5:42 PM, Marius Dumitru Florea wrote:
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.
This option seems less limitating and more easy to achieve isn't it?
And it seems to me that the limitation you mention, can be mitigated if
the content is optional: as you specify below even without a content,
the macro message is able to produce an XDOM output that you could use
to know if the top level is a block or not.
(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.
Making the macro content means in fact that there is a default content.
So if we make the content optional for the message macro, do you propose
that we put an empty default content?
Simon
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
--
Simon Urli
Software Engineer at XWiki SAS
simon.u...@xwiki.com
More about us at http://www.xwiki.com
