マルチソースリサーチテンプレートの実行が、投資商品についての良いレポートを作成し、それを不出来な形で印刷してしまいました。[^1]という形の九十五個のマーカーが本文の中にあり、[^1]:という形の九行が下に積み重なっていました。ウェブでもスマホでも同じでした。
原因は、脚注がMarkdownの一部ではないということです。それは拡張機能であり、私たちが提供する二つのMarkdownエンジン――一つはウェブ用、もう一つはモバイル用――のどちらもそれを実装していませんでした。私たちはモデルにまさにこの形式を要求し、それをそのまま文字通りのテキストとして表示していたのです。
一つの書き換え機、二つのエンジン
両方のレンダラーに同じ拡張機能を教える代わりに、どちらもそれを目にする前にマーカーが書き換えられ、両方がすでに同じように表示できる単純なリンクになります。定義は抽出されて別途返され、その後に続いていたものは文書の末尾として残ります。角括弧はリンクテキストの中に残るため、積み重なった引用は「12」ではなく「[1][2]」と読めます。
ウェブでは引用は上付き文字として描かれ、定義は本物のアンカー付きのリストとして表示され、一つをクリックするとそこへスクロールして行が点滅し、リストの番号は最初に引用された場所へジャンプして戻ります。ホバーすると移動せずに定義が表示されます。スマホでは同じマーカーがアクセントカラーで描かれ、一つをタップするとパネルが対応する行までスクロールします。引用ではないリンクは以前と同じようにブラウザで開かれます。
レポート下部のソースカードは一度も影響を受けませんでした。それらは別の場所から来ており、常に問題ありませんでした。
ダウンロードでも同じ
.docx、.pdf、.mdとしてダウンロードするレポートは別のコンバーターを通っており、生のマーカーを文書に直接印字していました。文書仕様には上付き文字がないため、引用は「[3]」として印字され、各定義は「[3]」で始まる独自の行を開きます。インデントされた継続行はその定義に結合されます。ファイル内の番号は画面上の番号と同じです。
最初の試みは、すでに対策を持っていたはずの方法で間違っていた
最初のバージョンは脚注番号を単純なフラグメントリンクにしていました。「href="#fn-3"」です。単一ページアプリケーションに必要な「<base href="/">」の下では、裸のフラグメントはサイトのルートに対して解決されるため、リンクはホームページを指してしまいます。クリックハンドラーがナビゲーションをキャンセルしていたため動作していました。誰かがそのハンドラーに触れるまでは動作し続けたでしょう。
まさにこのパターンのためにすでに用意していたチェックが、プッシュ前のローカル実行で赤になりました。番号は今ボタンです。スクロールし、フォーカスを移動し、読者の動きを減らす設定を尊重します。