
{希哲16年2月15日10歩 K#F85E/E74C-2CA8}
昨日,寝る直前にまた脳爆発があり,今朝にかけて文字装飾記法とタグ記法周りの概念整理・仕様整理が急速に進んだ。
文字装飾記法は,「文字装飾を伴う慣用表現」のための記法と位置付けることにした。太字記法(##
),斜体記法(//
),下線記法(__
),打ち消し線記法(~~
,翌日のまとめで「打ち消し記法」から改称)の4記法を基本とし,それぞれ所定装体を伴う <b>
,<i>
,<u>
,<s>
HTML 要素に対応する。
@
を使った文字サイズ記法,%
を使った色記法も検討していたが,タグ記法の概念が出来たことで中途半端なものになるため,これは廃案とする。
検討過程
3つの検討方針
実装自体は容易な部類で,記法も概ね固まっていたにもかかわらず文字装飾記法の実装に踏み切れなかった理由として意味論的な問題があり,これが思いのほか難題だった。実装方針は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>
にすることを考え始めた。

{希哲16年1月23日12歩 K#F85E/E74C-5AE3}
3歩がきっかけで久しぶりに実装予定の文字装飾記法について見直し,以下のように基本的な方針を整理した。
<<大きい文字>>
>>小さい文字<<
##太字##
//斜体//
__下線__
~~打ち消し線~~
下線記法については,_下線_
を有効にすることも考えていたが,適当に書いた時の誤解釈が増える懸念もあり見送ることにした。文字装飾記法は2個以上の記号で統一した方が綺麗にまとまる。簡潔な記法は追加するより削除する方がずっと難しいので,使用頻度を考えてもいまあえて導入する動機に乏しい。
……ここまで考えて,昨年6月23日10歩でも同じ結論を出していたことに気付いたが,再確認出来た。
太字記法については,昨年6月23日9歩では ++太字++
を検討しているものの,最近 ++
を行内埋め込み記法に利用することを考えているためこれは避けたい。そもそも「強調ではない太字」という微妙な要求のための記法であり,廃案も脳裏をよぎった。
分かりやすい代替記法がありうるのかと思ったが,意外と ##太字##
が悪くない。「くっきりした」という意味のシャープにもかかっているし,見た目の濃さも丁度良い。後述の文字サイズ記法同様,記号の数で濃さを調整出来ても面白い。
ついでに,<<大きい文字>>
,>>小さい文字<<
という文字サイズ記法を思いついた。大きさ・小ささは記号の数で調整出来てもいい。直感性は申し分ない。
あまり文字を大きくしたいと思ったことはないが,小書き括弧記法を使わずに文字を小さくしたいと思うことはたまにあったので良い拾い物だった。
上線記法も検討していたが,ここまでで HTML の要素に相当するものは揃い,軽標記言語としての表現力は十二分なので,いったんここで一区切りとすることにした。

{希哲15年6月23日10歩 K#F85E/E74C-2B89}

{希哲15年6月23日9歩 K#F85E/E74C-F7CB}
デラングのこまごまとした記法についていくつか思いつきがあり整理。
主に下線記法,打ち消し記法,斜体記法,太字記法など書式関連のもの。書式の例示など,文書の意味を変えずに使えるものもあった方が良い。
以下のような形で検討。
_下線_
__下線__
++太字++
//斜体//
~~打ち消し~~
下線記法はアンダースコアを使っておけば間違いないだろう。上線記法には ^
が使えそうだ。
太字記法は ++
を使うのが直感に適うか。何となく ins 要素に使えそうだが,対義となる --
はダッシュ記法で使えない。ins 要素や del 要素を直接書く機会は少ないだろうが,どのみち必要であれば別の記法を考える必要がある。
斜体記法はスラッシュに様々な用法があるため迷ったが,二重にすることで実現出来そうだ。
打ち消し記法はとりあえず Markdown 式を採用し,将来的に ==
で二重線が引けるなど拡張しても良さそうだと思ったが,見出し記法と紛らわしい。--
はダッシュ記法との兼ね合いで使えない。
lightgray
}{出振るい}{silver
}{進捗記録}{WhiteSmoke
}{gray
}{下線記法}{引用部区}{希哲15年6月21日の開発}...
{希哲15年6月21日9歩 K#F85E/E74C-A945}
これまで輪符の輪結装体 は 1px #999 の破下線にしていたが,通常の線の色は lightgray,引用部区など WhiteSmoke 背景の上では silver と,かなり薄くした。強調記法に単独で囲まれた輪符に関しては,silver の一本下線にし,少し目立つようにした。
これにより,輪結の重要性に応じてメリハリが付くようになり,重要性や変調をさりげなく示唆したいような場合は軽い強調,はっきり強調したい場合は重い強調というように,強調記法と組み合わせた「強調輪符」の記法が確立した。
輪符自体を強調するのではなく,参照名を強調したいのであれば内側に強調記法を置くことも出来る(例:軽い強調,重い強調)。
経緯
長い歴史
輪符の表示をどうするかという問題は,デルン最初期からの課題だった。
最初は重要な輪符を少しずつ貼り付けるような使い方しかしていなかったため大きな問題ではなかったが,いずれ文中に輪符が増えてくれば,重要性によって表示し分ける必要が出てくる,というのは当初から想定していた。元々,入力道手の機能や自動補完などで文章のほとんどが意味符号になるような技術として構想していたからだ。
実際,デライト以後,私自身の慣れとデライトの品質向上によって自然と文中に輪符が増えてきた。現在,私の描出ではほとんどの語が輪符であり,輪結になっている。こうなると,閲覧者にとっては,どこが重要な輪結なのか分からない上に,中途半端に目立つ輪結だらけで見にくいという問題が出てくる。
もう一つ,輪符に関する問題があった。輪符の知名を変えて参照したということが分かりにくいという問題だった。輪符の知名を変えたということが読み手にとって重要なことがあるが,これまでそれを表現する良い手段が無かった。
どちらの問題も,少し前までは自動的に解決出来るのではないかと考えていた。例えば,前景輪にある輪符を自動的に強調表示したり,知名と異なる名前で参照された輪符を斜体にするなどということを考えていた。
ただ,これは描出経験を積むにつれ無理があると感じるようになった。
まず,時として膨大になる前景輪に一致する輪符をいちいち見つけるのは現実的ではない。見えている10輪に限定するのも不自然な見え方になるだろう。輪符の参照名をいちいち照合するのも軽い処理ではない。
描写に隠し文字列でも埋め込めば負荷軽減にはなるだろうが,依然として無視出来ないコストではある。何より,出与えの一貫性や保守性に深刻な影響を及ぼすことは目に見えている。
それ以前に,自動装体を適用すべきではない場合が多々あることも分かってきた。全知検索との兼ね合いも考えると,文中で目立たせたい輪符と引き入れたい輪郭はむしろ一致しないことの方が多い。
知名に関しても,例えば,「知る」という輪郭を「知って」のように語形を変えて参照することも増えてきた。明らかに自動装体にすべきではない,瑣末な場合が多々ある。
最近では,デラング整備の進展もあり,これは手動装体,つまり何らかの記法で対応すべきなのではないか,と考えるようになっていた。
今日の進展
こうした問題の解決に向けて本格的に考え始めたのは,まさに今日,昨日の日記を付けていた時に,「希哲15年6月20日の開発」という輪郭を「開発では」として参照した時だった。この「開発」が,一般的な意味での開発なのか,特定の日の開発を指しているのか,一見して分からない。これは以前からずっと気になっていた問題だが,そろそろ何とかしたいと思った。
重い強調を使ってみたりもしたが,重過ぎる。そこで軽い強調を使ってみることにしたが,軽い強調は欧文向けで,斜体・伊体に依存した装体は避けたかった。ここで,強調輪符の下線を調整することを考え始めた。
強調輪符をいかに目立たせるか,ということを考えているうちに,そもそも輪符の輪結全般が目立ち過ぎていることに気付いた。というより,これまではこの輪結装体が軽い参照も重い参照も表現していたので,気付いてもどうしようもなかった。ここで,通常の輪符と強調輪符でメリハリを付けることを考え始めた。
破線は太くすると環境によって全体的に大きくなり短い語では破線らしく見えなかったりするため,一本下線にすることを考えた。もともと点下線・破下線・一本下線で輪結の強さを表現した装体で,一本下線は前景輪のために取っておいたが,前述の理由で未使用だった。ここで,輪結装体に関する問題全般と繋ってきた。
通常の輪符に関しては,いっそのこと下線類を無くしてもいいかと思ったが,流石に文字色だけでは心許無い。視線の流れを遮ることなく,視線を止めれば容易に輪結と視認出来る按配を理想として,破下線の色を極力薄くすることにし,白背景なら lightgray,引用部区など WhiteSmoke 背景の上では silver が最適と結論付けた。
(Firefox で調整していたためもう一段濃い silver と darkgray の組み合せで決めかけたが,他の環境では破線密度の差でまだ濃過ぎるように見えたため,まとめ中に修正)
強調輪符の一本下線に関しては,薄い色では弱いように思え gray を試したが,明示的に下線を引きたい場合のために下線記法を導入することも考えているため,兼ね合いであえて silver にしておくことにした。
まずは CSS のみでの出振るい。only-child で複数の輪符には効果が跨らないようにしてあるが,テキストノードは含まれうる。本来は一つの輪符のみを強調した時の効果であるべきだが,とりあえずは十分だろう。
総括
開発記録に書いておく。
