Custom elements not supported

[thomaswilburn]

We use CommonMark as our document parser at the Seattle Times on some special projects, and it has problems recognizing our custom elements when we try to insert them into the document as HTML. For example, this is not recognized:

<responsive-frame src="example.com"></responsive-frame>

A workaround is that we can wrap it in a known HTML element, such as a div, and that will be recognized:

<div>
  <responsive-frame src="example.com"></responsive-frame>
</div>

But this is ugly, and it goes against the point of our custom elements, which is to be more usable for non-technical producers. Can we get the HTML parser to recognize these valid elements as HTML?

[jgm]

Currently the spec hard-codes a list of HTML block elements (and this isn't one, obviously). But, in response to some other issues, I'm thinking of changing the spec to hard-code the elements that can NOT start HTML blocks, instead. That would solve your problem.

[thomaswilburn]

That sounds like a good solution, thanks.

[colinodell]

+1 I like the idea of blacklisting elements instead

[jgm]

See also http://w3c.github.io/webcomponents/spec/custom/

[jgm]

So, here's the plan. Both items need to be implemented in the spec, in the C parser, and in the JS parser.

1. Change from whitelisting elements that can start HTML blocks to blacklisting elements that can't start HTML blocks.
2. Change the scanner for HTML tags to allow interior hyphens.

[puzrin]

How are you going to define, if certain custom tag can or can not start html blocks?

[jgm]

@puzrin, my idea had been that any HTML tag that begins a block, except for a select few designated ones that are used for span-level content, would start an HTML block. But that's a bit crude, as in principle one might define a span-level custom tag and decide to start a paragraph with it.

Of course, one could go to a system where custom tags can be registered as block or inline tags through options to the program or library. I'd rather avoid that, though -- and even with the tags that HTML provides, we face many cases of ambiguity. For example, is <del> at the beginning of a line meant to enclose the entire paragraph (a block) or should it be interpreted as an inline tag inside the paragraph?

I'm very much tempted by the following rule, which is easy to remember and use: to start an HTML block, put a single HTML tag on a line by itself. (The block then continues until...etc.) Thus,

<del>
Content inside block-level tags.
</del>

<del>A paragraph with inline-level tags.</del>

With this rule, we wouldn't need to build in any distinction between block-level and span-level HTML tags.

The main worry here would be about backwards compatibility, since existing Markdown processors don't have this restriction.

An alternative system would use a mix of heuristics, following the current CommonMark spec for known HTML elements, but using the rule above for unknown ones. Aesthetically, this is ugly, but it might achieve more backwards compatibility.

[thomaswilburn]

I could live with that for custom elements, although I also think it'd be okay to just treat custom elements as block level by default, personally.

[jgm]

Discussion here: http://talk.commonmark.org/t/raw-html-blocks-proposals-comments-wanted/983

[jgm]

@thomaswilburn - Note the following.

<responsive-frame src="example.com">
</responsive-frame>

will be treated as a raw HTML block, and reproduced verbatim.

<responsive-frame src="example.com"></responsive-frame>

will be treated as a paragraph with inline HTML tags, and reproduced with <p>...</p> surrounding it.

See the new spec for HTML blocks (still in master, not published) for further details on how this works.

[thomaswilburn]

Awesome, thanks John.