{希哲16年5月17日の開発}{希哲16年5月17日の進捗}{新しい目印}{変わらなくなった}{目立たなくなる}{動的に}{効果は大きい}{発見しやすくなる}{機能の違い}{自然に学べる}...=}(89)

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

中景輪符改良

輪郭ページ知名選り手以外の知番輪結最大化アイコン追加していったん終了小さい変化だが効果は大きいだろう。

中景輪符知名輪結知番輪結役割動かしようがない旧デルン実装では,知名輪結輪郭ページび,再検索用に ?輪結置いていたが,再検索多用するので直感的な方がいい。輪符における知名知番役割から考えても単純性保ちつつ整合性を取るとこの形になってしまう。問題点として,初心者にはそれぞれの役割分かりにくかった

他方高さ固定解除する方法分かりにくいという問題もあった。最近最大化アイコン使った輪結をどこかに置くことを考えていたが,知番輪結同じ機能を別の輪結持たせる混乱を招く結局知番輪結固定輪結であり特定の輪郭注目する機能兼ねている,ということを自然に学べる用合い望ましい。ということで知番輪結一部であることが分かるようにした。

これによって,知番輪結機能分かりやすくなり,知名輪結との機能の違い発見しやすくなるだろう。

最近の一日一文で,読者高さ固定解除する方法気付きにくいという問題尚更気になっていた動的に解除する手段考えているが,これはこれで先々でも使えるだろう。

第零番節の省略自我知番の省略可能になることで知番目立たなくなるが,これで丁度良い感じになりそうだ。3月31日の開発輪郭ページ前後景検索ページ外観変わらなくなったため,新しい目印としても丁度良い

=}
{違了処理整備}{出振るい}{踏み切れた}{`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年2月22日}{希哲16年2月22日の開発}{希哲16年2月22日の進捗}{担わせる}{`4ja`}{有名無実化}{意識しない}...=}(159)

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

進捗時限記録中略

kitetu.comサブドメイン設計についての検討終了

今後デラングのように独立して参照出来るべき献典には積極的にサブドメイン与えていくことにした(例:dlng.kitetu.com


デラング的転回同時にデラング文書dlng.kitetu.com与えることを決めたが,これを機に知番SLFS 等々の公式文書にもサブドメイン与えることを考え始めた

これまでサブドメイン追加には消極的で,例えば技術系献典tech.kitetu.com集約することを考えていた。ただ,この手の URL 設計は,運営者にとっても閲覧者にとっても直感的でなく情報過多になりやすい上,階層的な整理難しいことも多々あり,変更に弱く参照可能性の低い URL が出来がちであるという問題があった。

こういう場合対策として,経験上最短原則」が最善であることは分かっていて,最近駒手にせよ各種識別子にせよ知名最短知名原則にせよ最短化する流れにある。サブドメインについてもこれに従うことにした。希哲館事業要素全て kitetu.com階層下にある,ということだけは確かだ。もちろん,これとは別に,階層的な情報源もあった方がいいので,そこは tech.kitetu.com などに担わせる

献典ドメインとしての独立性統一感同時に持たせられるのだから,むしろ,ここからがドメイン名統一本領発揮になりそうだ。

2文字サブドメイン問題解決

サブドメイン活用していく上で,一つ,「2文字サブドメイン問題」とでもいうべき問題があった

例えば,サブドメイン与えるなら cu.kitetu.com とするのが自然だが,CUキューバ国家符号だ。

ドメイン名統一によって ccTLD使わなくなっているため,将来的に地域別ドメイン欲しくなった時にはサブドメイン使うことになる。2文字サブドメイン使用避けるべきかもしれない,と考えていたキット*メーネmn.kitetu.comモンゴルMN被っているのが少し気になってはいた

ただ,その懸念も「もやもや」の域を出ていなかった明らかに紛らわしいサブドメイン最初から使わないので,被るとしたら普段意識しないようなものだ。被ったとして,ドメインハックccTLD有名無実化している今,そこまで神経質になることでもないだろう。そんなことのために,わざわざ不自然な表現もしたくない。とはいえ,サブドメイン選択肢多い越したことはない

そこで,国家符号表す何らかの接子導入考えたFacebook のように,ja-jp言語符号付きを基本として,言語符号がいらない場合は x-jp のように表記出来るようにするかとも考えたが,少し野暮ったい

最終的に4 接頭子導入する方向検討進めることにした。例えば,キューバ向けのドメイン4cu.kitetu.com として cu.kitetu.com区別出来るようにする。衝突しなければ 4 接頭子省略してもいいし,4ja のように言語符号に代えられてもいいだろう。4ja-jp のような表現が出来てもいい。これなら十分な簡潔性柔軟性兼ねられる

例えば 4jp.kitetu.com なら www.kitetu.com変わらない標準的な長さだし,むしろお洒落感すらあるので,これで統一して,4 接頭子無しは転送用にしてもいいくらいかもしれない。

いまのところ地域別ドメイン必要は感じておらず,将来的に必要になるかもしれない,という程度の問題なので,細かいこと追い追い決めるとりあえず理論上すっきりしたので良かった

=}
{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月18日の開発}{あれ}{文章の流れ}{左右矢印}{下矢印}{上矢印}{使うべきではない}{右矢印}{使われない}...=}(171)

{希哲16年2月18日13歩 K#F85E/A-E74C-E223}

進捗時限記録中略

前後記法」として検討していた記法を「前次記法」に改め仕様再検討して終了

<- 前 | 次 ->

<- 前
次 ->

<- 前のみ

次のみ ->

以上のように,<- 前 | 次 ->基本形とし,改行区切り<- 前次 -> のみでの記述可能にすることにした。


デルンにあった類似機能から,「時間(時印)的な前後関係」を表現する記法として「前後記法」と呼んでいたが,文書では新旧にかかわらず読ませたい順序指定出来る方が便利なので,より汎用的な前次記法」と位置付け直した

新旧表すのに「」や「」というのはよく考えるおかしいという意見もあり,私も何か良い代替表現はないかと考えていたが,慣用表現として定着しているのでこれは仕方ない前ページ次ページというように,左開きページめくっていく感覚なのだろう左開き右開き書字方向との相性問題なので,ウェブになることが多いのは一応合理的ではある)


前回の検討では,以下のように書いていた

前 <|> 後
前 <|
|> 後

これは他記法区別しやすく簡潔ではあるが,見本はともかく少し長い文字列が入ると記号埋もれがち直感的とも言い難い視認性考えると,行頭行末分かりやすい記号があってほしい。

また,<|>タグ記法使う予定</>紛らわしい|始まる長い文字列があると,初心者には表組み記法誤認される恐れもある。


他記法との区別しやすさ簡潔性直感性などを総合的に考慮した結果最も素直な記法であろう <- 前 | 次 ->落ち着きつつある

雑多な考慮点列挙しておく。

=}
{進捗記録}{希哲16年2月13日の開発}{単独行}{無理なく}{希哲16年2月13日の進捗時限}{希哲16年2月13日の進捗}{自動取得}{代替記法}{希哲16年1月19日1歩}{輪結記法}...=}(36)

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

デラング整備輪結記法についての検討終了

1月19日1歩考えた URL省略記法だが,これは [https://example.com/abc ... xyz] という形式導入することにした。これなら無理なく直感的だろう。

前々から考えていたリンクカードは,とりあえず,単独行[https://example.com] での導入考える長い URL の場合に,[] https://example.com という代替記法があってもいいかと思っていたが,これはチェックボックス記法紛らわしいためとする。いずれにせよ,これ以上分かりやすい記法もないだろう。

行内[https://example.com] を使った場合には題名自動取得するなどの機能があってもいい。

=}
{デラング}{ラテン文字}{進捗記録}{パンくず記法}{注意記法}{補足記法}{折り畳み記法}{感じさせてくれる}{歴史的な意義}{今となっては}...=}(166)

{希哲16年1月20日8歩 K#F85E/A-E74C-2FC4}

進捗時限記録中略

ひょんなことから予てから課題だった折り畳み記法急速にまとまった

折り畳み記法は,他の部区記法組み合わせ使える汎用的な記法として実装していくことにした。以下のように,部区開始行末^加えることで,その部区見出しなら階層下内容折り畳まれるようにする。厳密に言えば見出し階層下内容含む部区ではないが,例外的に扱う

・リストの折り畳み ^
  ・折り畳まれる項目

* 折り畳む見出し ^
折り畳まれる内容

+{埋め込みの折り畳み K#XXXX} ^

検討中,これがネタバレNSFW のような閲覧注意内容使えそうなことにも気付いた

きっかけからまとまるまで

補足記法・注意記法についての検討で,終了記号区切り線--)も使えるようにすることを考えた時,以下のように区切り線亜種として ^^ を使って折り畳めることをしてもいいのではないかと思い付いたことがきっかけだった。

?? 補足
補足内容
^^

この終了記号のように,他の部区にも統一的に応用出来る記法があれば何かと可能性が広がる。そこであれこれ検討してみると,部区終了記号だけでなく開始記号側にも分かりやすい目印欲しくなった。むしろそちらの方が自然場合多い

^対応する記号なら v考えられるが, などと異なり自然言語扱うデラングラテン文字導入しにくい日本語はともかく外国語問題が起きないとも限らない

何より下向きの三角形一般に展開されていることを表す記号なので,折り畳まれている記号として v開始記号添えるのは直感的ではない。となると,<>デラングではある程度活用方向性決まっているので,矢印的に使えそうASCII 記号^ しかない。

ここで,「行末^」を思いついた。これなら折り畳み記号としての直感性もあり,他記法とも組み合わせやすいパンくず記法で「行末>」を採用する直前にあっただが,微妙な違和感があり回避していた。この直感大当たりだった。

そして終了記号^^ とも整合的見える……と考え出したところで,今度はこっちの問題気になってきた。まず,日本人感覚ではぱっと見顔文字見える。そこで,--亜種であることが分かりやすいように --^考えてみたが,空行挟まない特定の文字指しているような記号見える

そもそも開始行末1個あれば,特別な終了記号要らないことに気付くまで時間はかからなかった結果的に非常にすっきりしたになった。

他の検討案

昨年6月18日の開発時点からは,以下2案があった。

++ ラベル
折り畳まれる内容
--

? ラベル
折り畳まれる内容
!

前者がこれまでの最新案で,区切り線--対応させて,++使うツリー開閉記号しばしば +-使われることに引っかけただったが,埋め込み記法渡括記法との紛らわしさから現時点での採用考えにくい。特に最近では ++使った行内埋め込み記法有力視していることもあった。無理に区別出来なくはないが,意味的な整合性確保するのが難しい

後者は,補足記法注意記法方向性固まった今となっては採用余地皆無だが,当時から今回の検討きっかけになった補足記法との組み合わせ考えていたことを示すであり,歴史的な意義感じさせてくれるものではある。

{直感的}

{}