（進捗時限記録中略）

動的引連 SVG アイコン実装。

途中で終了。

装体調整中，ダークテーマの共有小窓で <iframe> の背景色が白くなってしまっている問題に気付いた。color-scheme: dark の記述を外すとなぜか直る謎の現象だが，舞覧のバグにしては Firefox でも Safari でも Chrome でも再現する。現象自体は共有小窓以外でも起こっている。少し前から埋め込みツイートの角が白くなる現象が気になっていたが，同じ原因らしい。color-scheme は4月1日9歩で導入したが，すでにダークテーマの常用をやめていたので気付かなかった。

いまいち納得出来ないが，とりあえずダークテーマ時の <iframe> に color-scheme: normal を設定することで凌ぐことにした。

もしかしたら，ダークモードでは黒文字が黒背景に溶け込まないように透過背景を白背景にしているのかもしれない。

未出振るい。

動的引連 SVG アイコン実装。

途中で終了。

SVG スプライトを background-image などでも利用出来るようにする実装について考えていたが，ここは割り切って，原則，SVG アイコンは引連 SVG としてのみ扱う方針を決めた。

実装上の都合で background-image を使っているだけのアイコンは別として，現状，背景とアイコンの二つの役割を持たせている二輪鎖を念頭に置いた検討だったが，背景としての二輪鎖も特定要素の端っこに置いているだけなので，一番楽な方法ではあるが background-image を使う必要は無い。

<view> の舞覧対応状況に不安があることはさておき，フラグメント識別子を付けると多重立求が発生する舞覧があることがどうしても気になる（手元の Linux 版 Firefox でも発生する）。background-image を使いたいのが二輪鎖だけだったのでまだ問題は小さいが，SVG スプライトが十分に軽量でフラグメント識別子での参照が十分に少ないという状況でしか効率的ではない手法は範枠化出来ない。

スクリプトで補完した要素に background-image を設定することも検討したが，そうすると実装コストが動的引連 SVG と変わらない上に，より柔軟性の低い参照方法でしかなくなる。

結局，アイコンはアイコンらしく，要素と一対一で扱うものと割り切った方が何かとすっきりする。

（進捗時限記録中略）

動的引連 SVG アイコン実装。

途中で終了。

<view> は使えないこともなさそうなので，試しに使ってみることにした。

Can I use でなぜか <view> の対応状況が不明になっている舞覧（主に Safari）が多かったので避けようとしたが，「SVG fragment identifiers」の方では問題なさそうな数字になっており，いまいち実態が分からない。少なくとも手元の Safari では問題なさそうだ。

これが使えると，background-image などで使う場合にだいぶすっきりする。

Chrome 以外でなぜか多重立求が発生する問題はあるようだが，通常は隠しが使われるはずなのでさほど大きな問題ではないか。

（進捗時限記録中略）

動的引連 SVG アイコン実装。

途中で終了。

SVG スプライトの手法を取り入れ，SVG アイコンの定義は icn.svg に集約することにした。

SVG 出与えも Aejs に組み込んで直接挿入してしまうことを考えていたが，舞覧隠しの適切な分離が出来なくなる，要素の再利用に必要な id 属性が使いにくい，といった問題があった。外部 SVG を <use> で利用すれば Shadow DOM になるので，id 属性の衝突などを気にせず要素を整理しやすくなる。

スプライト画像として background-image で利用しやすいというのも大きい。:target とフラグメント識別子を利用して表示要素を変化させる技術があることを知ったが，舞覧によっては効率的に隠し出来ないことがあるらしく，今回は見送った。<view> が使えればいいが，Safari の対応に難がある。当面は古典的な座標指定で行くことにした。

アイコン制作では，アイコンを並べて全体のばら成しを見ながら調整することが多いため，見本を兼ねられるのも便利だ。

SVG スプライトだけで十分かもしれないと思いかけたが，<use> 1つでも若干冗長な上に，1つのアイコンの要素を細かく制御したい場合に <use> が複数必要になるため，やはりスクリプトでの補完は欲しい。

主に CSS アイコン実装。

一つ一つ課題を解決しながら進めているので時間はかかっているが，何かと知見を深めることが出来ている。やはり総合的に CSS アイコンの利点は大きいので採用方針は変わらないが，割り切りと誤魔化しの技術が肝だなと感じている。そこを抑えられれば強力な武器になる。

CSS アイコンの欠点として，拡縮時に歪みやすいということが理解出来てきた。スマートフォンだと再現しないので，サブピクセルのレンダリング問題なのかもしれない。拡大時に1px程度のずれが生じることがあるのはともかく，縮小時に細い線が消えたりもする。これは有名な CSS アイコン集でも同様なので，そういうものなのだろう。

もっとも，ラスター画像の主要な問題である高精細画面でのぼやけに対応出来れば十分とも言える。舞覧のズーム機能を使うような人にとって多少の表示の乱れは想定内だろう。あとは歪みにくい書き方・デザインの問題か。

すぐに終わるだろうという当初想定に反してもう少し時間がかかりそうなので，明日からは別の作業にも多めに時間を割くことにした。

（進捗時限記録中略）

CSS アイコン実装。

途中で終了。

端末・舞覧によっては拡縮時に微妙な歪みが生じるのが気になっていたが，さほど深刻な問題ではないので，良い解決策が見つかるまである程度は割り切ることにした。

（進捗時限記録中略）

デライトにおける νS（JavaScript）渡配（トランスパイル）についての検討などで終了。

しばらく，ES5 への渡配をやめて様子見することにした。備立環境は調整済み。次回の前縁出振るいで本番環境にも反映されるだろう。

希哲13年8月23日の開発以来，νS では ES2015 を基礎にしているが，同時に Babel を導入し，配信スクリプトは ES5 に渡配していた。それから4年近く経ち，デライトの舞覧対応方針は洗練され，ES2015 の対応舞覧も十分な市影を有している。もはや ES5 との互換性を引きずるべきではないと判断した。

とりあえず，--presets 応付子を外して，babel --no-babelrc --minified --no-comments だけで換配するようにしてみると，ae.js の譜類サイズは20kB近く減った。譜類サイズ削減以上に，スクリプトの複雑化に伴うオーバーヘッド増加抑制も期待出来る。

ES2016 以上の交度がうっかり紛れ込む（紛れ込んでいる）可能性を考えると ES2015 への渡配をしておいた方がいいかと思ったが，どうもそういう考え方をする時代でもなく，Browserslist を使った手法が主流らしい。確かに，舞覧の対応状況が非常に流動的なので実態に合わせる方が合理的ではあるが，ブラックボックス化は避けたい。これまで通り，導入付徴の対応状況は個別に把握しておくことにした。デライトの能力が活かせるだろう。

いずれにせよ Babel の設定で後からいくらでも調整出来るので，いったん渡配無しで様子見する。

ついでに，変数名などの短縮などについても再検討したが，やはり外部通類への依存度を高めず保守性を維持するのは難しいため見送った。交度英語のおかげで一定の短縮性は保たれている。