icon

{全てのデライターへ K#F85E/E74C-CA32}
デライトも公開から2年半ほど経ち,色々な人が興味を持ってくれたり,使ってみてくれたりした。遠くから眺めているだけの人,登録してみただけの人,たまに使う人,いつも使っている人……風変わりなデライトでも,出会った人の多様性は他のサービスとさして変わらない。
感謝
私は,そんな全ての“デライター”とデライターの卵達に深く感謝している。付き合いの長さも深さも関係ない。デライトに否定的な人ですら,知ってくれただけでありがたいと思う。
これがよくある社交辞令ではないということは,前回の一日一文,「デライトの歩み」を読めば分かるだろう。そもそも全く無謀な挑戦として始まったのがデライトだ。成功どころか,誰にも認められず終わるかもしれない。それならまだいい。弾圧や暗殺で命を失うかもしれない。10代の内にそこまで想像して葛藤を乗り越え,20年かけてここまで来た。
たとえるなら,デライトの歩みとは,真っ暗な巨大洞窟を一人で彷徨うようなものだった。どこかに新しい世界につながる出口がある。生きている内に辿り着けるかどうかは分からない。そんな洞窟を歩き続けていた時に見えた光,聞こえた人の声。それが私にとってのデライト利用者であり,デライトへの声だ。
そして今,デライトは「完全な成功」一歩手前と言えるところまで来ている。すでに夢のようなことだ。感謝せずにいられるだろうか。
代表的デライター

{希哲17年5月7日5歩 K#F85E/E74C-BDDE}
SVG スプライトを background-image
などでも利用出来るようにする実装について考えていたが,ここは割り切って,原則,SVG アイコンは引連 SVG としてのみ扱う方針を決めた。
実装上の都合で background-image
を使っているだけのアイコンは別として,現状,背景とアイコンの二つの役割を持たせている二輪鎖を念頭に置いた検討だったが,背景としての二輪鎖も特定要素の端っこに置いているだけなので,一番楽な方法ではあるが background-image
を使う必要は無い。
<view>
の舞覧対応状況に不安があることはさておき,フラグメント識別子を付けると多重立求が発生する舞覧があることがどうしても気になる(手元の Linux 版 Firefox でも発生する)。background-image
を使いたいのが二輪鎖だけだったのでまだ問題は小さいが,SVG スプライトが十分に軽量でフラグメント識別子での参照が十分に少ないという状況でしか効率的ではない手法は範枠化出来ない。
スクリプトで補完した要素に background-image
を設定することも検討したが,そうすると実装コストが動的引連 SVG と変わらない上に,より柔軟性の低い参照方法でしかなくなる。
結局,アイコンはアイコンらしく,要素と一対一で扱うものと割り切った方が何かとすっきりする。
<path>
}{希哲17年5月4日の副日記}{方針変更}{交代させる}{嬉しい所}{二大欠点}{何のことはない}{直接編集}{各部分}...
{希哲17年5月4日の開発 K#F85E/E74C-E5D4}
CSS アイコン実装から動的引連 SVG アイコン実装に切り替えることにした。軽く実験してみたらやたら捗ったため,改めて早期実装を目指すことにした。
昨日の開発記録を書いてみて,CSS アイコンの調整にかかる時間も馬鹿にならないなと考えながら,何気なく Google 検索の素出を覗いていたら,意外に上手くアイコンが SVG で表現出来ているなとは思ったが,やはり HTML で出力している引連 SVG アイコンは気持ち悪いと感じた。ここで,「行き詰まりを防ぐための選択肢」として残すことにしていた(4月27日の開発記録)動的引連 SVG で凌ぐことを思い付いた。
これまで見てきた例や解説が悪かったか,「SVG は煩雑」という先入観がありずっと苦手意識を持っていたが,引連 SVG 関しては,<path>
を中心に削ぎ落とせば十分簡潔に出来ることが分かった。例えば,従来のデライトの + アイコンは以下の記述で十分表現出来る。
<svg viewBox="0 0 32 32">
<path d="M 4 16 H 28 M 16 4 V 28" fill="none" stroke-width="5.5" stroke-linecap="round"/>
</svg>
引連 SVG なので,CSS や JavaScript での各部分の操作も容易だ。直接編集もやたら難しいと言われているので面倒臭そうだなと思っていたが,何のことはない,すぐに習得出来てしまった。CSS アイコンの調整に比べれば直感的ですらあるし,拡縮時の品質は比べ物にならない。これで外部通類への依存という懸念も払拭出来た。あとは,HTML の肥大化と保守性の低下という引連 SVG の二大欠点をスクリプトで補えばいい。動的引連 SVG なら部品の再利用も十分柔軟に出来る。
元々 CSS アイコンを中心とした枠組みの応付だったので,作ってきた枠組みをそのまま活かせるのも嬉しい所だった。動的引連 SVG を中心に,CSS アイコンの方を応付として交代させるだけで大きな方針変更も必要なかった。

{希哲17年5月6日10歩 K#F85E/E74C-DDBB}
SVG スプライトの手法を取り入れ,SVG アイコンの定義は icn.svg
に集約することにした。
SVG 出与えも Aejs に組み込んで直接挿入してしまうことを考えていたが,舞覧隠しの適切な分離が出来なくなる,要素の再利用に必要な id
属性が使いにくい,といった問題があった。外部 SVG を <use>
で利用すれば Shadow DOM になるので,id 属性の衝突などを気にせず要素を整理しやすくなる。
スプライト画像として background-image
で利用しやすいというのも大きい。:target
とフラグメント識別子を利用して表示要素を変化させる技術があることを知ったが,舞覧によっては効率的に隠し出来ないことがあるらしく,今回は見送った。<view>
が使えればいいが,Safari の対応に難がある。当面は古典的な座標指定で行くことにした。
アイコン制作では,アイコンを並べて全体のばら成しを見ながら調整することが多いため,見本を兼ねられるのも便利だ。
SVG スプライトだけで十分かもしれないと思いかけたが,<use>
1つでも若干冗長な上に,1つのアイコンの要素を細かく制御したい場合に <use>
が複数必要になるため,やはりスクリプトでの補完は欲しい。

{希哲17年5月5日16歩 K#F85E/E74C-6B00}
rotate
}{scale
}{scale()
}{transform
}{計算出来る}{calc()
}...
{希哲17年4月29日16歩 K#F85E/E74C-A887}
アイコンの縮尺問題は .sz16
や .sz32
といった分類名で CSS 変数 --icn-sz
を設定することでいったん解決した。これで width
,height
を設定し,基本的に各数値は比率で設定する。border-width
などパーセント指定が出来ない場合も var()
と calc()
を使って計算出来る。
当初,32px四方を基準に値を調整し,最終的に transform
の scale()
で縮尺を調整するということを考えたが,rotate()
などを使いたい時に組み合わせの数だけ transform
の記述が必要という問題があった。最近は scale
や rotate
という個別指定プロパティもあるが,対応舞覧の普及率にまだ若干難がある。
