(6)(102){希哲16年9月30日の開発}{採用理由}{採用前}{採用した}{希哲16年4月5日の開発}{希哲16年4月5日14歩}{舞覧五年対応原則}{デラング}{希哲16年2月15日10歩}{希哲16年2月9日15歩}...(59)なんとか全知検索演算子 !? を実装した。作業は円滑，懸念していた速度低下の問題も無く，大成功だった。
全文検索索引の作成には予定通り pg_bigm を採用した。想像していたよりずっと軽量で，導入しやすかった。切り替えも容易なので，非標準機能への依存を極力避けるという方針からいっても許容範囲内だろう。
一番懸念していたのは速度低下，特に描出時の索引更新にかかる負荷だったが，体感速度への悪影響は見られなかった。全文検索時に検索語によっては微かな引っかかりを感じる程度で，許容範囲内といえる。これは嬉しい結果だった。
全文検索機能はデルン初期実装にはあったものだが，正規一致への移行過程で「退行」していた（全知検索を正規一致方式に変更）。理想的な形で復活させることが出来て感慨深かった。
(9)(208)CSS 変数（カスタムプロパティ）の導入と舞覧五年対応原則の採用を決めて終了。今後デライトでは，「5年以内に離立された版存の主要舞覧」を中心に対応していく。
希哲15年3月1日の開発から「デライト推奨動作環境」として同様の定義を考えてはいたが，当時は，古い舞覧対応の努力はするが推奨はしない程度の，もっと緩やかなものを想定していた。
希哲13年に ECMAScript 2015，HTML5，CSS3 と比較的新しいウェブ標準の導入を決めてからだいぶモダンにはなったが，まだデライトの舞覧対応方針には感覚的で保守的なところがあった。感覚的に，影響範囲の広い付徴は主要舞覧の対応から10年，影響範囲の狭い付徴は5年を目安に導入を考えていた。rem ですら必要以上には使わなかった。
先日，前次記法実装でグリッド領当てを導入したが，これはちょうど主要舞覧で使えるようになってから5年ほど経つ機能だった。一記法の装体に過ぎなかったこともあり，ここまでは辛うじて良かったが，他にも色々応用したいことが出てきて舞覧対応方針見直しの必要を感じていた。
決め手は，デライトのダークテーマ対応も見据えて CSS 変数の導入を考え始めたことだった。CSS 変数も主要舞覧の対応から5年ほど経つが，本格的に導入するとなると影響範囲が広がり過ぎる。
Can I use で対応舞覧をよく調べるようになってから，「5年以内に離立された版存の主要舞覧」が意外に普及していることに気付いた。大体90％以上はある。
地域にもよるだろうが，確かに，今時古い舞覧を使い続ける方が難しいかもしれない。個人機なら5年は平均的な買い替え周期であり，スマートフォンなら古い部類だろう。自動更新も標準的になった。昔と違って，多数派の“普通の人”ほど新しい舞覧を使っている。
あえて古い舞覧を使い続ける場合というと，一昔前なら古い個人機の再利用というのがあったが，格安インターネット端末が普通に流通している今，新しい舞覧が使えないほど古い端末を使い続ける費用対効果は疑わしく，制危も考えれば推奨出来ることではない。
一番面倒なのが舞覧の更新が許されない企業内利用だが，そもそもそんな保守的な環境でデライトが利用出来るとは考えにくい。
こう考えていくと，デライトにとって古い舞覧への対応の重要性は極めて低いと言わざるをえない。
奇しくも，新生デライトの完成を目指している6月の15日に，IE11 のサポート終了がある。中途半端な気もする内容だが，いわゆるモダンではない舞覧最後の砦が崩壊する。新しいウェブ標準への社会的移行の象徴的な出来事にはなる。
ある程度古い舞覧への対応を考慮してきたのは，企業体力がついた将来，対応を拡充することを考えていたからだったが，これもよく考えると合理性が怪しい。
“技術的負債”は簡単に金で返せるものではない。大企業が肥大化した交度にいかに苦しめられているかを考えれば，合理的に古い舞覧への対応が出来る日が来るかどうかも分からない。むしろ，組織が大きくなった時にこそ見通しの良さが重要になる。
もっと根本的なことを言えば，デライトはウェブ標準という盤本の“キラーアプリ”になるべきものだ。新しいウェブ標準の普及を牽引していくくらいの考えがなくてはいけない。
その伝証の足掛かりがすでにこれだけ普及していれば十分過ぎるだろう。
舞覧五年対応原則の導入によって，ウェブの理想と現実における汚い現実の大部分だった古い舞覧を正しく切り捨てることが出来るようになり，前縁整備はもちろん，デライト文書整備でも大きな効率化がもたらされるだろう。文書整備では，対応舞覧についてどう説明していくかが一つの課題だった。ここまで絞り込めば説明もすっきりする。
デライト開発を劇的に合理化した描出公開原則とともに「デライト二大原則」と呼ぶべきかもしれない。思えば描出公開原則もデライト正式離立という大きな節目を目前にして生み出したものだった。
(27)(248)昨日，寝る直前にまた脳爆発があり，今朝にかけて文字装飾記法とタグ記法周りの概念整理・仕様整理が急速に進んだ。
文字装飾記法は，「文字装飾を伴う慣用表現」のための記法と位置付けることにした。太字記法（##），斜体記法（//），下線記法（__），打ち消し線記法（~~，翌日のまとめで「打ち消し記法」から改称）の4記法を基本とし，それぞれ所定装体を伴う <b>，<i>，<u>，<s> HTML 要素に対応する。
@ を使った文字サイズ記法，% を使った色記法も検討していたが，タグ記法の概念が出来たことで中途半端なものになるため，これは廃案とする。
実装自体は容易な部類で，記法も概ね固まっていたにもかかわらず文字装飾記法の実装に踏み切れなかった理由として意味論的な問題があり，これが思いのほか難題だった。実装方針は3通り考えられる。
記法の趣旨からしても，軽量標記言語の特性を考えても，1つ目に無理があるのは明らかだ。対応する HTML の <b>，<i>，<u>，<s> は，私が何度解説を読んでもややこしく感じる代物だ。それを多くの人が正しく理解して使うのは不可能だろう。そもそも「文字装飾記法」という分かりやすい説明体系を捨てることになるが，代替案があるわけでもない。
かといって，2つ目ももったいない。要は <span> で装体指定だけにするということだが，例えば，太字にはしたいが <b> にはしたくない場合，打ち消し線は引きたいが <s> にはしたくない場合がどれだけあるのかと考えると，無難を通り越して臆病過ぎる。失う可接性や応用可能性と釣り合わない。
最終的に採用することになった3つ目も，全く考えなかったわけではないが，柔軟性に欠け，前の2つの悪い所が組み合わされる気もして，有力案にはなっていなかった。
この膠着状態を変えたのは，前日に概念としてまとまったばかりのタグ記法だった。
これまで，デラングにおける HTML は，どうしてもデラングで出来ない表現をしたい場合などの“抜け道”とか“救済措置”に近い位置付けで，積極的に使うことを想定していなかった。実際，個人的にはほとんど使っておらず，放置している不具合も多い部分だった。
デラングのタグ記法として間接的に HTML を使うことで，略記法の導入も可能になり，HTML 側の仕様変更に対しても一定の緩衝帯を設けることが出来る。ここに来て初めて，文字装飾記法でも「書き分け」が考えられるようになった。文字装飾記法に対応しうるのが全て1文字要素だったことも幸いした。
昨日の寝る直前に，##太字的な表現## と <{font-weight:bold}>太字</> のように書き分けるよりも，##太字## と <b>太字的な表現</b> のように書き分ける方がマシであることに気付いて，1つ目の実装方針案は完全に潰せた。
これにより一時的に2つ目の実装方針案が再浮上したが，標準的に使う記法として標準的な用途に最適化不足なのはやはり否めなかった。
最終的に，「文字装飾を伴う慣用表現」という用者が自然に理解出来る範囲での意味論的な位置付けを与え，逸脱する用途ならタグ記法で書き分けるのが使用頻度に対して最適だろうという結論に達した。3つ目の実装方針案を洗練させた格好になる。
例えば，##太字## は「太字装体の <b>」に対応する。装体が邪魔なら <b>太字的な表現</b> と書けるし，意味が邪魔なら <{font-weight:bold}>太字</>（略記法は検討段階）のように書けるが，これらの場合が稀少なのは明らかで，記述量に上手く釣り合う。ワープロならともかく，軽量標記言語を手書きしようという人にとって難しい使い分けではないだろう。
そもそも，<b>，<i>，<u>，<s> は，古くからある視覚的要素が HTML5 で慣用的な用途を引き継いで意味論化されたものなので，「文字装飾を伴う慣用表現」と非常に相性が良い。相互変換にも全く問題ない。
何より，直感的に入力すれば構造的に出力されるというデラングの理想に適っている。
文字装飾記法を「文字装飾を伴う慣用表現」と位置付けたことで，慣用表現を持たない文字サイズ記法・色記法は仲間外れになるが，タグ記法によって出る幕がなくなった感があるので，ここで廃案にすることとした。
第一に，タグ記法で略記法を整備した方が一貫性も応用可能性も高い。特定の値でプロパティを省略出来るようにし，<{white}>白い文字</> のように書ければ，%white%白い文字%% と書くのと記述量も大差ない。
もともとパラメーターを必要とする記法の異質感はあり，文字装飾記法の統一感を損うかという懸念はあったので丁度良かった。
これまで，複数の文字装飾記法の組み合わせは #/太字と斜体/# のように，「記号を1つずつ逆さにした終了記号と挟む」といったややこしい説明を考えていたが，##//太字と斜体//## のような「入れ子」を #/太字と斜体/# と短縮出来るという考え方にした方が分かりやすいため改めることにした。
今回の検討で，タグ記法が早くも実践的な役割を持つことになり，デラングにおける存在感が一気に増した。
タグ記法に HTML の仕様変更に対する緩衝的な役割を持たせること，要素名の省略で <span> にすることを考え始めた。
(122)見出しは段落よりも横幅を両端0.5remずつ広げ，区切り線（<hr>）は段落よりも0.5remずつ狭めることにした（見出しと区切り線装体・幅調整後）。
当初，見出しの下線と区切り線を見分けやすくするために，区切り線の両端を1emずつ狭める形にしかけたが，試しに出振るいしてみたこの形が想像以上にしっくり来たので，基本方針として採用してしまうことにした。
段落に対して僅かに字上げするような見出し装体は昔から気に入っていて，現状でも「はじめに」などのデライト文書の <h2> は1em，<h3> は0.5em字上げされている（長らく更新していないため描写内見出しとは全体的に乖離している）。月庭でどうしていたか忘れたが，特に理由がなければ似たような装体を採用していたはずだ。
やはり，見出しが直感的に把握しやすいのが大きな利点だが，描写内見出しに採用出来なかった理由として，無駄な余白が生じやすいという領当て上の問題が大きかった。特に，諸場対応から強く意識するようになった幅狭領当てでは小さくない問題だった。
今回の実験で意外だったのは，全ての描写内見出しを0.5remずらすだけでも十分な視覚効果が得られたことだった。これなら，他の装体はそのままに，見出し装体のマージンを削るだけで一応実現出来る。
そのうち領当て上の問題が起きたとしても，幅狭領当てでは0.25emにするとか区切り線だけ調整するとか，調整のやりようはいくらでもあるので，基本方針としては問題ないだろう。
これだけ見出しが分かりやすくなれば，区切り線を短くする必要はないかとも考えたが，これはこれであった方がメリハリが付いて良い。従来の（他要素と同じ）長さだと，やはり直感的に区切りの大きさが把握しにくい。
新装体なら，見出しと見比べるまでもなく，見出し未満の小さな区切りであることが分かる。
昨日は眠気が強い時間帯に思い付いたのでこの新装体の良さに確信が持てなかったが，認知機能が低下している時に分かりやすいと思ったのだから，分かりやすさに関しても間違いないだろう。
