{HTML の要素 K#F85E/FAD7}
宇田川浩行<meta>
}{見出し要素}{Element
}{希哲17年5月7日5歩}{希哲17年4月27日の開発}{希哲17年4月23日の開発}{<video>
}{<audio>
}{<body>
}{HTMLの要素}{戻り見出し K#F85E/0758-1D21}
宇田川浩行{文字参照 K#F85E/C36E}
宇田川浩行(もじさんしょう,英:character reference)
XML や HTML などの標記言語において,所定の記法で文字を間接的に表現する方法。
例えば HTML では,<
や >
のように構文上直接記述できない予約文字を <
,>
と書いて「<」「>」と表示させることができる。 このように予約文字を標記される対象として記述したい場合のほか,非図形文字や空白類のような視認しにくい文字,字形の紛らわしい文字,入力しにくい文字などを厳密に記述することに役立つ。
HTML では,ISO/IEC 10646(Unicode にほぼ相当)の符号点を十進数または十六進数で記述する「数値文字参照」と,予め定義された文字名で記述する「文字実体参照」の2種類の方法がある。前者(例:α
→ α)は直感性に劣るものの符号点で示せる文字は全て扱うことができ,後者(例:α
→ α)は直感性に優れるものの予め定義された少数の文字しか扱えない。
なお,HTML でいう文字実体参照は XML においては実体参照というマクロ的な仕組みの単なる応用で,定義済み文字も最小限であり,単に文字参照といえば HTML の数値文字参照に相当する方法を指す。
デライトの標記言語であるデラングでは,HTML の文字参照と互換性のある文字参照記法を実装している。
{X(旧 Twitter)はなぜライトモードを捨てたかったのか K#F85E/0758-FB71}
宇田川浩行昨日,X(旧 Twitter)のダークモード以外の配色モードを廃止するとイーロン・マスク氏が表明し,反対意見が殺到するという騒動があった。結局,ダークモードをデフォルトにしてライトモードも一応残すという方向に軟化させたようだ。
デライトでは,今年2月にダークモード(ダークテーマ)対応を実現したばかりなので,個人的に色々思うことがあった。前回予告した KNS についての文章に時間がかかり過ぎているため,今回の一日一文はつなぎとして,開発者の視点からこの騒動の背景について書いてみたい。
デライトは元々明るい配色,いわゆるライトモードのみでやってきた。大きな理由の一つに,イメージの問題がある。白背景を基本としたデザインにはやはり明るく清潔な印象がある。サービスがメディアで紹介される時など,イメージ戦略を考えるとこれは馬鹿にできない。
個人的には黒背景が好きだが,この種のネットサービスではどうしてもアングラ感が出てしまう。背景色を微かな灰色にすることも試したが,白背景と比べるとちょっとくすんだような,地味な印象になってしまう。なるほど,ダークモードが流行しても大手サービスの多くがデフォルトで眩しい白背景を採用している理由はこれかと思ったものだ。
今年2月,満を持してダークモード対応を完了し,私もテストがてらダークモードを常用していた時期がある。最初は新鮮さもあって,それこそダークモードだけでやっていけそうな気がしたが,慣れてくると,眠気が強くなったり,いまいち調子が上がらないことに気付いて,結局ライトモードを常用する生活に戻った。
ライトモードもダークモードも,どう感じるかは個人差や環境差によるところが大きい。どちらかが万能だと思ってしまうのは,単純な経験不足なのだろう。今回の騒動は,ソフトウェア開発におけるマスク氏の経験不足と,新しいロゴに象徴される偏った趣味に起因する出来事とも言える。
ただ,もう少し踏み込むと,マスク氏をこの拙速に追い込んだ X の切実な開発事情が見えてくる。
配色モードの追加や維持というのは,見かけよりずっとコストがかかる。例えば,外観に絡むような機能追加をした時,それぞれの配色モードで問題が生じていないか確認する必要があるし,問題があれば個別に調整する必要がある。そして,このコストは,既存のコードの保守状況が悪ければ悪いほど,変更の程度が多大であればあるほど高くなる。
<path>
}{希哲17年5月4日の副日記}{方針変更}{交代させる}(118){希哲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年4月27日の開発 K#F85E/E74C-E6D9}
宇田川浩行検討作業など。
CSS アイコン補完のための @icn
の実装イメージが概ね固まった。
これまで CSS で画像アイコンを利用する場合はパディングに background-image
を当てていたが,HTML の記述量を増やしたくないため,HTML はそのままに,@icn
で同等の処理を実装することにした。
どの道,要素を動的挿入することになるため,ここで動的引連 SVG も選択肢として残すことにした。複雑な図形の表現のために,部分的に SVG を利用したいことがあるものの,CSS だけではそこまで気の利いたことは出来ない。単純な引連 SVG は HTML の肥大化を招くし,出与え URL も保守性の観点から避けたい。
もっとも,SVG 自体が簡潔な記法ではないので,CSS では表現しにくく,なおかつラスター画像より合理的な場面というのはそこまで無いかもしれない。あくまでも行き詰まりを防ぐための選択肢として残しておく。
むしろ,CSS アイコンの制約を基準として利用して,CSS で無理なく表現出来る程度に用合いアイコンの単純性を保つべきなのだろう。
.zip
}{希哲17年4月14日の開発}{希哲17年4月14日の進捗}{希哲17年4月14日}{含められる}{確実ではない}{移動される}(125)