{新生デライト}{知能増幅メモサービス}{一日一文}{希哲16年4月の一日一文}{森を見て木を見る}{向けた}{研究期間}{科学的な}{粘り続ける}{粘り続けた}...=}(326)

{第四次宣伝攻勢に向けて K#F85E/A-E74C-668D}

デライトは,黄金週間初日となる明日29日4度目の宣伝攻勢第四次宣伝攻勢始めるこれを機に中断していた一日一文」の日課再開することにした。

デライトはいま,包括的な改良構想によって「新生デライト」に生まれ変わろうとしている。今回の宣伝攻勢コンセプトは“新生デライト開発実況”だ。この一日一文含めて開発状況開発者考えなどについて積極的に発信していきたい。

森を見て木を見る

3度宣伝攻勢から得た教訓色々とあるが,4度目の宣伝攻勢目前にしてつくづく感じていることは,結局やってみなければ分からない,ということだ。

ソフトウェア開発やっていると,ここが悪い,あそこが分かりにくいなどといったことばかり考えてしまいがちだ。とりわけデライト新奇見える代物なので,開発者利用者も,“デライトの問題点”について考え込み過ぎる嫌いがある。

問題点地道に改善していくのは当たり前のことだが,問題点ばかり見ていると,「問題があることが問題」であるかのような錯覚に陥りがちだ。問題のないソフトウェアなど存在しないので,これは「木を見て森を見ず」でもある。広く使われている全てのソフトウェアは,それぞれに問題抱えながらそれぞれの役割を果たしている。その全体像見ず問題の大きさ正しく見ることは出来ない

そもそも使いやすい UI分かりやすい文書……などと全て兼ね備えた優等生的なソフトウェア世の中どれだけあるだろうか。使いにくかろうが分かりにくかろうが,バグだらけであろうが,“使う必要”があれば使われる。それが現実だ。ツール文書も,必要ならユーザー作り始める昔からそうやってソフトウェア共有されてきた。

そこに革新性があればなおのことだ。誰でも戸惑いなく使える革新的なソフトウェア──そんなものは夢の中にしか存在しないデライトがそうであれば,私はとっくに世界一の有名人にして世界一の大富豪になっている。冷静に考えれば馬鹿馬鹿しい話だが,知らず知らずのうちにそれに等しいことを考えてしまうのが認知バイアス怖さだ。

最大の課題

デライト普及させる上で最大の課題換言すれば,最も手っ取り早い道筋は何かといえば,デライト目指していること理解してもらい,共感してもらい,必要としてもらうことに他ならない。またこういう文章書き始めた理由だ。

デライトは,よくあるメモサービス出来るだけ近付けた知能増幅(IA)サービス名付けて知能増幅メモサービス」だ。一時期「最も使いやすいメモサービスを目指す最も使いやすい知能増幅サービス」表現していたこともあるが,研究室臭いものになりがちなこの種のソフトウェアとしてはすでに驚くほど簡易的で,その点の達成度決して低くないはずだ。

とはいえ,全く新しい領域目指している以上,新しいやり方理解して慣れてもらうしかない部分どう頑張っても残るデライト初心者戸惑いがちなところは,デライトの目的のためにあえてそうしていることが多い多くの人にとっての分かりやすさだけを基準にして最終的に出来るのは,微妙に使いにくいよくあるメモサービスだ。レーシングカー難しさだけを問題視してオモチャの車にするわけにはいかない。

2年ほど前に公開してから,デライトにはそれなりに多くの人来てくれた例に漏れず大半の人黙ってり,一部の人サービスの問題点指摘して去っていった。私が開発者として一番痛切に感じていたことは,そうした問題点大きく感じさせるほどの利用動機小ささだった。「ここが使いにくい」などと言い残して去っていった人達本当に言いたかったことは,「それでもと使うほどの意義見出せなかった」ということなのだと思う

事実デライト使いにくさ分かりにくさ改善して利用者が増えた試しがない。いま日常的に利用してくれているのは,あらゆる面でいまとは比べ物にならないほどデライト貧弱だった時期に,どこかで私がデライトについて語っているのを見て,その可能性興味を抱いてくれた人達だ。

デライトの意義理解したにとってデライトの問題決して大きくない開発者として,そう確信出来る地点ようやく来られた気がしている。あとは伝え方問題なのだろう。

結局は運

もう一つ,商売において陥いりがちに,「生存者バイアス」としてよく知られた認知バイアスがある。成功例背後にある屍の山に,気付きにくい。そして,成功失敗要因として語られることは,結果論でしかないことが多いデライト成功するもしないも,結局は「」によるところが大きい,ということだ。

例えば,売れっ子芸能人がみんな親しみやす万人受けするタイプかといえば,全くそんなことはない。癖が強く,とっつきにくそう多い。彼らは売れたから「それが良い」と言ってもらえるけれども,同じ特徴持っていても売れずに「だから駄目なんだ」と言われているごまんといる万人受けしそうなタイプならタイプで,売れなければ無個性つまらない」などと言われる。そのは,巡り合わせとしか言いようがない

勝てば官軍ではないが,デライトの“とっつきにくさ”とされていることも,何かのきっかけ話題になってしまえば“面白さ”になりうる。その程度のことでしかないのかもしれない。

結局は運」というのは投げ遣りなようでいて,実は非常に前向き覚悟必要な考え方でもある。粘り強く試行繰り返していくこと以上に成功確かなものにするはない,ということだからだ。奇跡のような偶然も,サイコロ振り直し続ければ必然近付いていく

そしてこのデライト自体,すでにソフトウェア開発における奇跡的な生存例だ。ソフトウェア開発世界では,デライトよりずっと低い目標掲げていても,成功どころか動く物すら出来ず頓挫していくプロジェクトごまんとある。その中にあって,これだけの大風呂敷を広げ,この品質実装運用され,少ないながらも利用者がいて,ちょっとした収益化まで出来ている。こんなサービス世界見渡しても他にない

そんな奇跡がなぜ起きているのか。それはやはり,「粘り続けたから」としか科学的な説明のしようがない。デライト自体は公開から2年越えたばかりのサービスだが,研究期間含める20年近い歴史がある。その全て無駄なくデライト結実している。

味方に付けデライトの成功という奇跡起こすために,ひたすら粘り続ける。これを新生デライトの完成向けた宣伝攻勢所信表明としたい。


=}(1){あれ}
{希哲16年4月5日の開発}{希哲16年4月5日の進捗}{CSS 変数}{生み出した}{伝証}{合理化した}{呼ぶべき}{汚い現実}{ウェブの理想と現実}{もたらされる}...=}(208)

{希哲16年4月5日14歩 K#F85E/A-E74C-6431}

CSS 変数(カスタムプロパティ)の導入舞覧ブラウザ五年対応原則採用決め終了今後デライトでは,「5年以内離立された版存主要舞覧」を中心に対応していく

希哲15年3月1日の開発から「デライト推奨動作環境」として同様の定義考えてはいたが,当時は,古い舞覧対応努力はするが推奨はしない程度の,もっと緩やかなものを想定していた


希哲13年ECMAScript 2015HTML5CSS3比較的新しいウェブ標準導入決めてからだいぶモダンにはなったが,まだデライトの舞覧対応方針には感覚的保守的なところがあった。感覚的に影響範囲の広い付徴主要舞覧対応から10年影響範囲の狭い付徴5年目安導入考えていたrem ですら必要以上には使わなかった

先日前次記法実装グリッド領当て導入したが,これはちょうど主要舞覧使えるようになってから5年ほど経つ機能だった。一記法装体過ぎなかったこともあり,ここまで辛うじて良かったが,他にも色々応用したいことが出てき舞覧対応方針見直し必要を感じていた

決め手は,デライトのダークテーマ対応見据えて CSS 変数の導入考え始めたことだった。CSS 変数主要舞覧対応から5年ほど経つが,本格的に導入するとなると影響範囲広がり過ぎる


Can I use対応舞覧よく調べるようになってから,「5年以内離立された版存主要舞覧」が意外に普及していることに気付いた大体90%以上はある。

地域にもよるだろうが,確かに今時古い舞覧使い続ける方が難しいかもしれない。個人機なら5年平均的な買い替え周期であり,スマートフォンなら古い部類だろう。自動更新標準的になった昔と違って多数派の“普通の人”ほど新しい舞覧使っている

あえて古い舞覧使い続ける場合というと,一昔前なら古い個人機再利用というのがあったが,格安インターネット端末普通に流通している今,新しい舞覧使えないほど古い端末使い続ける費用対効果疑わしく,制危考えれば推奨出来ることではない

一番面倒なのが舞覧の更新許されない企業内利用だが,そもそもそんな保守的な環境デライト利用出来るとは考えにくい

こう考えていくと,デライトにとって古い舞覧への対応重要性極めて低い言わざるをえない

奇しくも新生デライトの完成目指している6月15日に,IE11 のサポート終了がある。中途半端気もする内容だが,いわゆるモダンではない舞覧最後の砦崩壊する新しいウェブ標準への社会的移行象徴的な出来事にはなる。


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

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


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

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


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

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


=}
{踏み切れた}{`radial-gradient()`}{作れた}{理想的な陰影}{簡単なようで}{実験していた}{画段}{色々な場面}{稀に起こる}{外していた}...=}(203)

{希哲16年3月28日の開発 K#F85E/A-E74C-5B9D}

KNEST 隠し実装の再開金風といった出来事中断していた昨年9月以来,初めての Aejs出振るい終えた最初微調整程度でとりあえず出振るい目指すつもりだったが,あっという間下見機能陰影付きスクロール形になり,一応の新輪郭選り手」が出来た

外観操作性ともに洗練された新輪郭選り手日々の描出がより快適になることはもちろん下見機能手定め領当て調整大幅に効率化することによりデラング整備加速するだろう。そもそも Aejs出振るい出来なかったことで前縁関して出来ること限られていたため,その障害無くなったことが大きい

新輪郭選り手

今回出振るい以前を「旧輪郭選り手」,以後を「新輪郭選り手」と仮に呼んでいる

新輪郭選り手では,@oln.bld詰め込んでいた選り手関連機能@oln.edr_dln.bld@oln.edr_knm.bld整理し,複雑な機能見通し良く管理出来るようになった。これにより,保守性もちろん全体として見触れ大きく改善した。

まず,これまで知名選り手角丸長方形で,描写選り手吹き描き合わせた眼形表示していたが,両方開いている場合は「合体選り手」として眼形になるようにした画面撮り新規描出フォーム再描出フォーム旧輪郭選り手では単独開いた場合外観変わらず調和感欠けていた画面撮り新規描出フォーム再描出フォーム挙動もより連動的になり,自然になった。

描写選り手右脇適当に付けていた取り消しボタンも,合体選り手では知名選り手描写選り手同時に閉じる機能分かりやすくなり,見た目洗練された

描出ボタン22日9歩方針まとめ目障りにならないデザイン保ちつつ初心者にも分かりやすいものに出来た

挙動面では,違了処理整備若干表示タイミングなどに出来ていたぎこちなさ解消出来た外していた選り手溶暗溶明動き付け復活させ,滑らか見えるようになった。

まだ様子見必要だが,違了処理整備のあたりから出来ていた不具合解消期待出来る。特に描写選り手二重いたり,デラング記法消去して再描出してしまう不具合稀に起こるのが気になっていた

今回目玉となった下見機能は,思わぬ形あっさりまとまった感触く,色々な場面活躍してくれるだろう。

陰影付きスクロール

26日14歩出来た陰影付きスクロール同時に出振るいした画面撮り下見機能にも有用気付いたことで実装踏み切れた

背景色溶暗していく「溶暗付きスクロール」として考え始めたのは昨年3月11日9歩だったが,空行続くこともあり閲覧性必要な描写部には不向き気付いてからは,薄い陰影付ける方向実験していた

これも簡単なようで調整難しかった陰影がかかる高さ濃さ画段微妙な緩急調整繰り返し,さりげなく,かつ分かりやすい理想的な陰影ようやく作れた一時linear-gradient() ではなく radial-gradient() を使って中央丸みのある陰影試したが,交度部区などに重なった時に視認出来なくなるためやめた

諸場舞覧などスクロールバー出ない舞覧スクロール可能であることが非常に分かりにくいという用合い上欠陥がこれで解消したスクロールバーの出る舞覧でもより直感的スクロール可能であることが分かるようになり,効果大きい

{希哲16年3月3日}{『希哲日記』}{輪郭整備}{気ままに}{臨時半休}{気が休まらない}{全休}{気楽に}{過ごせた}{多くなった}...=}(38)

{希哲16年3月3日の日記 K#F85E/A-E74C-74B3}

予定通り臨時休業にした。久しぶりに気楽に過ごせた

ここのところ半休にすることが多かったが,のように過熱しがちな時期には全休有効なようだ。半休では進捗が出るまで気が休まらないし,進捗が出だすと熱中して止まらなくなる

そもそもなぜ半休多くなったのかといえば,脳過熱定休日前に臨時半休にすることが増え,その代わり定休日半休にして……と調整していたからだ。

臨時半休仕方ないとして,今後定休日常に全休とすることにした。


休日の過ごし方として,気ままに輪郭整備をするのはやはり良い娯楽のようなものでもあり,頭の整理にも献典整備にもなる。

=}
{デライト開発}{デラング}{進捗記録}{デラング 0.03}{デラング 0.04}{デラング 0.05}{デラング 0.02}{希哲16年2月23日の開発}{希哲16年2月23日の進捗}{旧版号}...=}(90)

{希哲16年2月23日12歩 K#F85E/A-E74C-BD5C}

進捗時限記録中略

デラングの版存に関する昨日の検討続き終了

今のところ,デラングの版存最新定義は以下のようになっている希哲15年5月15日の開発

0.01
DIL 0.1別名
0.02
DIL 0.2別名
0.03
現行版

この定義実装基準行ったもので,その後の劇的な実装変化に全く追い付かず更新していないそもそもサービス中心に開発されている性質上仕様実装一致させないことも場合によって必要になり,区切り難しい

最新のデラングの位置付け考えても仕様と実装を分離し,デラングの版存仕様基準決めるべきだろう。それへの追随度Dex の版存決める

0.03決定当時仕様をもって再定義するとして,現在のデラング整備一段落したところで 0.04まとめ,その次の 0.05破壊的変更まとめることにした。この「破壊的変更」は,主にキーボード記法ウィキ互換輪結記法への転用想定している。

Dex の版存は,現行版形式的に Dex 0.01 としておき,次でデラング歩調を合わせ Dex 0.04 とすることにした。


ずっと忘れていたが,今回検討で「デラング 0.001」を描出していたことに気付いた。以下のような記述残っている

希哲13年7月27日,これまでの DIL との互換性を保った形で整理を進めることにした。

新規描出日時デライト開発着手したばかりの希哲13年2月26日同年7月27日というとデライト正式離立向けて大忙しだった時期で,すぐ忘れたのだろう。

実質的に 0.03 ということになるはずなので,ここで 0.03旧版号再定義することにした。

=}
{HTML}{駒手記法}{進捗記録}{あれ}{希哲16年2月20日13歩}{神秘的な}{別に}{実装した}{付けた}{階層区切り}...=}(248)

{希哲16年2月15日24歩 K#F85E/A-E74C-1EF9}

進捗時限記録中略

不意に閃いた階層区切り線」についての方針まとめて終了

従来の見出し未満区切り線記法に,見出し階層越えられる階層区切り線」を加える。以下のように,唯一通常の区切り線区別出来る見出し記号 #全角 使う

* 第1階層
** 第2階層

#========================#

第1階層段落。

#------------------------#

第2階層段落。

#- - - - - - - - - - - - #

第3階層段落。

#. . . . . . . . . . . . #

第4階層段落。

##

第1階層段落(# の数でも調整出来る)。

持ち辺モチベーション

従来の区切り線記法は,HTML において対応する <hr>性質上見出し未満区切りにしか使えなかった

見出し階層作った後で描写全体に対するフッター的なものを書こうとする第1階層見出し作る必要があるが,しばしば大袈裟感じられることがある。

検討過程

空見出し」の挫折

今回検討当初は,「空見出し」という概念主に考えていた区切り線長さ任意であるべきなので,どうっても自然な形階層調整出来そうになかった。その点,見出し内容出来れば手っ取り早い

しかし,等号星号区切り線使う予定なので,== のように第2階層以降で内容空にする衝突することになる。

区切り線の方を見直しても,--区切り線なら == はやはり二重区切り線であってほしい。直感性下線形見出しとの整合性考えるとこれは捨て難い星号による区切り線はそれに比べればまだ転用余地があったが,その代わり *使う Markdown の区切り線記法との互換性損われる

そもそも,「空見出し」という概念にも無理がある文字を書くから見出しなのだし,実質的に区切り線なのだから,直感的とは言い難い

階層区切り線」の閃き

ここで,唯一区切り線記法被らない見出し記号である番号記号思い出した

番号記号による見出しは,ハッシュタグ駒手記法との衝突避けつつ atx 式見出しある程度互換性持たせるため,## のように2個以上条件対応していた個人的に好きな記法ではなかったこともあり,おまけのような扱いで,ここまで気付かなかった

すでに「空見出し」に感じていて,区切り線記法での対応立ち返っていたことで,この ##特殊な区切り線みなせる特徴持っていることに気付いた記号2個以上繰り返す区切り線見える記法で,実際普文枠線的な装飾使われることが多い記号でもある。

特に,区切り線記法としての統一感直感性保てる2個第1階層表せるということは決定的に重要な点で,見出し記号個数階層関係一致しないとどうしてもちぐはぐ見えてしまう。これは,衝突回避したとしても等号星号では解決出来ない問題だ。区切り線記号としての最短形見出し記号としての第1階層対応しうる唯一記号番号記号だった。

ただし,通常の区切り線記号異なり,個数階層対応するため,普文装飾兼ねられないという問題があった。上位階層区切り線普文上で目立つように書けない

これは,最新の区切り線記法下線形見出し記法検討9日17歩19歩踏まえ見出し階層対応する4種区切り線組み合わせる解決することにした。つまり,第1階層から順に最短形#==##--##- -##. .# というように区切り線組み合わせることが出来るようにする。これがまた都合が良いことに,よくある装飾見える

9日15歩以後,見出し下線区切り線長さ区別出来るようになっているため,区切り線装体にはある程度多様性持たせ問題ない一方見出し下線階層表す装体になっているため,一定制限必要になる。この点でもぴったり噛み合った

別に2個以上良いだろうと実装した区切り線記法おまけ感覚付けた番号記号による見出し記法最近の拡張方針……何気ない全てパズル要素だったかのように思える神秘的な閃きだった。

番号記号見出し仕様厳密化

この階層区切り線考案に,番号記号による見出し常に2個最上位階層とすることにした。つまり,*=##始まる見出しはともに最上位階層表す

これまで異なる見出し記号併用することは特に想定しておらず,実際使われていないはずなので,記号個数単純に計算していた。見出し階層相対的な個数決まるため,*始まる見出しがあると ##第2階層になる。これは階層区切り線整合しない。

特に仕様として決めていたことではないため,ここで厳密化することにした。

実装上の課題

仕様完璧思えるが,実装上の課題残った

HTMLCSS機能的には,可接性ちつつ見出し要素隠すことは造作もないが,SEO 上の懸念多少ある。今の検索演心評価理積みはそこまで単純ではないだろうが,伝統的に見出し要素隠すべきではないとされてきただけに,どこまで不利になるか分からない出来るだけ行儀の良い実装方法見つけたい

そもそも見出し要素にしてはいけないのか,<section> あたりを使って上手く誤魔化せないか,など色々考えてみたが,どれも多かれ少なかれ怪しさ残る

見出しの無い階層区切りというのは HTML想定外だったのだろう。

{デラング}{進捗記録}{希哲16年2月19日}{希哲16年2月19日の開発}{本来の意味}{自サービス}{止めておく}{独自に}{見ていた}{いっそのこと}...=}(131)

{希哲16年2月19日11歩 K#F85E/A-E74C-D1B5}

進捗時限記録中略前後

何気なくマイクロブログサービス用者ユーザー示せる記法欲しいという考え事をしていたら「外部サービス利用者記法」に発展したので,軽くまとめ終了

とりあえず分散型 SNS使われている記法拡張し,@[用者名]@[ドメイン名]汎用記法整備する方向進めることにした。


要は@user書いたTwitter輪結したり,@user@example.com書いた分散型マイクロブログ捌き手輪結してもいいのではないか,と考えたことがきっかけだった。

ここで一つ,@user@example.comhttps://example.com/@user必ず対応するのだろうかという疑問湧いた以前にもなんとなく考えたことはあったが,ActivityPub というか WebfingerURL引き出したり,面倒臭そう気がし進展しなかった。このあたりの仕様がどうなっているのか,いまだによく分からない

もっとも,ざっと見渡す限り分散型マイクロブログ捌き手は大体 https://example.com/@user になっているし,自分で Mastodon 捌き運営していた時も出放りはこれだったので,事実上の標準とみなしていいのかもしれない。


Twitter@user でいいかと思っていたが,いくら普及しているとはいえ,これは特定サービス寄り過ぎだろうということで,@user@twitter.com統一することを考えた。ただ,Twitterプロフィールページ正規 URLhttps://twitter.com/user だ。https://twitter.com/@user でも転送されるとはいえ,若干気持ち悪い

さらに,この時点では @user@twitter.com と書けば @user表示されるという仕様考えていたため,いずれにせよ特定サービス向けの処理追加出来るようにする必要があった

ここまで考えたところで,いっそのこと @[用者名]@[ドメイン名] として,外部サービス用者指すための汎用的な記法にしてしまえばいいのではないか,と思えてきた。これは, 氏が独自に同様記法使っているのを見ていたことが大きかった

[ドメイン名] は,@[用者名]@twitter のように自明なら短縮出来るようにしてもいいかもしれない。対応サービス毎に用者名解釈輪結先調整し,それ以外は https://[ドメイン名]/@[用者名]輪結する。


少し困ったのは,簡潔分かりやすい名前見つからないことだ。一応平たく外部サービス利用者記法」を仮称としておく。

異邦人記法」というのも面白いかもしれないと思ったが,一見して意味分かりにくいので別名としてしか使えないだろう。「宛名記法」はどちらかというとメールアドレス向きか。


デライト使う予定が全くなかったため,@[用者名] という表示Twitter のために使うつもりだったが,これは止めておく

そもそも SNS などでは自サービス上の用者に対する言及メンションという意味を持つ記法から来ているデライト使わなかったとしても,この種の記法必要とするサービスにはデラング応用出来ないことになってしまう。

ここから @[用者名]本来の意味考え始め知番輪符などと組み合わせる可能性気付いた。これは「言及記法」として別途検討することにした。

{HTML}{HTML5}{デラング}{進捗記録}{高い}{あれ}{役割を持たせる}{役割を持つ}{緩衝的}{実践的な}...=}(248)

{希哲16年2月15日10歩 K#F85E/A-E74C-2CA8}

進捗時限記録中略

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

文字装飾記法は,「文字装飾を伴う慣用表現」のための記法位置付けることにした。太字記法##斜体記法//下線記法__打ち消し線記法~~翌日のまとめで「打ち消し記法」から改称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> にすることを考え始めた

{そもそも}

{}