Allow spaces between directive fence and name

[digitalmoksha]

Initial checklist

• [X] I read the support docs
• [X] I read the contributing guide
• [X] I agree to follow the code of conduct
• [X] I searched issues and couldn’t find anything (or linked relevant results below)

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

<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]

Heya! :)

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

• It’s probably a bad idea to have different rules between text/leaf/container directives
• Doing this too for text (inline) directives, is prone to problems (word: isThisADirective?). That’s a format used a lot in the wild already.
• 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.

[digitalmoksha]

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]

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]

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]

Unrelated to this issue.

[AlbertMarashi]

Unrelated to this issue.

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

[wooorm]

Again, that's different.