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

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

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

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

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

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

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

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


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

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


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


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

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

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

{開発}{開発記録}{選り手}{下見ボタン}{下見機能}{Meson}{新生デライトの要件}{日本語表現}{プレビュー機能}{開閉状態}...=}(109)

{希哲15年8月1日の開発 K#F85E/E74C-7A28}

新生デライトの要件

もう考えていても仕方ない段階に来ているので,とりあえず雑に書き出しておく。

舞覧手定め環境整備

舞覧手定め環境整備一環として,SLFSChrome59最新版92更新

3月15日7歩でも試みているが,その時は libxkbcommon不足失敗依存性地獄懸念して中断した。

libxkbcommon引装には MesonNinja の引装が必要で,Meson と Ninja には Python 3 の引装が必要だったものの,それ以外に直接必要なライブラリはなく,意外とあっさり更新出来た。

これで SLFS では FirefoxChrome最新版が使えるようになり,手定め用iPhone 7近日中手に入る予定なので,舞覧手定め環境整備はここで一段落とする。

Android 端末向けの舞覧手持ちのスマホで,Edge 含め,Windows 向けの舞覧Windows 仮想機で使える。

実機仮想機では主に最新舞覧を使い,古い舞覧などは LambdaTest などのサービス利用すれば十分だろう。

輪郭選り手抜控機能整備など

描き直し選り手同期するように調整

とりあえず,選り手が開いている場合に内容同期させるようにだけしておいた。これで複数窓で同じ輪郭の選り手が開いていても混乱しにくくなり,内容が長い場合には複数窓で別々の箇所を編集することも出来るようになった。

現状,抜控のある選り手はページ読み込み時に開くようになっているが,閉じている場合でも別窓で抜控が出来た場合は開いたり,別窓で閉じた場合は自動的に閉じたりと,開閉状態同期もしようかと思っていた。これは止めておいた。

開閉状態の同期はしない方が,一方の編集用にして,一方の窓を確認用するなどといった応用の可能性が広がることに気付いた

現状では描き直し完了選り手閉じる機能的に一緒になっているが,複数窓有効活用を考えると保存と閉じるで分離すべきか。取り消しボタンを閉じるために使うかと思ったが,操作性を考えると,今の完了ボタンを保存・閉じるの二段階にする方向が良さそうだ。

そんなことを考えているうちに,保存せずに換配後プレビューが出来る機能についても検討し始めた。概念操作複雑化を避けることを考えるなら,完了ボタン機能現状維持プレビュー機能本命かもしれない。

プレビュー日本語表現は「確認」が分かりやすいだろう。内部的には「換配確認機能」や「確認ボタン」と呼んでおくことにした。

=}
{二段階}

{}