Allow whitespace between attributes in directives

[AlbertMarashi]

Initial checklist

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

Problem

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"
}

Solution

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"
}

Alternatives

Nope, enhancement

[AlbertMarashi]

Also, this is more inline with how HTML attributes work since I'm fairly certain they allow newlines or spaces in between attributes of elements

[wooorm]

Have you considered how this affects different directives? Texts? Containers?

Are there other markdown things that work like this?

Have you found this feature in the proposal or in other implementations?

[AlbertMarashi]

@wooorm I don't think it would affect anything. The { should enter a parse mode where consecutive whitespaces are ignored, as is done in HTML, which allows whitespace in attributes.

For container directives, it also should not play a role

:::foo{
   bar="xyz"
}
Some text
:::

Should be functionally equivalent to:

:::foo{ bar="xyz" }
Some text
:::

[wooorm]

HTML is a mostly whitespace-insensitive language. Markdown is a whitespace-sensitive language.

Markdown blocks are parsed per line: either a line is something, or it isn’t. It doesn’t backtrack past lines. What do you want to happen for:

:::foo{
   bar="xyz"
   qwe

Additionally, you mention whitespace, there are still many forms of whitespace that you don’t show. What about:

::question{
    slug="are-you-excited"
      

    098
}

To illustrate those two together, how far do you go?

::question{

# Is this a heading? Just some attributes?

> Block quote? Do we just go to the end is every word here an attribute?

[wooorm]

Importantly, “whitespace” is generally [\r\n\t ]+, and maybe a couple more characters. But in your case you are talking about (\r?\n|\r), which is a line ending.
Some characters and a line ending are called a line.
In markdown, there is also blank lines, which typically break every construct: two line endings, with only spaces and/or tabs in between.

[AlbertMarashi]

I don't know how the inner workings of the parser works, but I don't see why the parser can't enter a certain mode for parsing attributes

When it runs into :::foo{ It should enter the mode of parsing "attributes" (Key-value pairs)

When it runs into a } it should collect those attributes and store them inside of the object holding the information/attributes of the directive

Any cases where it runs into unexpected format of attributes should cause an error

[wooorm]

Markdown doesn't have errors, just like html or css, unlike javascript, it never crashes.

I don't think crashing for directives is a good idea. They're supposed to be like markdown.

This seems like a very big departure from the proposal.

If you want errors and breaking away from markdown and line endings in attributes: we have that already with MDX!

[AlbertMarashi]

Markdown doesn't have errors, just like html or css, unlike javascript, it never crashes.

I don't think crashing for directives is a good idea. They're supposed to be like markdown.

This seems like a very big departure from the proposal.

If you want errors and breaking away from markdown and line endings in attributes: we have that already with MDX!

In that case, it doesn't need to error, rather it will just not parse correctly and instead just return the directive content as text as is currently done (for example like when a comma is inserted in between directives)

[wooorm]

This (backtracking across lines) is something that markdown doesn’t currently do.
It’s dangerous (it can be a source of “DDoSing”).

I understand that you want to do what you propose.
But there is no precedence currently for this feature, in markdown itself or in the proposal.