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 のサポート終了がある。中途半端な気もする内容だが，いわゆるモダンではない舞覧最後の砦が崩壊する。新しいウェブ標準への社会的移行の象徴的な出来事にはなる。

ある程度古い舞覧への対応を考慮してきたのは，企業体力がついた将来，対応を拡充することを考えていたからだったが，これもよく考えると合理性が怪しい。

“技術的負債”は簡単に金で返せるものではない。大企業が肥大化した交度にいかに苦しめられているかを考えれば，合理的に古い舞覧への対応が出来る日が来るかどうかも分からない。むしろ，組織が大きくなった時にこそ見通しの良さが重要になる。

もっと根本的なことを言えば，デライトはウェブ標準という盤本の“キラーアプリ”になるべきものだ。新しいウェブ標準の普及を牽引していくくらいの考えがなくてはいけない。

その伝証（デモ）の足掛かりがすでにこれだけ普及していれば十分過ぎるだろう。

舞覧五年対応原則の導入によって，ウェブの理想と現実における汚い現実の大部分だった古い舞覧を正しく切り捨てることが出来るようになり，前縁整備はもちろん，デライト文書整備でも大きな効率化がもたらされるだろう。文書整備では，対応舞覧についてどう説明していくかが一つの課題だった。ここまで絞り込めば説明もすっきりする。

デライト開発を劇的に合理化した描出公開原則とともに「デライト二大原則」と呼ぶべきかもしれない。思えば描出公開原則もデライト正式離立という大きな節目を目前にして生み出したものだった。

（進捗時限記録中略）

昨日，寝る直前にまた脳爆発があり，今朝にかけて文字装飾記法とタグ記法周りの概念整理・仕様整理が急速に進んだ。

文字装飾記法は，「文字装飾を伴う慣用表現」のための記法と位置付けることにした。太字記法（##），斜体記法（//），下線記法（__），打ち消し線記法（~~，翌日のまとめで「打ち消し記法」から改称）の4記法を基本とし，それぞれ所定装体（スタイル）を伴う <b>，<i>，<u>，<s> HTML 要素に対応する。

@ を使った文字サイズ記法，% を使った色記法も検討していたが，タグ記法の概念が出来たことで中途半端なものになるため，これは廃案とする。

文字装飾記法はこれがほぼ完成形か。

検討過程

3つの検討方針

実装自体は容易な部類で，記法も概ね固まっていたにもかかわらず文字装飾記法の実装に踏み切れなかった理由として意味論的な問題があり，これが思いのほか難題だった。実装方針は3通り考えられる。

1. 完全に意味論的な記法にする
2. 完全に装飾的な記法にする
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> にすることを考え始めた。

（進捗時限記録中略）

<dl> に対応する「語釈記法」（仮称）についての検討で終了。

まずは，AsciiDoc の複数行ラベル記法を取り入れることにした。

以前から B̅ 氏が使っていたことで AsciiDoc 風記法の導入を考えるようになったが，末尾の :: は名称空間の知符として多用していたため，語句:: 定義 の単一行ラベル記法を導入するとおかしくなる輪郭がいくらかあるという問題があった。

ただ，最近この手の文字列は交度記法の利用で統一すべきという考えでまとまっているため，移行作業の問題はあるものの仕様として導入することに問題はなくなった。そこで，すぐに取り入れても問題なさそうな複数行ラベル記法から取り入れ，どう拡張するかは追い追い考えていくことにした。

記法名は仮に「語釈記法」とした。HTML5 で <dl> は〈definition list〉から〈description list〉に意味合いが変わっているが，語句に対する説明という大まかな意味には適っている。

AsciiDoc のラベル記法はもっと汎用的に使えるものらしいが，デライトが重視すべき HTML では意味付けも重要なので，とりあえず <dl> の用途に寄せておく。

他に，Markdown Extra などで採用されている行頭 : の記法も検討した。記法として悪くはないが，普及状況もいまいちで，優先的に採用するには決め手に欠ける。

https://html.spec.whatwg.org/

希哲館における珍奇な語彙といえば「日本語史上最大の翻訳語体系」こと希哲館訳語ばかりが注目されがちだが，実は，もう一つそれに負けず劣らず珍奇な言語関連望事（プロジェクト）がある。それが「交度英語」（Code English），略して「交語」（Codish）だ。

これは主に希哲館情報技術体系で利用しているもので，簡単に言えば，「英語を勘報機（コンピューター）向けに簡略化した人工言語」だ。

勘報（コンピューティング）の世界では，技術者であれば誰でも理解出来るような略語というものが多数存在する。例えば，std は〈standard〉，int は〈integer〉，str は〈string〉……といった具合だ。多くは「歴史的経緯」で定着したものだ。

一方で，こうした略語の使用を避けるという文化も優勢になっている。その主な理由は，「共有しにくい」からだ。特に新しい論組（プログラミング）言語では，英語を略さずに使う傾向があるため，妙に冗長な交度（コード）が増えた。

はっきり言おう。私は，これが非常に馬鹿げた考え方，いわば「略さない病」であると思っている。この病気によって世界から失われた効率性を金額に換算すれば天文学的なものになるに違いない。

よく考えてもみてほしい。略語というのは，どんな専門分野でも記録や情報交換の効率化のために自然発生するものだ。数学の一見意味不明な略語・記法は，数学者が本質的な仕事に専念するために編み出したものだろう。日夜神経を磨り減らして交度と向き合う情報技術者がそれを封じるのは，狂気の沙汰と言ってもいい。

実際のところ，「略語を使わない」ルールが徹底されているかというと，そうではない。例えば，String str; なんて記述は世の中に溢れかえっている。C++ には shared_ptr（pointer），Java には println()（line）なんてものがある。「モダン」なはずの HTML5 にも img（image）やら kbd（keyboard）やら残っている。こうした混在が当たり前になっているのが現状だ。なぜなら，「略語を使わない」というのは本来不自然なこと，無理のあることだからだ。

長い方に合わせるのは無理なのだから，短い方に合わせればいい。共有しにくいなら，「略語を使わない」のではなく，「略語の辞書を作る」ことを考えればいい。頻繁に使うものなら人間は慣れる。これがつまり，交度英語の考え方だ。

交度英語では，すでに定着している英略語を基礎に，実践を通じて新しい略語を提案，問題があれば修正しながら語彙を作り上げていく。

具体的には，論組をしながら，どう略せばいいのか分からない英単語にあたった時，私はまず適当に略してみて，それをデライトで検索する。他に前例があればそれと突き合わせて修正することもあるし，無ければどういう意図で使ったかを描き出していく。これを繰り返すことで，デライトが自然と辞書の役割を果し，妥当な略語の使い方に導いてくれるようになる。

これは基本的に希哲館訳語で行っていることと同じであり，デルン／デライトがはじめて可能にしたことでもあるのだろう。

希哲館ではまだ素交（ソースコード）の公開などはしていないので，交度英語を使った交度の実例としてすぐに見せられるものは少ないが，最近書いた「JavaScript の beforebegin，afterbegin，beforeend，afterend に代わる要素位置記法」などにはその片鱗が見えるかもしれない。

いずれ『希哲辞典』のように辞典として整えて公開することも考えているが，まずは考え方を紹介しておきたかった。

デライト文書構造最適化の SEO 向けの作業は一段落した。

長いこと SEO に関しては放置状態に近かったが，HTML5 と Schema.org を活用してそれなりの形にはなった。 SEE にとっても大きな進歩だ。機会損失の最小化を考えると出来るだけ早く済ませておきたかったので割とあっさり終わって良かった。

これからの文書構造最適化は中景輪符整理など領当てや保守性の観点から必要な作業中心になるだろう。

SEO に加え第三次宣伝攻勢も始まればデライト高速化も急ぐ必要があるが，CDN に関してはやはり依存を避けつつ，体系的に上手く利用出来るようにしておきたい。

この体系を KNEST の一環として「KDN」（knowledge delivery network）と呼んでおくことにした。

主に KNEST 隠し実装検討，自我ページ仕様検討，HTML5 の復習をしつつデライトの文書構造見直し。

KNEST 隠しに関しては，処理途中の HTML::tpl_I 客体で状態により細部の異なるページを持たせる手法を考えたが，どのみち最終処理は全ての変数が揃わなければ出来ず，ページ毎に変数の複製が出来てしまうことを考えると効率性は期待出来ないか。

自我ページに関しては，より SNS 寄りにヘッダー画像や bio くらいは設定出来るようにしてもいいかと考えたが，領当てが意外に難しい。