Metadata in documents

Extensions
82

Also to prevent metadata from being rendered, HTML comments can already be used <!-- my metadata here -->. This is more likely to work everywhere, even in non-CommonMark Markdown implementations.

83

Yes it certainly works, but it is not interoperable. newlines handling is already optional per spec but there is no way having the document declare it.

I do understand though that there may be bigger fish to fry and that we can just not have interoprability here.

84

The damper that @jonschlinkert placed on this idea, while understandable regarding data structure, fails to recognize that we’re just looking for “delimiter-ization” for a different portion of the page.

I would guess that nearly every markdown author, at one point or another needs some kind of invisible “meta” area.

Consider the idea that markdown advertises (and why everyone uses it):

Markdown = Simple characters delimit page parts.

In the same way that the # character delimits an H1, we’re just asking for an agreement on (and standardization of) which character(s) delimit:

  1. meta data
  2. no processing
  3. vcard

The problem with YAML is that the “—” is already used for multiple things. And other proposals don’t feel markdown-y enough.

No one complains about the “fencing” idea, so stick with it, and don’t start deviating from existing markdown paradigms.

I propose

  1. meta data - Enclosed by brackets. Allowing multiple metas – or peppering meta data throughout the document. Or it could also be leveraged as a hidden comment-like section.

    Example:

     {{{
 	title : My Page
 	sally: barfed
 	bob: is reversible
 }}}

    Example:

     {{{
 	{
 		"author" : "Patrik Star",
 		"uuid" : 1234566,
 		"whatever" : "you want",
 		"foo" : {
 					"bar" : [1.2, 4.5]
 				}
 	}
 }}}

  2. no processing - (Island) Fenced by exclamation points.

    Example:

     !!!"whatever" : "you want","foo" : "bar"!!!

  3. vcard - fenced by @ symbols, classic key=value pairs.

    Example:

     @@@
 name = bob
 phone = 555-1212
 email = bob@example.com
 @@@

Again, the idea here is just to allow CommonMark to establish the marks used to delimit different kinds of data.

I believe that the solidifying of the spec could be sped up dramatically if we remember to KISS.

2 Likes
85

Note that many provided examples can be solved with the current standard by using JSON-LD:

<script type="application/ld+json">
{ "@context": "http://schema.org",
  "@type": "BlogPosting",
  "headline": "Blogging Like a Hacker",
  "description": "How to blog like a hacker and win at life",
  "datePublished": "2018-05-19T21:11:36Z",
  "keywords": "blogging, hackery" }
</script>

It is in widespread use, well-defined at schema.org, and includes many more fields than the <meta> attribute.

(It is what I do in my blog, and I use that metadata for automated generation of the HTML and RSS feed.)

For other elements, other script types are possible, such as text/yaml.

86

If we adding the following rule to the spec, would this not cover the vast majority of cases?

If the first line of the document begins with a thematic break, treat this as a “do not parse” starting delimiter instead and ignore the subsequent lines until the next thematic break which is treated as a closing delimiter for the “do not parse” section.

This allows custom front matter to be added via a post-processor without it being rendered in the output (of regular CommonMark implementations). Third party implementations can implement the post-processor however they want (and come up with common syntax extensions for their specific use cases).

87

Looks like the full Common Mark spec finally landed in VS Code as of roughly this week. The front matter yaml used to be supported according to @chrisalley’s last message and now it is broken. Hmmmm…

Anyone else notice this?

1 Like