10 Sep
2018
10 Sep
'18
2:49 p.m.
On Mon, Sep 10, 2018 at 2:35 PM, Vincent Massol <vincent(a)massol.net> wrote:
We should probably also prefix it with "macro" or "wikimacro". So
something
like "wikimacro-wysiwyg-editable" (although I think we can find a better
naming).
Hi Simon,
On 10 Sep 2018, at 13:05, Simon Urli
<simon.urli(a)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.
Cool :) We've been waiting for a long time about this feature! See below.
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>
By “users”, I guess you mean macro developers?
So if I understand you well, you’re not planning to add a getter/setters
to the Macro descriptor, to tell that the macro content contains wiki
markup and that it should be editable in the WYSIWYG editor?
Is that because you want to be finer-grained and have macro content which
can have parts editable with the WYSIWYG while having other parts of the
content not editable (for example)?
Technically Macros don’t generate HTML, only XDOM. So
in order to make it
easier for java macro developers, I’d suggest to introduce some new
wrapping Block to indicate this information. We might need something
similar for wiki macros too, to make it more reusable and typed.
+1. We should avoid duplicating the markup that makes the content editable
in every macro that allows it.
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>
What’s your idea for editing parameters requiring WYSIWYG? How do you
present them in the UI? Do you have any mockup?
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?
Small details, there’s already the “contenteditable” notion that exists
(see https://developer.mozilla.org/fr/docs/Web/HTML/Attributs_
universels/contenteditable) so “editable-content” is quite close. Maybe
we should have something more xwiki-specific? or more WYSIWYG-specific?
Like “editable-wysiwyg” or “wysiwyg-editable”.
My main comment is what I put above: how do we make it easy for macro
developers to specify this information.
2. WDYT about using a data-parameter and this
class for inline editing
of parameters?
Before answering that part, I would need to understand what’s the proposal
in term of UI.
Note that the main use case is for content but it’s
nice if you can also
support parameters. Now, accepting markup in parameters is not really a
great use case IMO and is usually a design issue so I’m not sure we should
spend that much time in supporting that. WDYT?
Even if it's plain text it would still be nice to allow the user to edit
the parameter inline if the parameter appears as is in the macro output. Of
course, this won't apply to all macro parameters, but even if it's just one
parameter, it would still be useful.
The only macro parameter I know ATM that supports markup is the “title”
param of the {{box}} macro and I think it’s badly designed. Note: if you
check the recent {{figure}} macro, I implemented this need by having a
{{figureCaption}} nested macro.
That's OK when the macro parameter is optional and the position in the
macro output is not fixed. But if you want the title to be mandatory or if
you want the title to always be displayed before the message then you can't
allow the user to edit freely the macro content.
BTW this raises a question, will you support WYSIWYG editing of nested
macros?
Thanks
-Vincent
Thanks,
Simon
[snip]