Metadata in documents


#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.


#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).