volto-slate does not properly support "list in list" as generated by Plone Classic

[tiberiuichim]

In Plone classic, create a list in a list in a richtext field. This is how do to it:

• create a list with a single line
• create another line in the list (another list item)
• increase the level of the list item

The generated HTML is:

<ul>
  <li>blabla
     <ul>
        <li>dasdasdas</li>
     </ul>
   </li>
</ul>

Notice that the sublist is a part of the list item.

If you try the same thing with Volto (you can increate the level of the elements using the Tab key at the beginning of the list item), you'll get the following markup:

<ul>
  <li>blabla</li>
  <ul>
        <li>dasdasdas</li>
   </ul>
</ul>

If you copy the rendered markup of the Plone Classic above list and paste it in a Volto block, it will "silently eat" the sublist. If you generate the proper slate structure (using code from the plone.volto slate support PR), everything will appear to be working, but when you try to do any editing on the text block, the sublist will be swallowed.

[tiberiuichim]

Here's a page with sublists as a sample: https://climate-adapt.eea.europa.eu/en/eu-adaptation-policy/strategy

[tiberiuichim]

[tiberiuichim]

this is "expected behavior" because config.slate.inlineElements does not contain either ul or li elements.

According to the TinyMCE generated markup, they should be inline.

[davisagli]

@tiberiuichim What do you mean that they should be inline according to the TinyMCE markup? The TinyMCE markup for nested lists is correct (there is a similar example at https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ul) but lists and list items are block-level elements in HTML, not inline -- https://developer.mozilla.org/en-US/docs/Web/HTML/Block-level_elements

[tiberiuichim]

@davisagli I agree, it's just that I need to understand how to align the expectations of slate vs our internal model.

The problem we're hitting one of these two conditions: https://github.com/ianstormtaylor/slate/blob/1d8010be8500ef5c98dbd4179354db1986d5c8f4/packages/slate/src/create-editor.ts#L236-L237C13

Basically, for an element <li>text<ul>...</ul></li>, the first child (node.children[0]) is an inline element (Text), so slate expects that all the other children are also inline elements (shouldHaveInlines is True).

So, in my screenshot, when Slate is normalizing the parent <li> and it reaches the <ul> child, isInlineOrText is False for the ul, so it just removes it.

[tiberiuichim]

This comment from slate code is a bit head-scratching, as it seems to contradict the Mozilla examples:

https://github.com/ianstormtaylor/slate/blob/1d8010be8500ef5c98dbd4179354db1986d5c8f4/packages/slate/src/create-editor.ts#L253-L256

        // Only allow block nodes in the top-level children and parent blocks
        // that only contain block nodes. Similarly, only allow inline nodes in
        // other inline nodes, or parent blocks that only contain inlines and
        // text.

[davisagli]

@tiberiuichim I think it means we have to turn

<li>
  some text
  <ul> ... </ul>
</li>

into the slate equivalent of

<li>
  <div>some text</div>
  <ul> ... </ul>
</li>

so that the text is not parented by a node that contains both block-level and inline elements.

[tiberiuichim]

@davisagli as an additional piece of information, volto-slate uses almost exclusively Element nodes (blocks), but declares them to be "inline", for example https://github.com/plone/volto/blob/master/packages/volto-slate/src/editor/plugins/Link/extensions.js#L11

[tiberiuichim]

yes. Let's see if we can avoid this, I'm afraid that if we introduce another node we may make it weird to navigate and format things in lists. I think I should test this.