Option to disable the tight/loose distinction

[makoConstruct]

It's kind of impossible to get nested lists to render in a regular and predictable way due to the tight/loose list distinction. Paragraphs generally have padding. One of the list element types (I forget which) introduces a paragraph, but the rules about tight/loose list items don't correspond at all to whether you'd want there to be padding there. They seem to depend on whether there's a newline in the list item, or whether the list item is an only child, which, basically comes across as a bug.

This is the one aspect of markdown I think was really a mistake. An option to just force all list items to wrap the content in a p element would resolve it. (edit: I reflected on this a bit, I don't think an option does much at all to solve this, I think the sane thing to do is to take a stand, stop doing commonmark, and fix the spec.)

I could probably write this one, if you're open to it.

(If you're not, I'll just be using this kinda counterintuitive CSS that changes paragraphs' margins when they're in uls and uses a weird margin nesting effect that I didn't know existed until today:

p {
  margin-top: 13px;
}

ul p {
  margin-top: 6px;
}
li {
  margin-top: 6px;
}

)

[kivikakk]

I'm open to accepting a PR that implemented this, absolutely! I totally agree on this being a frankly-not-wonderful part of Markdown (and CommonMark) to begin with — the number of times I've had to explain the difference and how each is produced over the years is ridiculous. I feel like this being necessary really sums up how bad the situation is:

comrak/src/cm.rs

Lines 363 to 375 in c030b88

	if !entering
	&& match node.next_sibling() {
	Some(next_sibling) => matches!(
	next_sibling.data.borrow().value,
	NodeValue::CodeBlock(..) | NodeValue::List(..)
	),
	_ => false,
	}
	{
	self.cr();
	write!(self, "<!-- end list -->").unwrap();
	self.blankline();
	}

[makoConstruct]

Hmm I'm very glad to hear that, but now that we are here, it kinda dawns on me that it wouldn't actually save anyone time to add this as an option. Figuring out why you need the option takes time, learning what the issue is called takes time, they would find this issue, and the workaround, before they would find the option, and once they have the workaround they don't need it.

I guess I just think the whole wretched tradition of having a tight/loose distinction should be dropped, that's the only way to really save people from this.

[makoConstruct]

So, would you be interested in just violating the spec and not doing tight/loose? If not, the situation can't really be improved.

[kivikakk]

I'm happy to accept an option to enable this behaviour, yep! Default needs to always be spec-compliant.

[makoConstruct]

Completely disingenuous "yep".

I've explained why a non-default option wouldn't solve the problem. The spec contains a footgun. You know this. I'm not especially curious but you should probably explain at this point why you're sticking to the spec even though you know that it sucks.

[makoConstruct]

Providing an option would mildly improve the situation, but at this point I'm feeling more inclined to make a new markup format. There are some other things I think we're going to need that I don't really see a way to shoehorn into markdown. Something more structured and amenable to user-extensions seems necessary.

[kivikakk]

Because Comrak, first and foremost, exists to implement the CommonMark spec.

I think there's plenty of unexplored space in making markup-type languages, and that CommonMark isn't the be-all-and-end-all by a long shot, but plenty of people have a need for parsing it, and that's what Comrak's for. (It's even in the name, if you kinda squint your eyes.)

All the best.