Stop creating paragraphs in tight lists

[Hamms]

See syntax-tree/mdast-util-to-hast#23 for context.

This PR represents an opposing solution to the one presented in that PR; a solution in which the problematic paragraphs are never created in the first place, rather than being created and then discarded by the MDAST-to-HAST conversion.

[wooorm]

Could you update the tests as well? node script/regenerate-fixtures should do the trick!

[wooorm]

Wouldn’t this make more sense in list-items?

[wooorm]

I’m proposing some changes to mdast, as can be seen here.

• I propose dropping loose on listItem
• list.loose should default to false. loose: true can be inferred here in remark-parse based on whether there’s blank lines between items
• The content of list can be either block or phrasing content (see the aforementioned PR). However, we can change that. There’s something to be said for nodes always being block level!
• mdast-util-to-hast should have its own logic to check if the list items can be expressed without blank lines. If that is not the case, <p> elements must be used. This is because utilities could add other block nodes, and not update loose
• If a list can be tight, but has loose: true, <p> elements are used
• Otherwise, no <p> elements are used

Does that make sense?

[Hamms]

I think that makes tons of sense!

Can you explain a bit more what you mean by mdast-util-to-hast having its own logic? I'm not convinced that we want to make the decision about whether or not to use p tags based on the nodes in the list item rather than making that decision based exclusively on the loose property

[wooorm]

@Hamms This value:

- a
- b

  c
- d

Should in HTML be represented by <p> elements, because one item has two blocks, so it must be loose, whether the loose field is true or false.

Now, if we have an ambiguous tree that could be either:

- a
- b
- d

...we can check the loose property to either go loose or tight!

[Hamms]

Hmmm, interesting. Just to make sure I'm following you, you mean the MDAST

root[1]
└─ list[3] [ordered=false][loose=false]
   ├─ listItem[1] [loose=false]
   │  └─ paragraph[1]
   │     └─ text: "a"
   ├─ listItem[2] [loose=false]
   │  ├─ paragraph[1]
   │  │  └─ text: "b"
   │  └─ paragraph[1]
   │     └─ text: "c"
   └─ listItem[1] [loose=false]
      └─ paragraph[1]
         └─ text: "d"

That has been artificially modified by a utility that added the c node without setting things to loose, right?

I'm actually not completely convinced that this should be converted into a HAST with p tags; it seems like an invitation to unpredictable behavior to make the decision about whether or not to include p tags be based on anything except for the loose flag.

[wooorm]

Yes, I do mean that.
However, I do propose either dropping list.loose or listItem.loose. Both is unnecessary.

I'm actually not completely convinced that this should be converted into a HAST with p tags; it seems like an invitation to unpredictable behavior to make the decision about whether or not to include p tags be based on anything except for the loose flag.

What I’m proposing is that:

• a) either: if list.loose is turned off, but a block is added to a list item, the loose value is disregarded and a loose list is created anyway
• b) or: if listItem.loose is turned off, but a block is added to it, the loose value is disregarded and a loose item is created anyway

We need to infer the actual looseness anyway in markdown. Not so sure about HTML, but that’s what I’m basing my thinking off, if that’s not true, we can skip it for HTML!

When mapping to HTML, this behaviour would happen at list-level, wherever the property exists.
When mapping to markdown, this behaviour could happen at list-item-level, or list-level, wherever the property exists

[Hamms]

However, I do propose either dropping list.loose or listItem.loose. Both is unnecessary.

👍 I would strongly advocate for dropping listItem.loose and keeping list.loose, since from what I understand the list as a whole should be either loose or tight, and the looseness of the items is only used to determine the looseness of the list as a whole.

if list.loose is turned off, but a block is added to a list item, the loose value is disregarded and a loose list is created anyway

The counterpoint I have to this is the original case when prompted me to dive into this:

- item one
  - item two

In this case, list.loose is turned off and a block (namely, a ul) has been added to a list item, but we definitely don't want to disregard the loose value.

[wooorm]

@Hamms OK, few new ideas:

• Content of listItem should definitely be BlockContent (so paragraph), instead of PhrasingContent (such as emphasis and the like). Otherwise the tree just gets too confusing.
• loose is only present on list
• Your example:

  - item one
    - item two

  ...should (where the list is added) be represented in HTML as without <p>s. We can honour loose there. We can do that in markdown as well I think, we’re doing that already!

[Hamms]

Okay, cool. So it sounds like we just need to make sure that paragraphs in tight lists are correctly dropped in mdast-util-to-hast

[Hamms]

Unless you object, I'm going to close this PR and focus my efforts on syntax-tree/mdast-util-to-hast#23

[wooorm]

Yes, good! Quite the confusing problem!