Handle nested block quotes in XWiki syntax or in a macro

Development
1

It is currently not possible to write a quote with complex content in it. The quote syntax (‘>’ at the beginning of a line) we have doesn’t support block content.

Our WYSIWYG editor lets users write blocks in quotes, but the syntax they get upon saving is broken. For instance, if they input a list inside a quote, they get:

>(((
* hello 1
* hello 2
)))

This currently renders as an empty block quote, and then a list outside the quote and no error is shown upon saving or rendering.

It would be nice to avoid this WYSIWYG glitch and to support quotes containing block elements in the XWiki syntax, like HTML.

Here are two approaches to achieve this:

  1. Change the parser to accept nested content like in lists or table cells (and make sure we produce the correct syntax in the renderer, and make sure there are no related inconsistencies). This would be a breaking change if we don’t update the version of the syntax.
    1. We could limit the change to make the quote character directly followed by the quote, which would make whatever the WYSIWYG editor (the renderer) already produces
  2. Introduce a bundled block quote macro. Change the renderer to detect nested block elements in quotes and if there is any, wrap the content in that block quote macro.
    1. We could name it quote
    2. We could name it blockquote
    3. We could name it something else (please propose)
  3. Don’t do anything, we don’t want this in XWiki standard and we should let a contrib extension handle this if someone needs it.

I don’t like 3 because the situation is currently broken with the WYSIWYG editor.

Context:

  • supporting this would help import content from Confluence, which allows arbitrary content in block quotes
  • related issues:

I open this to votes. Thanks @MichaelHamann for actually drafting proposal 1 and 2.

I suggest a deadline to next Wednesday (28th)

1 Like
2

The safest seems to be 2., but we should probably create an issue dedicated to adding support for this use case in any future xwiki/2.2 syntax.

3

You linked the same issue twice :slight_smile:

There’s this one too: Loading...

4

Whoops, I meant to link Loading..., but your’s definitely relevant, thanks for sharing.

5

OK, that’s indeed the issue dedicated to adding support for this use case in any future xwiki/2.2 syntax.

6

there are 3 :slight_smile:

I had coded a quote macro already. I suggest to improve it to support standalone content. See https://extensions.xwiki.org/xwiki/bin/view/Extension/Quote%20Macro

I don’t think we should do nothing, at the minimum we should fix the wysiwyg editor so that it doesn’t allow standalone content inside quotes for xwiki syntax 2.0 and 2.1. When xwiki/2.2 is out, the wysiwyg should support standalone content inside quotes for that syntax.

Thanks but there is no question in your vote :slight_smile: In a vote you need to explain what you propose to do and the answer needs to be Yes or No. Here it’s not even a proposal but more like a brainstorming since you don’t propose anything (you’re just listing the options).

So I’ll assume it’s not a vote (I can’t answer +1, 0, or -1) and my opinion is:

  • Do 1) in xwiki/2.2
  • Do 2) for xwiki/2.0 and xwiki/2.1 by improving the existing quote macro at https://extensions.xwiki.org/xwiki/bin/view/Extension/Quote%20Macro
  • Don’t do 3) but do 4) which is

    fix the wysiwyg editor so that it doesn’t allow standalone content inside quotes for xwiki syntax 2.0 and 2.1. When xwiki/2.2 is out, the wysiwyg should support standalone content inside quotes for that syntax.

Thanks

1 Like
7

That macro displays its content verbatim, without supporting any syntax in its content. At least to me, changing it to support wiki content and in particular block content seems like a very breaking change that would totally change the nature of that macro.

To me, the question here is which of the 3 listed options should be chosen. More precisely, the main question to me is if we should change the parser to support what the renderer produces, which is a group syntax inside a quote syntax. As this is a breaking change, we can’t change that without a vote.

And here is my +1 vote to perform that change on the parser, so to implement option 1 (in xwiki/2.1). I see the following reasons for it:

  1. The renderer supports it already, so it’s just an inconsistency.
  2. It’s hard to argue that if you write
> (((
* hello 1
* hello 2
)))

you wanted an empty quote with a list after it. Note that I suggest that we only support a group syntax that follows directly after > (with some spaces in between), nothing else. So > === Heading === won’t be a heading in a quote for example. If you currently render

> == Heading ==

> ((( test )))

you get
image

So a group syntax inside a quote is clearly different from a heading syntax inside a quote.
3. While we can maybe update CKEditor to forbid that content inside the blockquote as CKEditor is aware of the syntax of the document, we can’t really expect that parsers of other syntax don’t produce block content nested inside a quote. You’ll still get this kind of XDOM that produces this broken syntax when importing an office document or a document from a Confluence wiki. We can’t really expect that office import or parsers for other syntaxes don’t produce this syntax but instead introduce the quote macro. It would also be difficult to update them at some point when xwiki/2.2 that supports this should exist as we don’t tell them which syntax we want to convert to afaik.

I’m also not against option 2 if we really change the XWiki syntax renderer to produce the quote macro (similar to how it produces an ID macro for example). So +0 for that option.