{進捗記録}{希哲16年2月21日}{希哲16年2月21日の開発}{希哲16年2月21日の進捗}{振り分けられる}{第1階層見出し}{10種}{線種}{希哲16年2月15日24歩}{希哲16年2月21日の進捗時限}...=}(64)

{希哲16年2月21日9歩 K#F85E/A-E74C-2183}

進捗時限記録中略

昨日15日24歩についてまとめながら区切り線記法線種見出し階層関係について整理する必要感じたため軽くまとめて終了

下線形見出し階層区切り線用いる線種二本線一本線破線点線4種としていたが,それに対し,9日17歩考えた10種多過ぎる。どれが使えてどれが使えないのか,用者混乱させる懸念がある。

4種絞り込んでしまうことも考えたが,atx 式見出しとの互換性はともかく,10種極めて整合的なものではあり捨て難い

ここで,二本線一本線破線点線出放りとしつつ,他の線種でも代替出来るようにすることを考え始めた。つまり,10線種4階層振り分けてしまえばいい。以下のように,意外と綺麗に振り分けられる

<!-- 第1階層 -->

=====
+++++
*****

<!-- 第2階層 -->

-----
= = =
+ + +

<!-- 第3階層 -->

- - -
: : :
* * *

<!-- 第4階層 -->

. . .

これに装体指定機能持たせてもいいだろう。元々第1階層見出し下線太い一本線だったので,代替しても大きな違和感はない。各見出し階層相応しいように装体はいくらでも調整出来る。

=}
{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想定外だったのだろう。

{進捗記録}{Markdown}{部区}{希哲16年1月18日の開発}{希哲16年1月18日12歩}{行内埋め込み}{行内埋め込み記法}{書き分けられる}{視覚的な}{導入予定}...=}(161)

{希哲16年1月18日8歩 K#F85E/A-E74C-91F1}

進捗時限記録中略

埋め込み記法渡括記法)の応付子オプションなどについての検討終了

概ね方針が固まってきた

引数風の応付子

これまで埋め込み記法には,埋め込み方細かく指定するような機能がなく,例えば画像埋め込みでも表示サイズ水平方向寄せ方指定出来なかった。この問題当然当初から認識していたが,どうしてもごちゃごちゃしがちな部分なので,直感的美しい記法練るのに時間がかかった差し当たり欲しいのは画像埋め込み表示サイズ寄せ方指定出来る機能だが,他の埋め込み対象でも使える汎用的な枠組み整えておきたい

そこで,[寄せ方指定スペース]+([応付])[埋め込み対象]形式採用することにした。例えば,添付譜類PNG 画像100x100埋め込みたい場合,+(100x100)png書けるようにする。

丸括弧内は,函数引数風にコンマ区切りで,埋め込み対象毎に使える応付子設定する。引数名指定出来るように a=xa:x受け取ってもいいが,柔軟性必要なのであえて必須にはしない。スペースを含む文字列扱いたい場合考えられなくはないのでとりあえずコンマ区切りにしておくが,各引数扱い駒手欄感覚近い

他のとして,+100x100 png+100x100,png のように全てを引数的に扱うことも考えたが,あくまでも埋め込み対象とする応付役割まとまり一番分かりやすいという点で丸括弧採用する。また,埋め込み対象URL など長い文字列になることも多いため,応付+直後置く。あるいは,末尾に置く書き分けられるようにする。

水平方向寄せ方

水平方向寄せ方は,表組み記法採用予定スペースを使う方法応用することにした。以下のように,+ 前のスペース無しは無指定4つ未満は左寄せ4つ以上で中央寄せ6つ以上で右寄せとする予定

+png            <!-- 無指定 -->
  +png          <!-- 左寄せ -->
    +png        <!-- 中央寄せ -->
      +png      <!-- 右寄せ -->

直感性でいえば矢印のような記号導入することも考えられる。となるとまず <>使うことになるが,すでに多用しているため無闇役割広げる記号意味稀薄化しかねない。そうでなければ leftcenterright のようなキーワード導入するくらいしかないだろう。いずれにせよ,見た目的にもあまり美しくない

当初,以下のようにスペースの数表組み記法合わせようとした2つ中央寄せ3つ右寄せが,いくつか問題がある。

+png         <!-- 無指定 -->
 +png        <!-- 左寄せ -->
  +png       <!-- 中央寄せ -->
   +png      <!-- 右寄せ -->

まず,表組みにおけるセル内での編集に比べそこまで編集効率問題にならないためここまで短くする必要もなく,比較的長くなる後続文字列に対して目立ちにく過ぎる単純にスペース2つ中央寄せ3つ右寄せ表現には見えない

さらに致命的な問題は,いくつかの他記法との整合性だ。導入予定字下げ記法では,行頭全角スペース使う。あまり好き記法ではないが,Markdown4つの半角スペースを使う交度記法互換性のため導入する可能性がある。これらの記法混ぜ書いた場合,視覚的な整合性が取れない。

そこで,行頭に使う寄せ方指定スペース表組み記法とすることにした。交度記法にも使われる4つの半角スペース右寄せ一致するよりは中央寄せに一致した方が違和感がずっと小さい

行内埋め込み記法

おまけに,行内埋め込み記法についても少し考えた

これまで埋め込み記法部区として扱うことを主に考えてきたが,やはり行内埋め込み必要だろう。まだ草案段階だが,例えば以下のようにして画像回り込む段落が作れると便利だ。

++png++ 左上の画像に回り込む段落。
=}
{デラング}{進捗記録}{廃止}{組み合わせた}{キーボード記法}{見送った}{書き間違い}{下境界線}{上境界線}{邪魔臭い}...=}(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_] のような組み合わせ記法として扱うことを考えたが,実用上大きな変化はないはずなので後回し

{進捗記録}{駒手}{知番}{希哲15年12月23日の開発}{希哲15年12月23日の進捗時限}{希哲15年12月23日の進捗}{希哲15年12月23日}{自動知番譜台化}{譜台}{kn kno}...=}(33)

{希哲15年12月23日10歩 K#F85E/A-E74C-8E28}

知機駒手整備終了

kn kno に,譜台指定して実体readlink -f知番譜台だった場合に知番出力する機能追加

$ kn kno /kn/K#XX+/XX/XX+/XX-/XX+/XX.jpg
K#XXXX/A-XXXX-XXXX

あとは自動知番譜台化対応すれば一段落となる。自動知番譜台化では,元の譜台疎輪結置き換える機能加えることにした。

=}
{進捗記録}{駒手}{KNEST 駒手}{希哲15年12月20日の開発}{書けるようにしたい}{加えない}{余計な機能}{直接記述}{knest}{kn}...=}(40)

{希哲15年12月20日7歩 K#F85E/A-E74C-5845}

知機駒手整備終了

KNEST 駒手curl駒手直接記述したくないため,kn getkn pst のような駒手を通して通信させることにした。

ここで,URI 素決め knest活用することにした。希哲13年4月4日の開発でも考えていたが,実際には機会がなく実装しなかった。また,仕様独自性のあるものにしようとしていたが,まずは HTTP との互換性重視し,余計な機能加えないことにした。KNEST ドメイン直接記述避け knest:///書けるようにしたい

独自性持たせたい場合のため kn予約しておき,将来的に使い分けることにした。

=}
{開発}{開発記録}{付徴}{デライト}{WebP 統一}{大きかった}{非対応舞覧}{減らしたかった}{性能低下}{高負荷時}...=}(98)

{希哲15年9月3日の開発 K#F85E/A-E74C-339B}

気になっていたデライト高速化に関する問題をいくつか片付け出振るいした。結果として大きな体感表示速度向上が見られた。

離立備立デバッグ備立切り分け

やや混乱していた kn cpl などを整理しながら,離立備立デバッグ備立切り分けられるようにした。5月デバッグ出力整備デバッグ出力録出力切り分けておいたことも奏功し,作業円滑進んだ

これまで,本番環境でも deln.fcgilibxtdxpo.Pgデバッグ出力無効化していなかった。特に大きな負荷になる要素ではないが,高負荷時性能低下要因極力減らしたかった

精神衛生的な面でも効果が大きかった。長い実験段階を終え,一つの製品として完成に向かうデライト象徴する出来事のような気がして嬉しかった

デライトの WebP 対応

一般用者自我アイコンWebP 化完了し,添付画像を除き,現時点で出来るデライトの WebP 対応完了した。

添付画像仕様再検討

先月31日12歩ではすっかり忘れていたが,互換性問題があるため,当面は元画像WebP共存させておくことにした。特に,Safari対応遅かったため,まだ WebP への統一時期尚早だろう。

非対応舞覧市影小さく,デライトにおける譜類添付機能もそれほど本質的付徴ではないため,割り切って無視出来なくもないかとも考えた。いずれにせよ,気になるのはストレージ容量なので,それが問題になるまでは様子見することにした。

外部スクリプト選択的読み込み

輪郭を含むページ無条件読み込んでいた KaTeXhighlight.js を,必要場合だけ後縁出力させるようにした。

体感表示速度への影響はこれが一番大きかった

交度記法における言語管理にも応用出来る。

{application/xml}{text/xml}{application/rss+xml}{text/html}{Content-Type}{互換性}{RSS 2.0}=}(7)
{進捗記録}{利素}{交度}{デライト}{希哲14年9月26日の開発}{改装中ページ}{デライト集約}{希哲14年9月26日の進捗時限}{希哲14年9月26日の進捗}{希哲14年9月26日}...=}(37)

{希哲14年9月26日6歩 K#F85E/A-5B28-CDBB}

デライト用合い改良

途中で終了。

ここから大胆に交度譜類整理を進めるため,全ての利素デライト集約する「デライト集約」を本格化させる。

月庭との互換性はいったん無視し,当面はデライトのことだけを考えることにした。

月庭改装改装中ページ利用出来ることは14日4歩で書いたが,時期未定だった。

sss-1 への出振るいを避ければウェブ捌きの状態は維持出来るとして,出場月庭共有しているため何らかの問題が起きる可能性が高い。

月庭で何らかの異常が発生した時か,デライト大規模流入予期される時点切り替えることになるだろう。

=}
{互換性}

{}