にしし らぼらとりー

Fumy News Clipperの動作サンプルの公開をひっそり終了した。ここに書いたら「ひっそり」ではないかもしれないが。「Fumy News Clipper」は2000年代に開発したCGIで、「てがろぐ」の前身になったCGIである。Fumy News Clipper側に存在する機能の大半は、てがろぐ側にもある。本文中にHTMLを直接書ける機能だけはFumy News Clipper側にしかないので、今でもCGIの配布自体は続けているが（てがろぐ側にその機能ができるまでは公開は続ける予定ではある）。もはや継続開発の意欲はないことと、何でも書ける動作サンプルがありすぎると管理しきれないので、サンプルだけは閉じることにした。（『表示はできるが投稿はできない』というようなデモモードを搭載していれば良かったのだが、Fumy News Clipperにはそういう仕様を用意していないので。いまさら追加するのも面倒だし、もはや需要もそこまでないだろうから。）

国立国会図書館サーチのAPIを使うと書影データは手に入るのか。これで蔵書管理スクリプトを自作すればいいか……？ 何をいつ読んだか、という情報だけでなくて、「その本がどの電子書籍リーダーに入っているのか」の情報を記録しておきたい。そうしないと読み返そうとしたときに探すのが大変なので。

もうちょっとデータファイルから無駄を省くようにした方が良いだろうか。ファイルサイズを減らすために。カテゴリに属していない投稿に <cat></cat> とか、フラグが何もない投稿に <flag></flag> とか記録しても無駄だものな……。総投稿数が少ないうちは、微々たる差ではあるけども。

カスタム絵文字のデフォルトCSSには、やはり max-width:2em; も出力しておく方が望ましいのかな。絵文字が全部縦横同じ（正方形に収まる）とは限らず、横長の絵文字も使われるのではないかと（Misskeyを見ていて）思うので横幅は制限しないままで居たのだが。まあでも、iOS版Safariだけの問題のようだしな……。どうするのが良いのか。まあ、本格的に絵文字で遊ぶ人々は、デフォルトCSSを切って自力でCSSを書いて使うかもしれないので、デフォルトでは max-height も max-width も両方 2em にしておく手でも良いかもしれないのだが。

カスタム絵文字を本文に直接書いたとき、それをクリックしたら、その絵文字のコードがコピーされるようなJavaScriptを出力するオプションも用意しようかな……。ああ、でも、誤ってクリックしてしまった場合に、利用者のクリップボードの中身を書き換えてしまうことになるから、避けた方がいいか……？ シングルクリックではなく、ダブルクリックにしたらいいか？ ダブルクリック仕様で加えた(v4.0.5)。設定でOFFにもできる。

カスタム絵文字一覧画面にもページネーションは要る……？ カスタム絵文字を200個とか300個とか大量にUPする人は居るだろうか……？

てがろぐにもログインボーナス機能を加えようかな。毎日管理画面にアクセスしたら石1個🪨。投稿したら石10個🪨🪨🪨🪨🪨🪨🪨🪨🪨🪨。石の用途は特にない。

外部サービスの何か（ツイートとか動画とか音楽とか）を埋め込む場合、てがろぐではURLの前に [Tweet] とか [YouTube] とかのラベルを書く仕様になっているが、よく考えると「何のサービスなのか？」はURLのドメインから明らかなので、別にラベルを個別に分ける必要性はないのよな。[Tweet] とか [YouTube] とか書き分けなくても、全部 [Embed] ラベルで良いような仕様にしても良い気がしてきた。（もちろん、従来のラベルを廃止することはない。） [Embed] に続いてツイートのURLがあればTwitterの埋め込み処理をすれば良いし、[Embed] に続いて動画のURLがあればYouTubeの埋め込み処理をすれば良いし……。というのでどうか。そうすると、投稿欄の下にある各種埋め込みボタンも「総合埋め込みボタン」1つだけで済むメリットがある。

管理画面の「設定」ページを生成するソースをリファクタリングしている。ブラウザ上での見た目は一切変わらないのだが、後々カスタマイズしやすくなるような気がする。なんとなく。ただ、具体的な計画がない段階でのリファクタリングは、もしかしたら不毛なのでは……という気もしないでもないのだけども……。まあ、プログラムサイズ（ソース分量）がいくらか減るメリットはある。

Re:2212◆それよりも、てがろぐ管理画面内の「画像管理」側で、「その画像に対する代替文字とキャプション」をあらかじめ登録しておける仕様にしておいて、[PICT:画像ファイル名] だけなら画像だけ、[PICT:(オプション):画像ファイル名] なら、オプションに「A」があれば代替文字(alt)を出力、「F」があればfigure要素＋img要素で出力、「C」があればfigcaption要素でキャプション(C)を出力……みたいな感じにできる方が楽で便利かもしれない（事前に登録可能にする実装が面倒だが）。ただ、それだと臨時のキャプションが付けられないか。

画像にキャプションを加えてインライン掲載できるような記法を作りたい。代替文字ではなく。代替文字(alt属性値)を指定する記法は既にある（→ [PICT:ファイルパス] ではなく [PICT:代替文字:ファイルパス] と書く）ので、この記法を維持したまま何らかの拡張をする必要がある。代替文字の指定方法をもうちょっと何か汎用的にするべきだった。orz 代替文字をそのままキャプションにする方法でも悪くはないとは思うが、「代替文字は指定したいがキャプションにはしたくない」みたいな場合もあるだろうから、やはり別に設けた方が良いだろう。

例えば、
figure要素を出力するための [FIG:画像記法:キャプション] というカバー記法を用意しておいて、その内側に既存の画像記法を挿入して [FIG:[PICT:代替文字:ファイルパス]:キャプション] と書くと、<figure class="pictbox"><img ～ alt="代替文字"><figcaption>キャプション</figcaption></figure> みたいに出力されるとか？ ただ、見た目が複雑になるので、よほど記憶力が良くないと使えなさそうな気がするから、望ましくはなさそうだ。（内側に画像以外も含められる可能性があるので汎用性は高まるけども。）

例えば、
[PICT:代替文字:キャプション:ファイルパス] とすることで代替文字とキャプションを指定できる方法にすれば簡単だが、この方法だと「ファイルパス以外の文字列」が1つだけ存在するとき、「代替文字が省略されたのか、キャプションが省略されたのか」の判別ができない。まあ、キャプションを指定したい人が「代替文字は出力したくない」と思うケースは少なそうな気はするので、これで良いのかもしれないが。

この「figure要素＋figcaption要素」で画像とキャプションを掲載できる仕組みがあれば、「キャプション付きの画像を横並びで掲載する」みたいな表示方法が簡単にできるメリットがある。

てがろぐCGIだけを使ってサイト制作するような凝った使い方をする方々のために、パーツ単位で出力できる機能があると（もしかしたら）便利なのかもしれない。?part=searchboxで検索窓HTMLだけを出力するとか、?part=quickpostでQUICKPOST(投稿欄)HTMLだけを出力するとか、?part=hashtaglistでハッシュタグリストのHTMLだけを出力するとか。そうすると、SSIとかPHPとかJavaScriptとか好きな技術で静的ページに合成して、いろいろ活用しやすいのではないかな……。

その投稿に含まれる1つ目の画像だけを挿入できる [ONEPICT:1] 記法では、画像が含まれていない投稿の場合には何も挿入されないが、『画像がない投稿の場合はデフォルトの画像を挿入する』みたいなオプションがある方が、デザインを作りやすい気がする。

実装がそこそこ複雑になるのだが、やはり連結返信機能があると望ましいな……。各投稿にユニークな「スレッドID」を割り振っておいて、同じスレッドIDが割り振られている投稿だけを閲覧する仕組み（カテゴリ等と同様に）を作っておけば、一連の返信だけをずらっと並べて閲覧することは可能だろう。検討する必要があるのは、どのタイミングでスレッドIDを割り振るか、ということくらいな気がする。スレッドIDも自由に再編集可能なUIを用意しておけば、後からスレッドの連結状態を調整するのも簡単だろう。Twitterのようにシステム側が決め打ちで繋げてしまうと、連結に失敗したときや後から連結を解除したくなったときに面倒だから、再編集機能は必須と考えておいた方が良さそうだ。