全知検索演算子についての検討（1歩），交度埋め込み記法の実装方針検討と数式記法も含めた概念整理（5歩），知名デラングの対応方針についての検討（7歩），交度記法で対応言語スクリプトを動的に追加する方法についての検討（12歩）など，検討作業がよく捗った。

実作業も，交度写し取りボタン実装（13歩〜16歩），交度埋め込み記法調整などそこそこ捗ったが，特に大きかったのは，交度埋め込み記法と数式記法の概念整理が出来たことだった。

交度埋め込み記法と数式記法の概念整理

交度埋め込み記法では，対応言語に tex，latex，katex を追加した。これまで katex のみを追加するつもりだったが，意図の明示という観点から使い分けられる方が望ましい。例えば，KaTeX という実装にこだわらず LaTeX を書きたいということは十分に考えられる。

また，これまでは数式記法も KaTeX 交度埋め込み記法の糖衣構文程度に考えていたが，ここで「数式のための TeX 風記法」と位置付け直すことにした。これにより，例えば mhchem などの数式以外の応用は交度埋め込み記法を使うといった使い分けが可能になる。

Mermaid 対応以後，交度埋め込み記法で KaTeX に対応する機会を窺っていた。これは同記法を考案した時点で考えていたこと（希哲16年2月15日18歩）で，いずれ対応するつもりではあったが，30分もあれば十分だろうという実装コストの低さにもかかわらず，いまいち気が乗らなかった。

数式記法を糖衣構文として再定義する，それ以上の意義が見出せなかった。整合性という大義名分はあったが，悪い意味での冗長性を加えるような感覚もあり，なんとなくぼんやりした，すっきりしないものを感じていた。

（進捗時限記録中略）

交度記法で対応言語スクリプトを動的に追加する方法についての検討で終了。

ずっと後縁で処理することを考えてきたが，動的更新を考えるといずれにせよ前縁での対応も必要になることに気付いた。前縁・後縁で別々にスクリプトの対応関係を管理することは考えたくない。

後縁では言語名の正規化・変換，前縁ではスクリプトの動的追加と役割分担させることにした。

知名デラングの対応方針についての検討で終了。

知名の役割を誤解させかねない懸念から必要以上の拡充には迷いがあったが，出来るだけ拡充していく方針を決めた。

詳細は文字装飾記法などへの対応後にまとめる。

全知検索演算子についての検討で終了。

昨年10月1日の開発では ?! の導入は保留することにしたが，当初予定通り，?!，!?，?? の3種類を揃えることにした。

少なくとも前縁では全知検索ボタンの切り替えに必要なことに気付いた。11日の開発でこのあたりの実装イメージがまとまったことで気付きやすくなっていた。後縁での実装がどこまで必要かは実装しながら考える。

（進捗時限記録中略）

また新生デライトの要件外だが，閲覧専用模動の実装イメージまで急に固まってしまったのでまとめて終了。

当初は Dex での対応を考えていたが，今日，開発者通類で実験してみたらほとんど CSS で簡単に実装出来ることが分かった。用合いもこれまで少しずつ練ってきたのでほぼ固まっている。

閲覧専用模動実装も新生デライトの当努に加えることにした。

この検討で，輪郭ページの吊るし輪郭が <header> を使っている問題に気付いた。元々後景一覧を利用しているので仕方ないことではあったが，SEO のことも考えると，吊るし輪郭は <header> と <main> を，輪郭一覧は <main> と <aside> を切り替える仕組みも必要になりそうだ。

（進捗時限記録中略）

新生デライトの要件ではなかったが，デライト最初期に実装・削除してからずっと保留状態にあった全知検索窓固定機能の実装イメージが急速に固まったのでまとめて終了。

全知検索窓では，下スクロールで隠れ上スクロールで現れる固定表示を採用することにした。

昨日，寝る前に Android 版 Chrome を触っていて思いついた（上スクロールでツールバーが現れる）。以前にもこの方式を検討した記憶があるが，その時は流してしまった。昨年，新規描出フォーム固定機能とともに大きく検討を進めたことがあった（開発記録）ので，時期的な噛み合わせだろう。

いったん削除した理由，その後復活させられなかった理由は主に二つあった。

一つは，広告との相性の問題だ。AdSense では広告に固定メニューのようなものが被ることもグレーとされている。実際には悪質でなければそこまで厳しく対応されることはないだろうが，広告頼みのデライトではわずかなリスクでも避けたかった。

もう一つは，画面を広く使いたい場合に邪魔になることがあり，必ずしも便利ではなかったことだ。当然，スマートフォンのような小型端末ではこの問題が顕著になる。

昨年の検討では，広告に近付いたら隠すようにすることと，表示領域の高さが十分ではない場合は固定機能を無効にすることでこれらの問題を回避する方針を固め，復活に向けて一歩前進した。しかし，実装と調整の煩雑さに対して必要性が高まらず，ここまで実作業に至らなかった。

今回採用を決めた方式なら，調整の手間はほとんどかからず，交度も半分くらいで済みそうだ。無くてもそこまで困らない機能ではあるが，これくらい実装コストが下がれば優先順位も上げられる。

埋め込み YouTube 動画のレスポンシブ化についての検討で終了。