GitHub Flavored Markdown は何であって何でないか - Qiita

のんびりしていたらこんなメンションをもらっていたので、ちょっとまとめてみようと思います。 そろそろ @tk0miya さんがアップしてくる頃。GFMはspecかっちりしてるんでしたっけ(markdown全く詳しくない — Aki Ariga (@chezou) February 1, 2020 かっちりしている? この記事を読んでいる皆さんは Markdown の歴史に精通していると思うので、古い部分はざっくり割愛してしまいますが、オリジナルの Markdown は かっちりしていない ことで有名なマークアップ言語です。 必要最低限のマークアップ要素は規定されていて HTML への変換ツールも完成していた Markdown ですが、マークアップ言語の言語仕様としては貧弱で、インデントのルールやインライン要素をネストしたときの挙動、空行の有無による解釈の違い、などなど、細かい部分のルールにつ

[amagitakayosi]

😇 “みんなが使っているのは GitHub.com Flavored GFM であって GFM ではない ”

[mapk0y]

github.com の GFM の改行って soft line breaks じゃなかったっけ？pull request や issue では利便性のためか hard line breaks だけど、レポジトリ内の markdown は soft line breaks になってると思う

[yarumato]

“Markdown初期は細かい挙動は未定義。移植時に独自解釈を生んだ。CommonMarkは解釈の余地を減らし異常系のサンプル多。GFMは定義あるがCommonMarkと矛盾箇所もあり、異常系定義が曖昧で、github.com挙動とも違う”

[dh16t]

一体いつから ”GitHub.com Flavored GFM” を遣っていないと錯覚していた？

[vanbraam]

Markdownのそもそもの思想が「renderされなくてもそれなりに読める」なので,最近の空行を入れない事を許すMarkdownには反対. GFMはde facto standardなので,その辺はきっちりして欲しい

[braitom]

ほう。“みんなが使っているのは GitHub.com Flavored GFM であって GFM ではない”

[smbd]

なるほどなぁ

[b-wind]

“なんとか統一変換ルールを作らねば、と立ち上がったのが CommonMark プロジェクトのひとたちでした。彼らはさまざまな荒波を乗り越えながら Markdown の各要素をどのように解釈するとよいのかを仕様書に取りまとめたので

[akabekobeko]

いま Vivliostyle で策定中の VFM https://github.com/vivliostyle/vfm 参考意見としてブクマ。

[marmot1123]

そ、そうだったのか……

[raimon49]

github.com上での挙動がGFM specから外れているという話。

[shifumin]

“みんなが使っているのは GitHub.com Flavored GFM であって GFM ではない”

[kfujieda]

GFMの仕様がCommonMarkを元に定義されたが、仕様に矛盾があったり仕様にない記法がgithub.comで使えたりするという救いがない話。

[teppeis]

「みんなが使っているのは GitHub.com Flavored GFM であって GFM ではない」

[gfx]

CommonMarkの拡張部分がこんなにゆるかったのは知らなかった。github/libcmark-gfmの挙動を文章としてざっくり抜き出した、くらいの感じなのかな。