List items with nothing but blank lines

[mity]

Spec 0.27 says:

A list item can begin with at most one blank line. In the following example, foo is not part of the list item.

And demonstrates it with Example 241.

However later, there is Example 274:

* a
*

* c

Spec says it should render to

<ul>
<li>
<p>a</p>
</li>
<li></li>
<li>
<p>c</p>
</li>
</ul>

but then the 2nd item here starts with two blank lines which contradicts the quoted rule.

Therefore, I would expect

<ul>
<li>a</li>
<li></li>
</ul>
<ul>
<li>c</li>
</ul>

[jgm]

Spec says:

A list is a sequence of one or more list items of the same type. The list items may be separated by any number of blank lines.

So, in Example 274 we have the following (blank) list item:

*

followed by one blank line. The blank line is not part of the list item; it is one of the blank lines separating list items. Does that make sense?

[mity]

Does that make sense?

Well, maybe. But I still dislike it a lot ;-)

I see these rules together as a quite unnatural and strange combination, especially if I take this into account:

There can be any number of blank lines between items. (Example 267)

That together means that for parsing lists (or maybe even for parsing ANYTHING), the very only situation where count of consecutive blank lines matters is start of an non-empty list item. I see it as against the Principle of uniformity. Especially as I see empty list items as quite a corner case which should not deserve many exceptions.

Second, this rule requires inadequately a lot of work on implementation side. It has to count consecutive blank lines after list item mark and it can only decide what they mean only AFTER them, when a non-blank line is seen.

And although such principle is not explicitly declared anywhere in the specs, I think Markdown language should to a reasonable limits follow something we can call "the Principle of locality".

[mity]

BTW, AFAIK, right now there are only three things in CommonMark specs against the Principle of locality:

1. Links/images using link definition reference.
2. Turning list from tight into a loose one.
3. Subject of this issue.

It's maybe worth to mention that without these, implementations could work strictly in a streaming single pass fashion. Well I of course do not vote to cancel the first two points as they form a strong and well established features of Markdown.

But I argue that adding any new arbitrary feature against the Principle of locality increases complexity of implementation more then any local rules, so doing so should have be done only for strong and important features which really add some value.