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

{希哲16年2月15日24歩 K#F85E/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想定外だったのだろう。

{進捗記録}{廃止}{Markdown}{デライト}{希哲15年7月6日の開発}{希哲15年7月6日の進捗時限}{希哲15年7月6日の進捗}{希哲15年7月6日}{表示環境}{読み手の好み}...=}(72)

{希哲15年7月6日8歩 K#F85E/E74C-87B0}

デラング整備段落記法段落装体改行仕様再検討

いったん終了。

これまで,段落間の余白0.5emほど開けて1em分の字下げtext-indent設定していたが,自動字下げ廃止し,代わりに字下げ記法導入することにした。

字下げ記法では,行頭に所定のスペース(例えば日本語なら全角スペース1つ)を置くことで text-indent設定出来るようにする。Markdown 等で採用されている4つの半角スペースでの交度記法などの導入をどうするかはまだ決まっていないため,まずは衝突しないように限定的な導入に留める。

また,改行については,これまで通り1行の空行段落分けに使い,半行分の余白を開ける。2行の空行で1行分の余白,それ以降は1行分ずつ余白を追加していくように装体厳密化する。

字下げ記法により改行無しで段落を表現出来るようにすることも検討する。この場合,段落間余白無しで字下げのみを使った段落表現も出来るようにする。

これにより,多様段落装体対応出来る。


段落の字下げは,段落間の余白とともに文書の性質書き手読み手の好みによって制御出来るようにしておいた方がデライト活用範囲広がるだろう。

従来の段落装体は恐らくデルン最初期調整したもので,長い文章を書く時は便利に感じていたが,例えば,どんな表示環境でも改行されないような一言程度でも字下げが入るため,内容によっては不自然行頭が揃っていないように見える,といった問題があった。

段落間の余白を広げ過ぎると縦の空間消費し過ぎかえって視認性問題があるため,代わりに字下げ導入したような微かな記憶がある。

ただ,日本語版 Wikipedia でも英語版 Wikipedia でも0.5emの段落間余白で字下げ無しという装体なので,特別読みにくいということもない。

最初は字下げ無しを指定出来るような記法導入することを考えたが,そんなややこしいことをするくらいならこちらの方がすっきりするだろう。

{開発}{開発記録}{道手}{正規表現の単純化}{希哲15年6月19日の開発}{客体指向正規表現}{正規表現の複雑化}{Objex}{類型化}{類型化正規表現}...=}(27)

{希哲15年6月20日の開発 K#F85E/E74C-EADA}

定休日だったが,昨日の開発で感じた正規表現周りの課題についてよく考え,概ね方針まとまった

名前付きキャプチャを利用することも考えたが,保守性を考えると中途半端だ。そもそも正規表現は可読性が良いものではないので,正規表現の複雑化は避けたい。

正規表現の単純化をしつつ保守性機能性を保つ手段として,とりあえず特定正規表現の類型クラス採用することにした。これで複数の正規表現をまとめやすくなり,道手メソッドを通して参照厳密化出来る。

これを「類型化正規表現」と呼ぶべきか「客体オブジェクト指向正規表現」と呼ぶべきか少し迷った。「Objex」という略称は捨てがたいが,より厳密な前者で呼んでおくことにした。

{進捗記録}{輪郭整備}{握接}{知番}{最短知名原則}{完全名称}{Firefox}{短い名前}{扱い方}{希哲15年6月5日の進捗時限}...=}(41)

{希哲15年6月5日6歩 K#F85E/E74C-4D4A}

描出通称原則についての検討で終了。

固有名詞などで複数の表記がある場合,原則として認識しやすい通称とすることにした。

輪郭整備体系化を考え始めたこともあり,表記揺れが発生しやすい知名扱い方について方針を決めておきたかった。

これまでは特に方針もなく,感覚的に知名を付けていたが,どちらかというと長い名前正式名称完全名称など)を主とすることが多かった(例:FirefoxMozilla Firefox

これは Wikipedia 等でよく行われている方法だが,ウィキと異なり知番のあるデルンでは名称厳密化する必要は無く,短い名前の方が全知検索との相性が良い

経験上,正式名称を主にしているつもりでも,結局すぐ握接出来る通称の方に引き入れすることが多くなっていたりする。

=}
{開発}{開発記録}{場筋}{自我アイコン設定機能実装}{希哲15年2月7日12歩}{希哲15年2月5日}{独自アイコン}{自我アイコン}{検索演心教育}{吊るし検索}...=}(26)

{希哲15年2月5日の開発 K#F85E/E74C-211B}

自輪郭検索厳密化作業に入る。

細かい問題は概ね修正したが,吊るし検索との調整に難しい部分があったこと,意外に現行仕様も悪くない気がしてきたことでいったん保留することにした。

右上の×に自輪郭検索を反映させようとしていたが,よく考えてみれば自輪郭検索に戻るのは自我アイコンから出来るので現行仕様で十分かもしれない。これは独自アイコンにしてみたことによる心証の変化か。

その他,場筋の問題で機能しない部分が多くあった正規 URI 経由の輪郭ページ修正正常化するなどした。これのせいで外部サイトで正規 URI を紹介出来ず不格好だったので良かった。ついでに長らく設定していなかった canonical も設定し,検索演心教育上の効果も見込める。

自我アイコン設定機能実装再開する前に片付けておきたかった細々とした問題は片付いたため,明日から再開する。

{厳密化}

{}