list items wrap p, don't make new li on return

[forresto]

On http://prosemirror.net/ in Firefox and Chrome,

1. make a new line
2. switch it to list with side menu
3. try to add a new line

expected html:

<ul pm-path="2">
  <li pm-path="0"><span pm-span="0">list item one</span></li>
  <li pm-path="1"><span pm-span="0">two</span></li>
</ul>

actual html:

<ul pm-path="2">
  <li pm-path="0">
    <p pm-path="0"><span pm-span="0-13">list item one</span></p>
    <p pm-path="1"><span pm-span="0-1">two</span></p>
  </li>
</ul>

---

[marijnh]

I know. This is by design. You can override it by defining a new command that splits a list item, and binding it to Enter with a higher precedence than the default paragraph splitting command, but I don't actually recommend that. Quite a bit of thought went into the current enter/backspace behavior -- it's predictable (as in, based on straightforward rules without much exceptions) and powerful (you can use it to produce almost every nested structure).

[forresto]

I didn't notice that enter again makes the new li.

[marijnh]

Sorry, should have mentioned that too. This'll definitely go into the user tutorial, once we have one.

[tumm]

Hi guys,

It seems like a double enter does not create a new list item on mobile chrome.

Instead of the expected behaviour, it seems like either:

1. I get continuous new paragraphs
2. I get continuous new paragraphs, and the text moves down with the cursor, leaving a blank line above.

[Lykoskia]

I had to write custom node resolvers in Storyblok rich text renderer just to remove the < p > tags in < li > elements (I can't imagine who could have possibly thought this was a good idea?! < li > are block level just like < p >!) and the ability to write multiple consecutive newlines (so I can actually have real paragraphs instead of just linebreaks). Why on earth has this not been fixed for so many years (almost a decade if I'm reading this right)?

I find it hard to believe that you've been aware of this since at least 2015 and that it's still by design?

You are aware that list items are not meant to each be in their own paragraphs, but that rich text can and does have actual paragraphs (like this comment)? Maybe I should've just crammed it all together. Maybe I should also have replaced all spaces with question marks and shifted all letters by using the character with a certain charcode offset.

Please help me understand the justification for this, since I've lost about as much time working around the ridiculous rich text renderer as I have with the entire rest of the application.

Thanks.

[marijnh]

I had to write custom node resolvers in Storyblok rich text renderer just to remove the < p > tags in < li > elements (I can't imagine who could have possibly thought this was a good idea?! < li > are block level just like < p >!)

You are aware that you can control whether list items contain blocks or just inline content in your schema, no? And, yes, blocks inside list items are also perfectly valid HTML, and in fact the only reasonable way to represent list items with multiple paragraphs in them.

[Lykoskia]

I had to write custom node resolvers in Storyblok rich text renderer just to remove the < p > tags in < li > elements (I can't imagine who could have possibly thought this was a good idea?! < li > are block level just like < p >!)

You are aware that you can control whether list items contain blocks or just inline content in your schema, no? And, yes, blocks inside list items are also perfectly valid HTML, and in fact the only reasonable way to represent list items with multiple paragraphs in them.

Yes, I am aware that you can, since I managed to do it, I'm just questioning why I had to go through that just to make a list work as it naturally does. Yes, block elements can contain other block elements, but the point is the extra p (which is not optional, but always added) means that your actual list items would ignore any styling you assign to actual NODE_LI resolvers, as they are no longer li elements, but p elements with li children. I can't assign ul/ol/li specific CSS to a p element. I'm not sure I can even target this inserted p element without messing up normal paragraphs.

The other issue is probably even more important and that is sequential newlines. I don't remember having either of these issues with Portable Text. But in any case, my question is still: why do you secretly and forcefully insert that p in there? li elements can have children, you don't have to nest a p inside of it to do that. Any block element can contain nested block elements as children, and li is, as I said, a block element. So again, both things work just fine without the added p tag.

Just so you get an idea of my pain.