micromark / micromark-extension-directive

micromark extension to support generic directives (`:cite[smith04]`)
https://unifiedjs.com
MIT License
31 stars 16 forks source link

Allow spaces between directive fence and name #18

Open digitalmoksha opened 1 year ago

digitalmoksha commented 1 year ago

Initial checklist

Problem

In the README you mention

Note that while other implementations are sometimes loose in what they allow, this implementation mimics CommonMark as closely as possible:

  • Whitespace is not allowed between colons and name (: a), name and label (:a []), name and attributes (:a {}), or label and attributes (:a[] {}) — because it’s not allowed in links either ([] ())

CommonMark, for code fences, allows a space(s) between the code fence and the language identifier

```   ruby
x = 1

gives 

```html
<pre><code class="language-ruby">x = 1
</code></pre>

https://spec.commonmark.org/dingus/?text=%60%60%60%20%20%20ruby%0Ax%20%3D%201%0A%60%60%60%0A%0A

I would think that we would want to have the same syntax for directive containers 🤔 Not sure it makes sense to have different rules here.

Solution

Allow container directives to have a space between the fence and the name.

::: spoiler

would be allowed

Alternatives

-

wooorm commented 1 year ago

Heya! :)

Some more reasons other than the one provided in the docs:

digitalmoksha commented 1 year ago

Sorry to keep poking in different directions :-)

I would still come down on the side of sticking with adherence to CommonMark conventions, whether that's how links are handled, or code blocks are handled.

Inline is a little different, and can have slightly tweaked syntax because it's inline.

But a block directive is really (from my current understanding) a more generalized syntax of a fenced code block. In fact, as a markdown user, I would expect a block directive to be able to be used in exactly the same way/places (embedded in lists the same way, etc). That "fenced block" syntax should be the bedrock of the block directive.

The current handling also aligns with HTML: < followed by whitespace is just a <. If it’s followed by a letter, then it becomes a tag.

I'm not sure that really matters. Since this is decidedly not an HTML document (it's just tolerated), I don't think that should be a factor that overrides the underlying accepted CommonMark syntax.

wooorm commented 1 year ago

I think y0our points are all quite reasonable. How I order importance is:

  1. text (inline) must not have a space. Otherwise it doesn’t work
  2. the different kinds should be consistent
  3. similarity to other markdown things is nice

Your point, 3, is indeed important. But I think the other ones are more important.

That "fenced block" syntax should be the bedrock of the block directive.

This is complex, because in other senses it’s much more like a block quote or a footnote definition.

But that’s the problem with all these syntaxes: they are all completely different. Seemingly sometimes similar. But no thing in markdown works the same as other things.

Which is why I’d like to start out strict. And then maybe we can become looser if there’s more consensus!

Since this is decidedly not an HTML document (it's just tolerated), I don't think that should be a factor that overrides the underlying accepted CommonMark syntax.

It’s not super relevant, but I do see the tag syntax from HTML/XML/MDX/JSX, and generic directives, as solving the same thing. Hence I use them as inspiration.

AlbertMarashi commented 1 year ago

I think

suffers from long lines
::question{slug="are-you-excited" question="What are you excited to learn about in this course?" context="The course is about Programmatic thinking" }

Easier to write & read
::question{
    slug="are-you-excited"
    question="What are you excited to learn about in this course?"
    context="The course is about Programmatic thinking"
}

Should be allowed, but it's not

wooorm commented 1 year ago

Unrelated to this issue.

AlbertMarashi commented 1 year ago

Unrelated to this issue.

Well it's about whitespace between directives, so I think it's kind of relevant

wooorm commented 1 year ago

Again, that's different.