{素出}{`--?`}{書き分けたい}{`?--`}{`!--`}{`--!`}{輩符}{区別しにくい}{希哲16年1月26日の進捗時限}{希哲16年1月26日の進捗}...=}(34)

{希哲16年1月26日15歩 K#F85E/A-E74C-869A}

進捗時限記録中略前後

注意記法補足記法区切り線記法併用についての整理終了

!--?--始まる場合の装体は,小書きにするだけでは周囲区別しにくいため区切り線を付けようかと思っていたが,普通の区切り線との併用がしにくそうなので,区切り線機能とは切り離すことにした。

素出上で書き分けたい場合は輩符の数を変えるなどしてもらえばいい。

区切り線を引くことを --!--?明示させてもいいかもしれないと思ったが,かえってややこしくなるか。

=}
{`<small>`}{置き換えられる}{補足部区}{注意部区}{一段階目}{希哲16年1月24日4歩}{強調度}{文字装飾記法}{注意記法}{補足記法}...=}(73)

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

注意記法補足記法についての再検討終了

4歩を以下のように修正した。強調度に応じて三段階となる補足記法同様

!--
小さな注意書き
--

!!--
通常の注意書き
--

!!!--
重要な注意書き
--

装体は,23日2歩下敷きに,境界線背景色無しで font-size: 0.8em 程度にした小書きのものを加える。この場合,一段階目注意部区補足部区装体的に区別出来なくなるが,そもそも小さな注意書き補足違い曖昧なものなので自然といえば自然だ。


そもそも注意書き目立つように書かれるものばかりではない,というところに引っかかっていた

二段階三段階かは迷ったが,二段階にして後から追加出来なくなるよりは,三段階にして一段階目無用の長物になる後悔の方が小さい


当初,記号の数で「重要度」を表すことにしていたが,内容重要性装体目立たせ方は必ずしも一致しないので,「強調度」程度の意味合いにしておくべきかもしれない。


ダッシュ記法への応用考えた

例えばデラング文書では,目次項目末尾<small>----輪郭記法</small> などと書いているが,これを ?----輪郭記法置き換えられるかもしれない。

23日12歩書いた小書き括弧記法を使わずに文字を小さくしたいと思うことはたまにあった」とはこのことだったが,あくまでも文字装飾記法の一種である文字サイズ記法フォント記法<small> 相当の表現完全に代替は出来ない。

=}
{特殊な例}{生じていた}{再確定}{ボタン記法}{希哲16年1月23日の進捗時限}{希哲16年1月23日の進捗}{希哲16年1月23日}{行内埋め込み記法}{キーボード記法}{機能する}...=}(55)

{希哲16年1月23日4歩 K#F85E/A-E74C-6C79}

キーボード記法についての再検討終了

キーボード記法に関しては,改めて [_X_] 記法中心にしていく方針再確定した。また,[_X_] + [_Y_] を一つの記法として扱うことも明確化した。


[_X_] 記法導入して一件落着かと思ったキーボード記法だが,その後,少し迷い生じていた

この記法ボタンらしく見え過ぎるせいで,ウィジェットボタンにも応用出来る「ボタン記法」のようなものも可能なのではないかというが出てしまっていたAsciiDoc にはボタンメニュー表現出来るマクロがある)。それが可能なら,[_X_]キーボード記法とすべきではないかもしれない,という気がした

ただ,[_X_]キーボード記法一般化した「ボタン記法」にしようかと考えてみたところで,そもそも千差万別外観を持つウィジェットボタン抽象的表現出来る装体存在しないことに気付いて廃案となった。確かに記号としてみるとボタンらしいのだが,ボタンらしい装体を付けようとすると全くイメージと違うものになってしまう。これではあまり意味が無い。あくまでも言語的に扱うか,視覚的に扱いたければ画像素材行内埋め込み記法挿入するのが適切だろう。

そう考えると,キーボードキーに使う装体キー記号としてちゃんと機能するのは特殊な例だ。

=}
{文字サイズ}{目立たな過ぎる}{装体の調整}{読みにくさ}{短い URL}{事情が異なる}{ちょっと長い}{文書の傾向}{検討していた}{気付けた}...=}(94)

{希哲16年1月19日1歩 K#F85E/A-E74C-5396}

デライト装体調整URL 装体調整終了

直書き URL<a.URI>font-size: 0.9em等幅フォントにしたURL 装体調整前後字間無し昨年6月30日の開発からだが維持する。

直書き URL のある描写読みにくい問題はずっと以前から感じていて,何度か調整しているが,一昨日の開発中にふと,「文字サイズ小さくしていない」ことに気付いた

昨年6月30日の開発字間無しにしているが,等幅フォントにして変に目立ち過ぎるという理由したりもしている。この時になぜ文字サイズ小さくするという発想がなかったのか不思議だ。他にも問題山積していて思考時間割けず灯台の下まで目が行かなかったか。

今回<kbd><code>装体について考えていたところだったので,その関連気付けたのだろう。

文字サイズはやはり0.9em丁度良い0.8emにすると長い URL はともかく短い URL提示する時に今度は目立たな過ぎる


これにより,十分凝縮されメリハリが付いたので,予てから検討していた長い URL の省略については保留とすることにした。

長い URL の省略は,簡単なようでいざ導入しようとすると意外と難しい問題がある。

まず,デライト上文書の傾向からいっても,「ちょっと長い」程度の URL省略したくない。URL全体情報として有用場合しばしばある。このあたりはマイクロブログなどとは事情が異なる

では,どこで省略すべきかという問題になるが,長い URL許容すればするほど比較的短い URL読みにくさ解消されないというジレンマがあった。これは装体の調整解決した。

そもそも輪結記法[ ... ]もあるので,現状維持で特に困ることはないだろう。そのうち https://example.com/abc ... xyx のような省略記法導入してもいい。

ただ,パーセント符号化復号はしたい。これは昨年3月22日2歩決めていたことだが,少し面倒臭い部分がありいまだに実現していない。

{組み合わせた}{キーボード記法}{見送った}{書き間違い}{下境界線}{上境界線}{邪魔臭い}{キー名}{視認性の悪さ}{損なわない}...=}(111)

{希哲16年1月17日17歩 K#F85E/A-E74C-835A}

キーボード記法改良終了

従来二重角括弧を使った [[X]] 記法に加え,アンダースコア組み合わせた [_X_] 記法使えるようにした

旧記法近いうちに廃止し,ウィキ互換輪結記法転用する。ハッシュタグ同様,単純に全知検索飛ばすだけだが,他サービスからの移行者デライト触りやすくなったり,デライト向け文書書き直しやすくする効果見込める

大きな用途変更であるため,時印によって適用版存切り替えることになりそうだ。

11日14歩検討方向性定まっていた旧記法導入した昨年3月11日はまだデラング整備最初期で,あまり他サービス他言語との互換性重視しておらず,他サービス採用例多かった二重角括弧による輪結キーボード記法使うことも,独自性を出すのに良いだろうという程度にしか考えていなかった

最近デラングが,デライトにとっての利益損なわない限り他サービス他言語との互換性最大化するという方針になっていることに加え,単純に旧記法視認性の悪さ気になっていたこともあった。最近ではほとんど自分で使っていなかった

[[Ctrl]] のようにキー名長さがあればまだいいが,[[X]] では流石に記号邪魔臭い[_X_] という記法は当時検討した記憶があるが,[X] に対して物足りず決め手に欠ける感じたか,なんとなく見送っていた[[X]] は「キー立体感を表現しているように見えなくもない」希哲15年3月11日2歩思っていたが,<kbd>装体デライトも含めて,四方み,立体感を出すため上境界線よりも下境界線目立たせるという形になることが多いため [_X_] の方がむしろ装体近い

逆括点を使った [`X`] という記法採用例を見かけて悪くない思ったが,まだ普及度低い上,これは `[X]` との書き間違い続出しそうだと感じたたため見送った[_X_] ならその問題もなく,直感性でこれに勝るものはなさそうだ。

<kbd>入れ子にすることも出来るので,[_Ctrl_] + [_X_] のような組み合わせ記法として扱うことを考えたが,実用上大きな変化はないはずなので後回し

{装体}
{}