Parsing additional info string as meta data on <pre> tags

[no-itsbackpack]

@mikekavouras and I have been playing around with a concept of parsing additional information from the info string and attaching it as meta data on the <pre> tags.

Input

\```diff something

Output

<pre lang="diff" data-meta="something">

We want to open up the conversation on two aspects of this feature:

1. Parsing the meta data
   a. Do we parse everything after the info string?
   b. Do we parse just the second element after the info string?
   c. Do we parse against a predefined pattern. (```ruby [meta])

2. Exposing the data to the client
   a. Do we store the parsed meta in a valid <pre> attribute (eg. <pre lang="diff" title="[meta]">)
   b. Do we set a data attribute on the <pre> tag (eg. <pre lang="diff" data-meta="[meta]">)

Our Proposal

We vote for 1a and 2b but we are totally open to any other ideas or suggestions. We figured it would beneficial to provide the client with everything after the info string but we also realize they could be a chance of abusing this implementation. eg. \```ruby jump go never do this.

\cc @kivikakk @gjtorikian

[pathawks]

FWIW The CommonMark spec does not seem to say much about the info string, leaving open the possibility of doing something like this 👍

https://spec.commonmark.org/0.28/#info-string

[gjtorikian]

I like 1c, 2b. So parse everything into data iff it is prefixed with data-:

``` ruby data-blah=“wah” data-foo=‘bar’ data-meow=cat not-getting-added

 
  ```

It doesn’t have to be like that, but I like that there’s no additional thinking. You can look at the fence and see that those will just be applied as straight elements delimited by double quotes, quotes, or nothing (which I think is valid? people who write HTML attributes like this are monsters).

As for abuse—putting an upper cap of like five or something would be good, I think. I’d rather start low and then go high if needed.

I worried that this change would break spec compliance, but according to the spec:

The first word of the info string is typically used to specify the language of the code sample, and rendered in the class attribute of the code tag. However, this spec does not mandate any particular treatment of the info string.

So that’s great news. 🎉

[kivikakk]

This change will likely need to be made in cmark-gfm — a solution implemented in commonmarker would involve switching to a HtmlRenderer, which is going to be many times slower in rendering.

I like 1a, 2b — I'd be worried about letting the users add arbitrary data- attributes to elements, seeing as a lot of JavaScript triggers on data- attributes and this could potentially let users mess with things. It'd also imply a lot more parsing of the info string than I think we want to do.

I'd instead be inclined to just drop the entire remainder of the info string into data-info-string or something possibly more "vendor specific" (data-cmark-info-string) seeing as this is totally out of spec and almost always going to be consumed by someone reparsing the output HTML or otherwise inspecting the DOM. This also side-steps the abuse issue entirely, as far as I can see. (Please correct me if I'm missing something.)