Attributes in fenced divs are somewhat brittle - could this be improved?

[cscheid]

Minimal reproducible example for context. Spaces around the attribute key-value pair definition cause Pandoc to give up on parsing the div.

$ pandoc -f markdown -t native
::: {#hello .class key = value}

This will fail

:::
^D
[ Para
    [ Str ":::"
    , Space
    , Str "{#hello"
    , Space
    , Str ".class"
    , Space
    , Str "key"
    , Space
    , Str "="
    , Space
    , Str "value}"
    ]
, Para
    [ Str "This" , Space , Str "will" , Space , Str "fail" ]
, Para [ Str ":::" ]
]

In contrast,

$ pandoc -f markdown -t native
::: {#hello .class key=value}

This will not fail

:::
^D
[ Div
    ( "hello" , [ "class" ] , [ ( "key" , "value" ) ] )
    [ Para
        [ Str "This"
        , Space
        , Str "will"
        , Space
        , Str "not"
        , Space
        , Str "fail"
        ]
    ]
]

Why I think this matters. Last week we (I work for Posit on Quarto) hosted a teaching event for Quarto dashboards. The fenced div syntax is important for us, and so we ask learners to write documents with it. Approximately 80 people attended in person (so I could see what they were typing). About 10 people made the mistake shown above, typing key = value instead of the expected key=value.

Because there's no syntax errors in Pandoc, this was an instant blocker for a surprisingly large fraction of the attendees. That leads to my title: could this be improved?

I'm willing to try and write a PR to improve this, but it interacts with how Pandoc's markdown is defined to begin with (and so I imagine it's a delicate part of the code base). So, before I got started: would changing the parser to tolerate spaces around key-value definitions be an acceptable PR?

Thank you, as always!

[bpj]

Remove the spaces around the =. They are invalid.

[cscheid]

Remove the spaces around the =. They are invalid.

I'm aware that they're invalid, thank you. My point is that this is confusing for our users, and that it's a hard thing for them to figure out. That's what I'm proposing to improve.

[jgm]

I understand the comment. But I'm hesitant to make the change you suggest. It's good for the syntax of attributes to be fairly tightly controlled, so that people don't accidentally trigger attributes. In addition, it's possible that in the future we might make "bare words" significant (e.g. as flags or as something else, there's an issue for this somewhere). In principle, that might be compatible with allowing spaces around =. But I'm hesitant.

[cscheid]

Thanks for the response. I understand where you're coming from too. I suspected this would be your answer, but I wanted to check before doing an upstream fix on our side.

For what's worth, this would be a non-issue for us if there were a strict mode in Pandoc where the spaces caused a genuine syntax error. (I know that's a much bigger project, and this isn't a feature request!)

Nevertheless, it's the emitting of an AST that is plainly unintended by the authors that causes real user harm for us. The unintended output is not always easy to spot at the time the mistake is made, and noticing it during (eg) a public presentation feels quite bad for the user.

[jgm]

Don't you have this issue with many other things in Markdown, where the proper syntax must be learned? E.g. #Heading with no space, * emphasis with space *, [link with space] (url).

[cscheid]

In a sense, yes: those are sources of pain, and a strict mode could address some of it as well.

Although I have no evidence for the following, my suspicion is that the instances you pointed out tend to be easier to spot because they affect the prose output, rather than the structure around the prose. The fenced div and its attributes are never intended to produce text output, so users don't look to see if they accidentally do.

(Again, all I have are suspicions from observing 200 or so people write Markdown in our workshops over a few years, and that's not evidence.)

[cscheid]

Here's another user reporting the same class of issue, but with spans instead of divs: quarto-dev/quarto-cli#10924 (reply in thread)