{}{戻り見出し}{改見出し}{もどりみだし}{「リターン見出し」}{}{希哲17年10月18日}{かいみだし}{〈return heading〉}{記号見出し}(15)

{戻り見出し K#F85E/0758-1D21}

もどりみだしreturn heading

デラングあるいは HTML において,リターン記号U+21B5↵のみを書いた見出し

HTML では見出し階層新しい見出しでしか改めることが出来ないが,下位階層から上位階層ったり,同階層見出し区切りをつけたりという目的のみで,見出し内容必要としない場合見出し内容邪魔になる場合がある。しかし,HTML見出し要素内容持つ必要があるとされている。そこで,簡潔かつ直感的な」を使おうという一種の命名規約である。

第1階層 A-1

第2階層 A-2

第3階層 A-3

ここで第1階層に戻り,前出の第1階層 A-1 に区切りを付ける。

大輪郭整備中の希哲17年10月18日考案

{文字}{もじさんしょう}{HTML}{XML 用語}{〈character reference〉}{HTML 用語}{参照}{XML}{素描}(9)

{文字参照 K#F85E/C36E}

もじさんしょうcharacter reference

XMLHTML などの標記マークアップ言語において,所定の記法文字間接的に表現する方法

例えば HTML では,<> のように構文上直接記述できない予約文字&lt;&gt;書いて<」「>」と表示させることができる。 このように予約文字標記される対象として記述したい場合のほか,非図形文字空白類のような視認しにくい文字字形紛らわしい文字入力しにくい文字などを厳密に記述することに役立つ

HTML では,ISO/IEC 10646Unicodeほぼ相当符号点コードポイント十進数または十六進数記述する数値文字参照」と,予め定義された文字名記述する文字実体参照」の2種類方法がある。前者(例:&#x03B1; → α)直感性劣るものの符号点示せる文字全て扱うことができ後者(例:&alpha; → α)直感性優れるものの予め定義された少数文字しか扱えない

なお,HTML でいう文字実体参照XML においては実体参照というマクロ的な仕組み単なる応用で,定義済み文字最小限であり,単に文字参照といえば HTML数値文字参照相当する方法指す

デライト標記言語であるデラングでは,HTML文字参照互換性のある文字参照記法実装している


{方向}{}{}{}{}{一日一文}{サービス}{希哲17年2月}{希哲17年7月の一日一文}{時間がかかり過ぎている}(204)

{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 なので,CSSJavaScript での各部分操作容易だ。直接編集やたら難しい言われているので面倒臭そうだなと思っていたが,何のことはないすぐに習得出来てしまったCSS アイコン調整比べれば直感的ですらあるし,拡縮時品質比べ物にならない。これで外部通類への依存という懸念払拭出来たあとはHTML の肥大化保守性の低下という引連 SVG二大欠点スクリプト補えばいい。動的引連 SVG なら部品再利用十分柔軟に出来る

元々 CSS アイコン中心とした枠組み応付だったので,作ってきた枠組みそのまま活かせるのも嬉しい所だった。動的引連 SVG中心にCSS アイコン応付として交代させるだけで大きな方針変更必要なかった

{開発記録}{HTML の要素}{希哲17年4月27日の副日記}{保つべき}{表現出来る}{表現しにくい}{出与え URL}{気の利いた}{複雑な図形}{当てていた}(76)

{希哲17年4月27日の開発 K#F85E/E74C-E6D9}

{進捗記録}{}{進捗}{.zip}{希哲17年4月14日の開発}{希哲17年4月14日の進捗}{希哲17年4月14日}{含められる}{確実ではない}{移動される}(125)

{希哲17年4月14日12歩 K#F85E/E74C-3EE7}

進捗時限記録中略

設定ページ整備エクスポート機能実装

仕様検討終了

サイクリング中良い思い付きいくつかありエクスポート機能想定以上に洗練されたものになりそうだ。

読み込み中...
{HTML}

{}