Unclosed selfClosing tag vacuums everything after it in the page about markdoc HOT 4 CLOSED

This is as designed — a self-closing tag needs to have a forward slash (similar to XML) in order to explicitly indicate that it is self-closing: {% partial file="" /%}. Without the slash, the parser assumes that it is an opening tag, so nesting the subsequent content as children is expected behavior.

The parser itself does not have access to the schema and does not know which tags are supposed to be self-closing. Parsing behavior in Markdoc is deterministic and based solely on the syntax, so self-closing tags need to be syntactically distinct from opening tags.

Note that Markdoc validation will typically catch this and tell you, but I'm not sure why it doesn't in the sandbox:

from markdoc.

I just want to chime in to say I'm disappointed in this resolution.

At a minimum, the error handling should be better, to identify and report the syntax error. But, realistically, it feels like a huge missed opportunity to have a schema where you define which tags are self-closing and which aren't if you don't actually use that data to inform parsing.

I'm old enough to remember the failed attempt to migrate the web to XHTML, which failed because, realistically, people make flawed documents and an HTML parser that produces what they probably wanted most of the time is more desirable than a parser that throws up its hands in failure at the slightest imperfection. The type of authors you should expect to be writing Markdoc are, I would expect, on average even less technically-minded than web developers, so it makes sense to me that you would want the parser to be as forgiving as HTML. Ordinary Markdown, for all its quirks, is generally pretty forgiving and intuitive, so pitfalls like this are a big step away from what made it catch on.

The problem is pretty obvious if it occurs at the beginning of a page, but it can be a lot more mysterious if you have one unclosed tag 3/4 of the way through a multi-page document with a bunch of stuff. To make matters worse, the syntax for variables looks exactly like an unclosed tag, which makes it even easier to make these mistakes by accident and harder to spot them after the fact.

Ultimately it's not my project so you can do things how you like, but perhaps you might reconsider this point given the additional context I've provided.

from markdoc.

At a minimum, the error handling should be better, to identify and report the syntax error.

It is reported during validation when the schema is provided. Is there something else we could be doing to report it more effectively?

it makes sense to me that you would want the parser to be as forgiving as HTML

For our purposes at Stripe, we really favor things being more explicit and less ambiguous. There are also cases where a user may want a single tag to be usable as either self-closing or not depending on context, and having explicit syntax enables that.

We have noticed, however, that there are cases where people forget the forward slash. I'm open to reconsidering the syntax and coming up with a cleaner way of expressing a self-closing tag. I think we still ultimately want it to be explicit so that the schema doesn't have to be present during parsing, though.

For your case, you could probably implement a pre-transform pass that programmatically mutates the AST so that self-closing tags that were written as opening tags still work as expected.

from markdoc.

At a minimum, the error handling should be better, to identify and report the syntax error.

It is reported during validation when the schema is provided. Is there something else we could be doing to report it more effectively?

For starters, the sandbox could show some kind of error.

For our purposes at Stripe, we really favor things being more explicit and less ambiguous... I think we still ultimately want it to be explicit so that the schema doesn't have to be present during parsing, though.

Well, even without the schema, shouldn't an open tag without a corresponding close tag be a syntax error? I'm surprised that the example parses without error.

from markdoc.