we have certain macros like mentions or footnotes, for which it just doesn’t make any sense to use them in standalone mode - it would be totally surprising for a user to insert them in the WYSIWYG editor and then not to be able to insert text in the same line before or after them.
I would therefore suggest introducing a way for macros to indicate that they don’t support standalone mode similar to how macros can already indicate that they don’t support inline mode.
There are several options for this:
Duplicate what we have for supportsInlineMode as supportsStandaloneMode, at least the part in the macro descriptor and in the wiki macro descriptor. The default would be true for this new property.
Refactor the macro descriptor and the wiki macro definition to have a set of supported modes with inline and standalone as possible values and deprecate the existing supportsInlineMode methods. Of course, there would be backwards compatibility code to ensure that the existing methods still work, which might be a bit complex to support all possibilities.
I propose the following consequences when a macro is marked as supporting inline mode only:
Ensure that CKEditor always inserts such macros as inline, similar to the existing inline: enforce property.
Before the macro transformation executes such a macro, if the macro is marked as standalone, the macro is wrapped in a paragraph.
Do you have any opinions on this, in particular related to how this property should be stored?
Generally +0 although the reason we didn’t do this is because we couldn’t imagine a macro that couldn’t work when used standalone (even if it makes less in some cases as you mentioned).
You give the example of mentions, for me it makes sense that it should work standalone and I can see valid use cases.
For the footnote macro, it makes less sense indeed but I’m not sure why it’s a problem and I’m sure it’s even possible to find use cases for it.
I’m curious to understand what need you got that lead to this proposal.
Right now all macros are marked as standalone, so adding an extra paragraph would break a lot of macros. Also, IMO, if the macro works in standalone mode, it’s up to the macro to output valid standalone blocks.
Not sure what is the problem here. A macro can support both standalone an inline. So inserting such a macro as the only element on a line makes it standalone but as soon as you add other items on the same line, it makes the macro inline. And the rendered content of the macro generates the correct blocks appropriately.
This extra paragraph would only be inserted for macros that don’t support standalone mode, not for all macros (note the “such” in my text).
The problem is that as soon as you’ve inserted a macro as standalone macro in the WYSIWYG editor, it is no longer possible to insert other content in the same line - the macro fills the line, and it is only possible to insert content in a new paragraph above or below the macro. There is no way to convert a standalone macro to inline (or vice versa) in the WYSIWYG editor.
ok but this is going to happen for all macros supporting both inline and standalone mode and won’t be fixed by your proposal. We need to improve the wysiwyg editor’s feature IMO for this.
ok (so only for inline only macros). I still don’t understand the need and why we would change the strategy we currently have which is that macros are responsible for the blocks they output. If we change the rule of inline-only macros, then macros which support both inline and standalone will be written differently, handling the blocks the output, and this is not consistent.
I’m still lacking this as I don’t see what you are trying to solve.
For macros that don’t support inline mode, when they’re used inline, it’s also not the macro that’s responsible for dealing with the situation, but instead the macro transformation outputs an error instead of executing the macro. For inline only macro, instead of printing an error, I suggest just wrapping them in a paragraph as the situation is easy to fix. In the case of standalone macros in an inline context no such easy fix exists, so I think it’s okay to get an error instead.
I’m trying to develop a clean and nice fix for XRENDERING-705 that results in good usability in the WYSIWYG editor. While the easiest fix would be to just wrap the regular output of the footnote macro in a paragraph, it’s not a good fix imho as - as I explained above - it makes it impossible to add text in the same line before or after the footnote in the WYSIWYG editor. In the current version of the pull request I proposed a simple hack in the putFootnotes macro to wrap the footnote macro in a paragraph but as it has been pointed out there by @tmortagne, this isn’t very clean, and it would be nicer to be able to indicate that a macro doesn’t support standalone mode.
IIUC, @vmassol’s argument is that this could be fixed from the WYSIWYG editor, by providing a quick and simple way to “convert” a standalone macro to inline. This is doable for instance with a button on the balloon toolbar that is displayed when selecting / focusing a macro. The button would be visible only for standalone macros that support inline mode. Of course, we would have to re-render the entire content, while preserving the selection, like we do when updating a macro.
But this leads to a usability problem: for some macros (like mention and footnote) the users will have to make an additional action most of the time in order to add content inline after the macro call. Moreover, this additional action would pretty much “duplicate” the rendering done when the macro was inserted.
With this in mind, I’m wondering if instead of saying that a macro doesn’t support standalone mode, maybe we should instead let the macro specify the preferred mode, when both standalone and inline modes are supported. This information wouldn’t be used directly by the rendering, but by the WYSIWYG editor, when inserting a macro, e.g. by adding a space after the macro call if the macro descriptor specifies that the inline mode is preferred.
This sounds like an interesting solution indeed. What would the WYSIWYG editor do when a macro supports inline mode but prefers standalone mode? Would it always insert it in standalone mode? If yes, should there be a way to indicate that the macro is indifferent, which should be the default?
I wouldn’t force the standalone mode. I mean, if you are in the middle of some text, and you insert a macro that supports both standalone and inline but prefers standalone, I would still insert it inline because the context asks for it. I would obey the preference only when both make sense in the current context (where the macro is inserted). For a start, I would simply:
keep the current behavior in the WYSIWYG editor when inserting a macro, if the standalone mode is preferred (which should be the default in the macro descriptor)
insert a space after the macro call if the macro prefers inline mode (in order to force the inline mode); the inserted space should be harmless if the context is already inline.