{新生デライト}{上手くまとめる}{一定の水準}{大きな印迫}{暫定実装}{争っている}{具体的な作業}{大きな当努}{合間合間}{どうであれ}...=}(113)

{希哲16年4月3日の日記 K#F85E/E74C-2AE0}

のんびり作業しながら開発組計について整理した最近の脳爆発でまた混沌としてきた頭の中がだいぶ整理出来脳疲労感一気に和らいだ良い休日の過ごし方だ。


まず,第四次宣伝攻勢は,遅くとも黄金週間初日29日には始める多少の助走期間欲しいので,下旬出来るだけ早い内始めたい。その前に新生デライトの完成,と行きたいところだが,やや無理がある無理をして不眠不休やれば出来ないこともないだろうが,今のところそこまでの必要感じていない

無理のないところで,6月までの新生デライトの完成目指すことにした。ちょうど6月まで様子を見ることにしていたが,新生デライトさえ出来れば収益どうであれどうとでもなる。これが現状の最適解だろう。

宣伝認知されてから実際に流入始まるまでには多少の時間差もある。第四次宣伝攻勢前には,新生デライト当努のうち,訴求効果必要性高いものを優先して詰め込む

こまごまとした問題合間合間片付けるとして,大きな当努では,まず輪郭選り手抜控機能整備片付けたい今のところ最も長く中途半端なまま引きずっている当努で,心理的負担大きい先日終えた Aejs 整備目的でもあった。KNEST 隠し実装昨年から中断しているが,これは具体的な作業がほとんど出来なかったため,状態としては他の当努大差ない

その次は,Aejs 整備の再開前の Cμ 文字列処理改良り,1月29日12歩決めた通り,続いて描写渡括実装入る。さらにその次の優先順位をめぐって頭の中争っているのが,輪郭小窓暫定実装公開設定機能部分実装だ。どちらも用者体験にとって大きな印迫がある。集客する以上,高速化文書整備デラング整備一定の水準以上に進めておく必要がある

これらを黄金週間前に上手くまとめることが当面の目標になりそうだ。

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

{用者}{HTML}{HTML5}{デラング}{進捗記録}{高い}{あれ}{役割を持たせる}{役割を持つ}{緩衝的}...=}(248)

{希哲16年2月15日10歩 K#F85E/E74C-2CA8}

進捗時限記録中略

昨日寝る直前にまた脳爆発があり,今朝にかけて文字装飾記法タグ記法周りの概念整理仕様整理急速に進んだ

文字装飾記法は,「文字装飾を伴う慣用表現」のための記法位置付けることにした。太字記法##斜体記法//下線記法__打ち消し線記法~~翌日のまとめで「打ち消し記法」から改称4記法基本とし,それぞれ所定装体スタイルを伴う <b><i><u><s> HTML 要素対応する

@ を使った文字サイズ記法% を使った色記法検討していたが,タグ記法概念が出来たことで中途半端なものになるため,これは廃案とする。

文字装飾記法はこれがほぼ完成形か。

検討過程

3つ検討方針

実装自体は容易部類で,記法概ね固まっていたにもかかわらず文字装飾記法実装踏み切れなかった理由として意味論的な問題があり,これが思いのほか難題だった。実装方針3通り考えられる

  1. 完全に意味論的な記法にする
  2. 完全に装飾的な記法にする
  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年2月14日の開発}{損われる}{本質的ではない}{記述しやすい}{珍しくない}{大規模サイト}{迷惑行為対策}{運営上の都合}...=}(65)

{希哲16年2月14日15歩 K#F85E/E74C-5780}

越化エスケープ周りの客体表現化考えるついでに文字参照の越化について再検討して終了

HTML 越化仕様決めた昨年5月20日12歩以来越化目的使う可能性がある文字参照のみを許容していたが,これは修正し,いったん全ての文字参照許容することにした。

4日21歩でも再検討したが,越化記法同様デラングにおける特殊文字白表方式管理するのは無理がある損われる保守性に対して利点乏しい

当初制危というより迷惑行為対策など運営上の都合必要になるのではないかと思っていたが,Wikipedia はじめ大規模サイト開放されている珍しくなく,少なくともデライト言語仕様にするほど必要制限とは言えない。文字参照制危上致命的な問題があればそれは舞覧問題だろう。迷惑行為対策としてもあまり本質的ではない

何か問題があれば制限する,で十分なはずなので,実装都合制限してもいいことにする。

文字参照には,表示入力難がある文字記述しやすいという有用性一応ある。

=}
{出振るい}{silver}{進捗記録}{WhiteSmoke}{gray}{下線記法}{引用部区}{デライト}{希哲15年6月21日の開発}{希哲15年6月20日の日記}...=}(160)

{希哲15年6月21日9歩 K#F85E/E74C-A945}

強調輪符輪結装体リンクスタイルについてのまとめ

これまで輪符輪結装体1px #999破下線にしていたが,通常の線のlightgray引用部区ブロックなど WhiteSmoke 背景の上では silver と,かなり薄くした強調記法単独で囲まれた輪符に関しては,silver一本下線にし,少し目立つようにした。

これにより,輪結リンク重要性に応じてメリハリが付くようになり,重要性変調さりげなく示唆したいような場合は軽い強調はっきり強調したい場合は重い強調というように,強調記法と組み合わせた「強調輪符」の記法確立した。

輪符自体を強調するのではなく,参照名を強調したいのであれば内側に強調記法を置くことも出来る(例:軽い強調重い強調)。

経緯

長い歴史

輪符表示をどうするかという問題は,デルン最初期からの課題だった。

最初は重要な輪符を少しずつ貼り付けるような使い方しかしていなかったため大きな問題ではなかったが,いずれ文中輪符が増えてくれば,重要性によって表示し分ける必要が出てくる,というのは当初から想定していた。元々,入力道手メソッド機能自動補完などで文章のほとんどが意味符号になるような技術として構想していたからだ。

実際,デライト以後,私自身の慣れデライトの品質向上によって自然と文中に輪符が増えてきた。現在,私の描出ではほとんどの輪符であり,輪結になっている。こうなると,閲覧者にとっては,どこが重要な輪結なのか分からない上に,中途半端に目立つ輪結だらけで見にくいという問題が出てくる。

もう一つ,輪符に関する問題があった。輪符知名を変えて参照したということが分かりにくいという問題だった。輪符の知名を変えたということが読み手にとって重要なことがあるが,これまでそれを表現する良い手段が無かった。

どちらの問題も,少し前までは自動的解決出来るのではないかと考えていた。例えば,前景輪にある輪符自動的強調表示したり,知名と異なる名前で参照された輪符斜体にするなどということを考えていた

ただ,これは描出経験を積むにつれ無理がある感じるようになった。

まず,時として膨大になる前景輪に一致する輪符をいちいち見つけるのは現実的ではない。見えている10輪限定するのも不自然見え方になるだろう。輪符参照名をいちいち照合するのも軽い処理ではない。

描写隠し文字列でも埋め込めば負荷軽減にはなるだろうが,依然として無視出来ないコストではある。何より,出与え一貫性保守性深刻な影響を及ぼすことは目に見えている。

それ以前に,自動装体スタイリング適用すべきではない場合が多々あることも分かってきた。全知検索との兼ね合いも考えると,文中目立たせたい輪符引き入れたい輪郭はむしろ一致しないことの方が多い。

知名に関しても,例えば,「知る」という輪郭を「って」のように語形を変えて参照することも増えてきた。明らかに自動装体にすべきではない,瑣末な場合が多々ある。

最近では,デラング整備進展もあり,これは手動装体,つまり何らかの記法対応すべきなのではないか,と考えるようになっていた。

今日の進展

こうした問題解決に向けて本格的に考え始めたのは,まさに今日,昨日の日記を付けていた時に,「希哲15年6月20日の開発」という輪郭を「開発では」として参照した時だった。この「開発」が,一般的な意味での開発なのか,特定の日の開発を指しているのか,一見して分からない。これは以前からずっと気になっていた問題だが,そろそろ何とかしたいと思った。

重い強調を使ってみたりもしたが,重過ぎる。そこで軽い強調を使ってみることにしたが,軽い強調は欧文向けで,斜体伊体依存した装体は避けたかった。ここで,強調輪符下線調整することを考え始めた。

強調輪符をいかに目立たせるか,ということを考えているうちに,そもそも輪符輪結全般が目立ち過ぎていることに気付いた。というより,これまではこの輪結装体軽い参照重い参照表現していたので,気付いてもどうしようもなかった。ここで,通常の輪符と強調輪符でメリハリを付けることを考え始めた。

破線は太くすると環境によって全体的に大きくなり短いでは破線らしく見えなかったりするため,一本下線にすることを考えた。もともと点下線破下線一本下線輪結の強さ表現した装体で,一本下線は前景輪のために取っておいたが,前述の理由で未使用だった。ここで,輪結装体に関する問題全般と繋ってきた。

通常の輪符に関しては,いっそのこと下線類を無くしてもいいかと思ったが,流石に文字色だけでは心許無い視線の流れ K#F85E/A-E74C-AA16}を遮ることなく,視線を止めれば容易に輪結と視認出来る按配を{理想として,破下線を極力薄くすることにし,白背景なら lightgray引用部区など WhiteSmoke 背景の上では silver最適結論付けた

Firefox調整していたためもう一段濃い silver と darkgray の組み合せで決めかけたが,他の環境では破線密度の差でまだ濃過ぎるように見えたため,まとめ中に修正)

強調輪符一本下線に関しては,薄い色では弱いように思え gray を試したが,明示的下線を引きたい場合のために下線記法導入することも考えているため,兼ね合いであえて silver にしておくことにした。

まずは CSS のみでの出振るいonly-child で複数の輪符には効果が跨らないようにしてあるが,テキストノードは含まれうる。本来は一つの輪符のみを強調した時の効果であるべきだが,とりあえずは十分だろう。

総括

開発記録に書いておく。

{無理がある}

{}