てがろぐ
- Fumy Otegaru Memo Logger -
カテゴリ「回答/返信」に属する投稿［669件］（14ページ目）
No.2666で、以下のようなご要望(ご質問)を頂きました。
Ver 3.7.2βで実装した検索コマンドを使って、 -$ci=; という検索語で検索すると、上記のご要望を実現できるようになりました。
そうできる背景の説明：
●検索コマンド $ci=; で「カテゴリなし」だけがヒットします。これは従来からあるパラメータ ?cat=- の表示結果と同じになります。
●この検索コマンドと除外検索機能を使って -$ci=; で検索すると「カテゴリなし以外全部」(＝何らかのカテゴリに属しているすべての投稿)をヒットさせられます。畳む
稼働例：
➡何らかのカテゴリに属している投稿のみを表示する
カテゴリなしの投稿を出力したい場合は「cat=-」というパラメータで可能かと思うのですが、この逆で何らかのカテゴリに属する全ての投稿を出力する「cat=+」みたいなことってできますでしょうか？
Ver 3.7.2βで実装した検索コマンドを使って、 -$ci=; という検索語で検索すると、上記のご要望を実現できるようになりました。
そうできる背景の説明：
●検索コマンド $ci=; で「カテゴリなし」だけがヒットします。これは従来からあるパラメータ ?cat=- の表示結果と同じになります。
●この検索コマンドと除外検索機能を使って -$ci=; で検索すると「カテゴリなし以外全部」(＝何らかのカテゴリに属しているすべての投稿)をヒットさせられます。畳む
稼働例：
➡何らかのカテゴリに属している投稿のみを表示する
全文検索で、カテゴリID・カテゴリ名・投稿日時・ユーザID・ユーザ名・投稿番号でも検索できる（どれを検索対象にするかは自由に設定できる）ようになった Ver 3.7.2（未配布）の動作テスト。
🍧Re:2940◆なるほど……、写植機みたいな感じなんですかね（いや、写植機についてもよくは知らないのですけども^^;）。資格もあったとは。その当時から罫線はあったんですねえ。どうせ文字数が多いのなら、記号も含めれば便利になりますものね。◆かなタイプライターは電信用と。なるほど。そういえば電報というサービスがありましたね……。
🍧Re:2941◆そうですね、FREESPACEを活用すると実現できますね。その際は、「入力した改行は、実際の表示上でも改行する」項目をOFFに設定すると自動で<br>が挿入されてしまうのを防げるのでHTMLを書きやすいと思います。また、tegalog.cgiの54行目付近にあるmy $safemode = 1;の値を0にすると、script要素も書けるようになります。ユーザフレンドリーにしようと思うと、やはりスキンの切り替え画面でCSSだけを切り替えるとかの機能がある方が良いでしょうけども、とりあえず今の時点で自力で何とかしたい場合にはFREESPACEを活用する手はありますね。
🍧Re:2940◆なるほど……、写植機みたいな感じなんですかね（いや、写植機についてもよくは知らないのですけども^^;）。資格もあったとは。その当時から罫線はあったんですねえ。どうせ文字数が多いのなら、記号も含めれば便利になりますものね。◆かなタイプライターは電信用と。なるほど。そういえば電報というサービスがありましたね……。
🍧Re:2941◆そうですね、FREESPACEを活用すると実現できますね。その際は、「入力した改行は、実際の表示上でも改行する」項目をOFFに設定すると自動で<br>が挿入されてしまうのを防げるのでHTMLを書きやすいと思います。また、tegalog.cgiの54行目付近にあるmy $safemode = 1;の値を0にすると、script要素も書けるようになります。ユーザフレンドリーにしようと思うと、やはりスキンの切り替え画面でCSSだけを切り替えるとかの機能がある方が良いでしょうけども、とりあえず今の時点で自力で何とかしたい場合にはFREESPACEを活用する手はありますね。
今年は梅雨明けの後にまた梅雨入り……？
🍧Re:2928◆はい。全角空白文字は「区切り」としては認識せず、文字として扱う仕様になっています。本当なら全角空白文字も「区切り」にした方が良いと思っているのですが、（全角空白文字が区切りになっていない問題に気付いた時には既に）全角空白文字を含むハッシュタグを使っているユーザさんが居る可能性もあったので、修正せずにそのままの仕様にしてあります。……が、どうなんでしょうね……。全角空白文字をハッシュタグに含めているユーザさんが果たしてどれくらい居るのか。(^_^;) もしかして、今からでも仕様変更して、全角空白文字は「区切り」として認識するようにする方が良いのかな……という気もしなくもないのですが。
🍧Re:2929◆腕の確かな看護師さんは本当にサクッと針刺せるんですよね……。私の腕をぐりぐり押したりバシバシ叩いたりせずに1発で刺せる看護師さんを見かけると、この人すごいな、と思います。(^_^;)
🍨Re:2931◆なるほど、CSSだけを切り替えられる機能というのも、あると良いかもしれませんね。「Twitterっぽいスキン(ブルー)」と「Twitterっぽいスキン(ピンク)」は、CSSが異なるだけでHTMLは全く同一（コメントの文字は異なりますがHTMLとしては同じ）なのですけども、CSSだけを切り替えられる機能があれば、これらのスキンは単一のスキンとして配布できましたね……。それに、他の配色の提供も楽になりそうですね。スキンを格納しているディレクトリに「altcss」というサブディレクトリがあるとき、そのサブディレクトリの中に入っているCSSファイルを「切り替え用の別CSS（Alternate CSS）」と解釈して、管理画面上で切り替えられる機能とかがあったら便利でしょうかね……？ そういう機能があれば、CSSだけの配布もしやすそうですし。
🍧Re:2932◆さすがにtDiaryはテーマの数が多いですね。
🍧Re:2933◆古い記事を発掘して下さってありがとうございます。古すぎるので、もはやページ上のサンプル表示用JavaScriptが動作しませんね。(^_^;) All About側のシステム変更で、たぶん記事に直接埋め込まれたJavaScriptはもう動かないようになっているのだろうな……と思います。「➊記事中にJavaScriptを埋め込む必要があるジャンルの執筆者は2～3人しか居なかったこと」＆「➋もはやIT系の記事は（世の中にあふれすぎていて）広告で儲ける題材としては扱いにくいこと」あたりの理由から、最近のシステム変更では「本文中にサンプルを埋め込んでいる記事」への考慮はもはやなくなっているのだろうな、と推測しています。
🍧Re:2934◆解説がお役に立ったようで良かったです。(╹◡╹) 全然知らなかったんですが、確かに今のActivePerlは、ダウンロードするためににGitHub連携かアカウント作成が必要になっているっぽいですね。いつの間に……。Perl公式でもActivePerlとStrawberry Perlの2つがWindows向けに紹介されているんですね。これも知りませんでした。Strawberry Perlはダウンロードが極めて簡単な点が良いですね。
🍨Re:2935◆てがろぐの場合は、やはり「ベースになるHTML」が何種類か存在している状態で、それら個別に対応する「着せ替え用CSS」（ベースが異なる場合は適用できない）という形である必要があるでしょうかね。
🍨スキンの仕様は従来通りにしつつ、1つ「着せ替えCSSを適用する専用のベーススキン」という特殊なスキンを1つ用意しておいて、そのスキンに対してだけは「着せ替えCSSをアップロードするだけで管理画面上でCSSを切り替えられる」みたいな仕様の方が、CSSを作りやすくて良いのかもしれませんけども……。つまり、「着せ替え用ベーススキン向けのCSSだけで望みのデザインが実現できるなら着せ替え用CSSを作る」方法で済ませて、それだけでは済まない場合には（従来通り）「HTML×2＋CSSのスキン（フルセット）を作る」方法を採用する……みたいな感じで。
何か「こうなっているとスキンが作りやすい」みたいなご要望があればぜひお知らせ下さい。
🍧Re:2928◆はい。全角空白文字は「区切り」としては認識せず、文字として扱う仕様になっています。本当なら全角空白文字も「区切り」にした方が良いと思っているのですが、（全角空白文字が区切りになっていない問題に気付いた時には既に）全角空白文字を含むハッシュタグを使っているユーザさんが居る可能性もあったので、修正せずにそのままの仕様にしてあります。……が、どうなんでしょうね……。全角空白文字をハッシュタグに含めているユーザさんが果たしてどれくらい居るのか。(^_^;) もしかして、今からでも仕様変更して、全角空白文字は「区切り」として認識するようにする方が良いのかな……という気もしなくもないのですが。
🍧Re:2929◆腕の確かな看護師さんは本当にサクッと針刺せるんですよね……。私の腕をぐりぐり押したりバシバシ叩いたりせずに1発で刺せる看護師さんを見かけると、この人すごいな、と思います。(^_^;)
🍨Re:2931◆なるほど、CSSだけを切り替えられる機能というのも、あると良いかもしれませんね。「Twitterっぽいスキン(ブルー)」と「Twitterっぽいスキン(ピンク)」は、CSSが異なるだけでHTMLは全く同一（コメントの文字は異なりますがHTMLとしては同じ）なのですけども、CSSだけを切り替えられる機能があれば、これらのスキンは単一のスキンとして配布できましたね……。それに、他の配色の提供も楽になりそうですね。スキンを格納しているディレクトリに「altcss」というサブディレクトリがあるとき、そのサブディレクトリの中に入っているCSSファイルを「切り替え用の別CSS（Alternate CSS）」と解釈して、管理画面上で切り替えられる機能とかがあったら便利でしょうかね……？ そういう機能があれば、CSSだけの配布もしやすそうですし。
🍧Re:2932◆さすがにtDiaryはテーマの数が多いですね。
🍧Re:2933◆古い記事を発掘して下さってありがとうございます。古すぎるので、もはやページ上のサンプル表示用JavaScriptが動作しませんね。(^_^;) All About側のシステム変更で、たぶん記事に直接埋め込まれたJavaScriptはもう動かないようになっているのだろうな……と思います。「➊記事中にJavaScriptを埋め込む必要があるジャンルの執筆者は2～3人しか居なかったこと」＆「➋もはやIT系の記事は（世の中にあふれすぎていて）広告で儲ける題材としては扱いにくいこと」あたりの理由から、最近のシステム変更では「本文中にサンプルを埋め込んでいる記事」への考慮はもはやなくなっているのだろうな、と推測しています。
🍧Re:2934◆解説がお役に立ったようで良かったです。(╹◡╹) 全然知らなかったんですが、確かに今のActivePerlは、ダウンロードするためににGitHub連携かアカウント作成が必要になっているっぽいですね。いつの間に……。Perl公式でもActivePerlとStrawberry Perlの2つがWindows向けに紹介されているんですね。これも知りませんでした。Strawberry Perlはダウンロードが極めて簡単な点が良いですね。
🍨Re:2935◆てがろぐの場合は、やはり「ベースになるHTML」が何種類か存在している状態で、それら個別に対応する「着せ替え用CSS」（ベースが異なる場合は適用できない）という形である必要があるでしょうかね。
🍨スキンの仕様は従来通りにしつつ、1つ「着せ替えCSSを適用する専用のベーススキン」という特殊なスキンを1つ用意しておいて、そのスキンに対してだけは「着せ替えCSSをアップロードするだけで管理画面上でCSSを切り替えられる」みたいな仕様の方が、CSSを作りやすくて良いのかもしれませんけども……。つまり、「着せ替え用ベーススキン向けのCSSだけで望みのデザインが実現できるなら着せ替え用CSSを作る」方法で済ませて、それだけでは済まない場合には（従来通り）「HTML×2＋CSSのスキン（フルセット）を作る」方法を採用する……みたいな感じで。
何か「こうなっているとスキンが作りやすい」みたいなご要望があればぜひお知らせ下さい。
黒電話に詳しいコミュニティ……。☎
🍧Re:2922◆紙の電話帳ってもしかして30年以上見ていないのではないかな……と一瞬思ったのですが、そういえば大学院の内線電話番号が紙の電話帳だったことを思い出しました。内線だと今でも一覧を紙で用意されていたりするのでしょうかね……？
🍧Re:2923◆そうそう。こんな感じで五十音の見出しが付いていましたよね。均等に割り振られていると、特定のページだけスペースが足りなくなるんですよね……。^^;
🍧Re:2924◆一般配布用のスキンを作って下さっているのですね！ どうもありがとうございます。(╹◡╹)
🍧Re:2925◆その情報を併記頂けると親切で分かりやすくてたいへんありがたいです。◆ドイリーという名称なんですね、これ。果たして昔々のうちの黒電話の下にこれがあったかどうかまでは記憶にないのですが、そういえばなんかあったような気も……。
🍧Re:2926◆はい。もしCSSだけで全く異なるデザインにできてHTMLを改造する必要性がない、というような場合なら、HTMLソースは無変更のままで丸々流用して頂いてもOKです。👍
おなかがへった……。_(┐｢ε:)_ 🍨🍨🍨
🍧Re:2922◆紙の電話帳ってもしかして30年以上見ていないのではないかな……と一瞬思ったのですが、そういえば大学院の内線電話番号が紙の電話帳だったことを思い出しました。内線だと今でも一覧を紙で用意されていたりするのでしょうかね……？
🍧Re:2923◆そうそう。こんな感じで五十音の見出しが付いていましたよね。均等に割り振られていると、特定のページだけスペースが足りなくなるんですよね……。^^;
🍧Re:2924◆一般配布用のスキンを作って下さっているのですね！ どうもありがとうございます。(╹◡╹)
🍧Re:2925◆その情報を併記頂けると親切で分かりやすくてたいへんありがたいです。◆ドイリーという名称なんですね、これ。果たして昔々のうちの黒電話の下にこれがあったかどうかまでは記憶にないのですが、そういえばなんかあったような気も……。
🍧Re:2926◆はい。もしCSSだけで全く異なるデザインにできてHTMLを改造する必要性がない、というような場合なら、HTMLソースは無変更のままで丸々流用して頂いてもOKです。👍
おなかがへった……。_(┐｢ε:)_ 🍨🍨🍨
返信が遅くなって申し訳ないです。
🍧Re:2916◆そういえば、うろ覚えですけども、昔々うちの黒電話にも何らかのカバーが掛かっていたような……。
🍧Re:2917◆黒電話って、何らかの電話帳がセットで必要ですよね。覚えている番号だけに掛けるわけではないでしょうし。黒電話と併せて使う電話帳は話題にならないのかな……？
🍧Re:2918◆「配布」というのは、ご自身のWebで公開するなど「不特定多数への配布」という意味でしょうかね？（不特定ではなくて、限られた相手に配布するだけならもう本当に何でも好きにして頂ければ良いです。）以下は、不特定多数へ配布する場合として回答します。
まず、大前提として、既存のスキンはいくらでも改造して下さって構いません。流用できるソースは何でも流用して、自由に作成して下さい。
で、既存のスキンを改造して作成された「新たなスキン」を不特定多数へ配布なさりたい場合の話ですが、「元のデザインと大きく異なる」くらいに改造されているのなら特に問題はありません。むしろ歓迎です。ぜひ配布して下さい。
そうではなくて、例えば「配色を変えただけ」とか「掲載順序を変えただけ」とか「特定の要素を削っただけ」などのように、「元のデザインからあまり変わっていない」状態での再配布はご遠慮頂けるとありがたいな、と思っています。
これはなぜかというと、（特に新規のユーザさんには）極力『最新版用に記述されたスキンで「てがろぐ」を使い始めて欲しい』と思っているからです。標準添付の各スキンは『そのときの最新版で使える多くの機能を使うように記述』してあります。そのようなスキンなら、搭載されている各機能の存在に気付きやすいだろうからです。ユーザさんによっては「不要な機能」が多々あるかも知れませんが、それは単に各自で消して頂ければ良いだけなのでカスタマイズも簡単です。
しかし、「古い版のスキン」で使い始められてしまうと、新しい機能の存在に気付いてもらえない可能性が高まってしまいます（※OGP＋Twitter CardやRSS等のように「ページ上には見えない」機能の場合は特に）。たとえマニュアル等で新機能の存在を知ったとしても、それを使うためには「どうやってスキンに書き足せば良いのか」を調べて自力で編集しなければ使えません。それはハードルが高いと思うのですよね。
なので、できるだけ『使える機能を「全部盛り」した状態のスキン』で使い始めて頂きやすいようにしたいと思っているのです。
これは決して「機能を全部盛りしたスキンしか配布しないでくれ」と言っているわけではありません。シンプルな構成にも需要はあるでしょうし、デザイン上の都合で盛り込みにくい機能もあるでしょうし。私も個人的に使っているのは極めてシンプルに機能をそぎ落としたスキンです。様々なスキンの選択肢があることは「てがろぐ」にとって良いことだと思います。あなた独自のデザインなスキンであれば、特定の機能を使うも使わないもご自由に作成して配布頂いて全然問題ありません。（問題ないどころか、むしろ歓迎です。） その際に、既存スキンのソースがどれだけ流用されていても何の問題もありません。使えるものはいくらでも使って下さい。既存スキンのソースがお役に立つなら嬉しいです。
上記で「ご遠慮頂けるとありがたい」と言っているのは、あくまでも「元のデザインからあまり変わっていない」状態での配布についてだけです。
今、おそらく一番使われているスキンが「Twitterっぽいスキン」ですが、例えば『「Twitterっぽいスキン」のサイドバーの掲載順序を変えただけ』みたいなスキンを配布されてしまうと、「Twitterっぽいスキン」のデザインそのままで使いたい新規ユーザさんは、そのスキンを使うかもしれませんよね（便宜上「コピースキン」と呼びます）。すると、将来「てがろぐ」に新しい機能が追加されたとき、コピースキンをダウンロードして使おうとする新規ユーザさんは、新機能の存在に気付きにくくなってしまうでしょう。なので、『「Twitterっぽいスキン」を使いたいと思って下さったユーザさんには、公式配布されている(最新版用の)「Twitterっぽいスキン」を使って頂きたい』と思っているだけです。
以上で回答になっていますでしょうか？畳む
🍧Re:2919◆おぉぅ。ご指摘ありがとうございます！ たしかに、Twitterっぽいスキンでは <div class="onelog"> で .onelog を使っていましたね。気付いていませんでした。これはちょっと都合が悪そうなので、次のバージョンでは別のclass名に差し替えておこうと思います。 .onelogbody とかに。ご指摘感謝です！ Web製作時の『class名あるある』のような気がしますが、どうしても自分の脳ミソから出てくる単語って限られているので、油断すると重複してしまうんですよね……。(^_^;)
🍧Re:2916◆そういえば、うろ覚えですけども、昔々うちの黒電話にも何らかのカバーが掛かっていたような……。
🍧Re:2917◆黒電話って、何らかの電話帳がセットで必要ですよね。覚えている番号だけに掛けるわけではないでしょうし。黒電話と併せて使う電話帳は話題にならないのかな……？
🍧Re:2918◆「配布」というのは、ご自身のWebで公開するなど「不特定多数への配布」という意味でしょうかね？（不特定ではなくて、限られた相手に配布するだけならもう本当に何でも好きにして頂ければ良いです。）以下は、不特定多数へ配布する場合として回答します。
まず、大前提として、既存のスキンはいくらでも改造して下さって構いません。流用できるソースは何でも流用して、自由に作成して下さい。
で、既存のスキンを改造して作成された「新たなスキン」を不特定多数へ配布なさりたい場合の話ですが、「元のデザインと大きく異なる」くらいに改造されているのなら特に問題はありません。むしろ歓迎です。ぜひ配布して下さい。
そうではなくて、例えば「配色を変えただけ」とか「掲載順序を変えただけ」とか「特定の要素を削っただけ」などのように、「元のデザインからあまり変わっていない」状態での再配布はご遠慮頂けるとありがたいな、と思っています。
これはなぜかというと、（特に新規のユーザさんには）極力『最新版用に記述されたスキンで「てがろぐ」を使い始めて欲しい』と思っているからです。標準添付の各スキンは『そのときの最新版で使える多くの機能を使うように記述』してあります。そのようなスキンなら、搭載されている各機能の存在に気付きやすいだろうからです。ユーザさんによっては「不要な機能」が多々あるかも知れませんが、それは単に各自で消して頂ければ良いだけなのでカスタマイズも簡単です。
しかし、「古い版のスキン」で使い始められてしまうと、新しい機能の存在に気付いてもらえない可能性が高まってしまいます（※OGP＋Twitter CardやRSS等のように「ページ上には見えない」機能の場合は特に）。たとえマニュアル等で新機能の存在を知ったとしても、それを使うためには「どうやってスキンに書き足せば良いのか」を調べて自力で編集しなければ使えません。それはハードルが高いと思うのですよね。
なので、できるだけ『使える機能を「全部盛り」した状態のスキン』で使い始めて頂きやすいようにしたいと思っているのです。
これは決して「機能を全部盛りしたスキンしか配布しないでくれ」と言っているわけではありません。シンプルな構成にも需要はあるでしょうし、デザイン上の都合で盛り込みにくい機能もあるでしょうし。私も個人的に使っているのは極めてシンプルに機能をそぎ落としたスキンです。様々なスキンの選択肢があることは「てがろぐ」にとって良いことだと思います。あなた独自のデザインなスキンであれば、特定の機能を使うも使わないもご自由に作成して配布頂いて全然問題ありません。（問題ないどころか、むしろ歓迎です。） その際に、既存スキンのソースがどれだけ流用されていても何の問題もありません。使えるものはいくらでも使って下さい。既存スキンのソースがお役に立つなら嬉しいです。
上記で「ご遠慮頂けるとありがたい」と言っているのは、あくまでも「元のデザインからあまり変わっていない」状態での配布についてだけです。
今、おそらく一番使われているスキンが「Twitterっぽいスキン」ですが、例えば『「Twitterっぽいスキン」のサイドバーの掲載順序を変えただけ』みたいなスキンを配布されてしまうと、「Twitterっぽいスキン」のデザインそのままで使いたい新規ユーザさんは、そのスキンを使うかもしれませんよね（便宜上「コピースキン」と呼びます）。すると、将来「てがろぐ」に新しい機能が追加されたとき、コピースキンをダウンロードして使おうとする新規ユーザさんは、新機能の存在に気付きにくくなってしまうでしょう。なので、『「Twitterっぽいスキン」を使いたいと思って下さったユーザさんには、公式配布されている(最新版用の)「Twitterっぽいスキン」を使って頂きたい』と思っているだけです。
以上で回答になっていますでしょうか？畳む
🍧Re:2919◆おぉぅ。ご指摘ありがとうございます！ たしかに、Twitterっぽいスキンでは <div class="onelog"> で .onelog を使っていましたね。気付いていませんでした。これはちょっと都合が悪そうなので、次のバージョンでは別のclass名に差し替えておこうと思います。 .onelogbody とかに。ご指摘感謝です！ Web製作時の『class名あるある』のような気がしますが、どうしても自分の脳ミソから出てくる単語って限られているので、油断すると重複してしまうんですよね……。(^_^;)
塩分補給のために梅塩飴🍬を調達したものの、そもそも自分の身体が塩分不足なのか塩分過多なのか判断する方法がないので、舐めるべきなのかどうかの判断ができない……。┌(:3」└)┐
🍧Re:2911◆「黒電話でも使える番号がある」という情報を先に得ていたからでしょうね。^^; 「どこかに確実にある」と分かっているわけですから。電話番号が「お問い合わせ」関連以外のページにあるとは思いにくいので、「掘りに掘って」という表現から、見つかりにくい位置にリンクがあるのかな、と思ったのでした。
🍧Re:2912◆黒電話ユーザってもしかして結構多いんですかね……？^^; まあ、故障しない限り買い換えることはなさそうですしね……。^^;
🍧Re:2913◆ひかり電話でも「ダイヤルパルス信号を出す電話機」(黒電話もその一種です)は使用可能です。そもそも2024年にはNTTはアナログ回線を廃止してしまいますけども、今の電話機はそのまま使えるようです。ただ、黒電話ってケーブルが家の壁に直結していませんかね？ 今の一般的な電話機だとモジュラーケーブルで壁のモジュラージャックに繋がっていますから、光回線化する場合でも単に「壁のモジュラージャックに繋がっていたケーブル」を抜いて「ひかり電話用ルータにあるコネクタ」とかに挿し直せば良いだけですけども。黒電話の場合はまず「モジュラージャックに挿せるような改造」が必要なんじゃないかな、という気がします。軽くググってみると方法は存在するようですが、法的には資格者しかやっちゃダメなようなのでNTTとかに依頼する必要があるっぽいですね。たいていの場合は「そこまでせんでも電話機を買い換えるわ」ということになるのではないかと思います。(笑)
🍧そういえば、うちも（固定電話の）電話機が壊れたことはない気がします。引っ越しのついでに変わるか、機能不足で変えるかしかなかったような。
私の記憶にある最初の電話は黒電話でしたけども、引っ越しによってプッシュホンに変わりました。黒電話って（買い取りも可能なようですが）基本はレンタルですから、引っ越しした時代にNTTがプッシュホンを推していればあえて黒電話にはしないですよね。あとは、「留守電が必要だから留守電機能付きに買い換える」とか「FAXが必要だからFAX付きに買い換える」とかみたいな交換でした。
🍧Re:2911◆「黒電話でも使える番号がある」という情報を先に得ていたからでしょうね。^^; 「どこかに確実にある」と分かっているわけですから。電話番号が「お問い合わせ」関連以外のページにあるとは思いにくいので、「掘りに掘って」という表現から、見つかりにくい位置にリンクがあるのかな、と思ったのでした。
🍧Re:2912◆黒電話ユーザってもしかして結構多いんですかね……？^^; まあ、故障しない限り買い換えることはなさそうですしね……。^^;
🍧Re:2913◆ひかり電話でも「ダイヤルパルス信号を出す電話機」(黒電話もその一種です)は使用可能です。そもそも2024年にはNTTはアナログ回線を廃止してしまいますけども、今の電話機はそのまま使えるようです。ただ、黒電話ってケーブルが家の壁に直結していませんかね？ 今の一般的な電話機だとモジュラーケーブルで壁のモジュラージャックに繋がっていますから、光回線化する場合でも単に「壁のモジュラージャックに繋がっていたケーブル」を抜いて「ひかり電話用ルータにあるコネクタ」とかに挿し直せば良いだけですけども。黒電話の場合はまず「モジュラージャックに挿せるような改造」が必要なんじゃないかな、という気がします。軽くググってみると方法は存在するようですが、法的には資格者しかやっちゃダメなようなのでNTTとかに依頼する必要があるっぽいですね。たいていの場合は「そこまでせんでも電話機を買い換えるわ」ということになるのではないかと思います。(笑)
🍧そういえば、うちも（固定電話の）電話機が壊れたことはない気がします。引っ越しのついでに変わるか、機能不足で変えるかしかなかったような。
私の記憶にある最初の電話は黒電話でしたけども、引っ越しによってプッシュホンに変わりました。黒電話って（買い取りも可能なようですが）基本はレンタルですから、引っ越しした時代にNTTがプッシュホンを推していればあえて黒電話にはしないですよね。あとは、「留守電が必要だから留守電機能付きに買い換える」とか「FAXが必要だからFAX付きに買い換える」とかみたいな交換でした。
おなかがへったぁ～。_(┐｢ε:)_
🍨Re:2907◆早速のご試用をどうもありがとうございます。問題なく動作しているようで良かったです。(^_^)
🍨Re:2908◆黒電話が現役とは、ずいぶん物持ちが良いですね！ たしかに、各種サービスの受付電話だと、番号を選択させる仕組みが多そうですね。黒電話でもOKな番号というのは、もしかして問い合わせ窓口ページにある固定回線へのお問合せをご希望のお客さまでしょうか？ こういうのがちゃんと用意されていることにちょっと驚きました。^^;
🍨Re:2909◆さんごよみCGIのご使用をどうもありがとうございます！ そうですね、HTMLソースの直接投稿もできる仕様になっています。てがろぐCGIでは、実装上の関係から（たぶん） [HTML]～[/HTML] みたいな専用タグで括った範囲内だけでHTMLを有効にするとか、何かそんな感じの仕様になりそうな気がしています。何にしても、将来的にはHTMLも直接扱えるようにはする予定ですので気長にお待ち頂ければ幸いです。
夜中なので、何も食べずに寝る……。(:3[____]
🍨Re:2907◆早速のご試用をどうもありがとうございます。問題なく動作しているようで良かったです。(^_^)
🍨Re:2908◆黒電話が現役とは、ずいぶん物持ちが良いですね！ たしかに、各種サービスの受付電話だと、番号を選択させる仕組みが多そうですね。黒電話でもOKな番号というのは、もしかして問い合わせ窓口ページにある固定回線へのお問合せをご希望のお客さまでしょうか？ こういうのがちゃんと用意されていることにちょっと驚きました。^^;
🍨Re:2909◆さんごよみCGIのご使用をどうもありがとうございます！ そうですね、HTMLソースの直接投稿もできる仕様になっています。てがろぐCGIでは、実装上の関係から（たぶん） [HTML]～[/HTML] みたいな専用タグで括った範囲内だけでHTMLを有効にするとか、何かそんな感じの仕様になりそうな気がしています。何にしても、将来的にはHTMLも直接扱えるようにはする予定ですので気長にお待ち頂ければ幸いです。
夜中なので、何も食べずに寝る……。(:3[____]
室温が32.9℃……？
🍨Re:2899◆ブックマーク機能はJavaScriptだけで作れば、てがろぐ側の機能拡張をあまりしなくても実装できそうな気がなんとなくはしています。その代わり、ブラウザ単位での保存になりますし、管理者側は数を把握できませんが（だからこそ、てがろぐ側の拡張が不要なわけですけども）。逆に、管理者側で把握できるようにするなら、てがろぐ側にその管理機能を加える必要がありますから、そこそこの拡張が必要ですね。ただ、それが実現できるなら、「いいね」機能も同時に実現可能だというメリットもありそうですが。◆かき氷はほとんど液体なので、（たくさん食べて冷やしすぎることさえなければ）胃腸に優しいのはかき氷の方ではないかな、と思っています。チョコレートとか消化にあまりよろしくない物体があるのはアイスクリームの方だろうとも思いますし。
No.2900投稿時に、公式ページのURLが間違っていたので修正しました。
公式ページ、公式動作サンプル です。
🍨Re:2899◆ブックマーク機能はJavaScriptだけで作れば、てがろぐ側の機能拡張をあまりしなくても実装できそうな気がなんとなくはしています。その代わり、ブラウザ単位での保存になりますし、管理者側は数を把握できませんが（だからこそ、てがろぐ側の拡張が不要なわけですけども）。逆に、管理者側で把握できるようにするなら、てがろぐ側にその管理機能を加える必要がありますから、そこそこの拡張が必要ですね。ただ、それが実現できるなら、「いいね」機能も同時に実現可能だというメリットもありそうですが。◆かき氷はほとんど液体なので、（たくさん食べて冷やしすぎることさえなければ）胃腸に優しいのはかき氷の方ではないかな、と思っています。チョコレートとか消化にあまりよろしくない物体があるのはアイスクリームの方だろうとも思いますし。
No.2900投稿時に、公式ページのURLが間違っていたので修正しました。
公式ページ、公式動作サンプル です。
あ、つ、い……。_(┐｢ε:)_
🍵Re:2893◆なるほど、ブックマーク機能は便利そうですね。Cookieに保存する仕組みにすれば、IDがなくてもブラウザ単位で保持しておけそうな気もしました。(ただその場合は、管理者がブックマーク数を知る手段がなさそうですけども。むしろその方が良いですかね？^^;)
🍵Re:2894◆うまくいったようで良かったです。(╹◡╹)ﾉ
🍵Re:2895◆自由にIDを作成できると、IDの総数が多くなるケースも想定しないといけないので、IDをプルダウンメニューから選ぶUIだけでなくて、IDも直接キー入力させるようなUIも用意しないといけなさそうですね。◆てがろぐは元々少人数で使うことを想定した仕様なので、不特定多数が利用する形態を考えると、何か他にもいろいろ追加しないといけない仕様が出てきそうな気もしてきました。^^;◆画像の使用を投稿者に限るよう制限する機能を作るのは不可能ではないのですが、「URLを指定して埋め込める」なら意味がほとんどありませんし、たとえURL指定を不可能にしても、「画像を一旦保存してから自分で再投稿する」手も使えるので、厳密に「投稿者に限る」のは(技術的に)無理だと思います。◆「思いつき」でのご要望も歓迎です。想定用途以外にももしかしたら活用できる便利機能な可能性もありますし。ご要望そのものは何でも歓迎です。(実現できるかは完全に別問題ですが。^^;)
🍵Re:2897◆ご要望をありがとうございます。複数投稿に対して一括して何かする機能は、やはりあると便利ですよね。今のところ「一括削除」機能しかありませんが、幸いチェックボックスを既に用意していますから、「チェックを入れた投稿を削除」ボタンの他のバリエーションを用意することでお望みの機能とかも実装できないかな……とちょっと考えてみます。一括カテゴリ登録機能とかもある方が便利ですもんね。
もはや、かき氷の季節……。アイスクリームよりも。🍨🍨🍨
🍵Re:2893◆なるほど、ブックマーク機能は便利そうですね。Cookieに保存する仕組みにすれば、IDがなくてもブラウザ単位で保持しておけそうな気もしました。(ただその場合は、管理者がブックマーク数を知る手段がなさそうですけども。むしろその方が良いですかね？^^;)
🍵Re:2894◆うまくいったようで良かったです。(╹◡╹)ﾉ
🍵Re:2895◆自由にIDを作成できると、IDの総数が多くなるケースも想定しないといけないので、IDをプルダウンメニューから選ぶUIだけでなくて、IDも直接キー入力させるようなUIも用意しないといけなさそうですね。◆てがろぐは元々少人数で使うことを想定した仕様なので、不特定多数が利用する形態を考えると、何か他にもいろいろ追加しないといけない仕様が出てきそうな気もしてきました。^^;◆画像の使用を投稿者に限るよう制限する機能を作るのは不可能ではないのですが、「URLを指定して埋め込める」なら意味がほとんどありませんし、たとえURL指定を不可能にしても、「画像を一旦保存してから自分で再投稿する」手も使えるので、厳密に「投稿者に限る」のは(技術的に)無理だと思います。◆「思いつき」でのご要望も歓迎です。想定用途以外にももしかしたら活用できる便利機能な可能性もありますし。ご要望そのものは何でも歓迎です。(実現できるかは完全に別問題ですが。^^;)
🍵Re:2897◆ご要望をありがとうございます。複数投稿に対して一括して何かする機能は、やはりあると便利ですよね。今のところ「一括削除」機能しかありませんが、幸いチェックボックスを既に用意していますから、「チェックを入れた投稿を削除」ボタンの他のバリエーションを用意することでお望みの機能とかも実装できないかな……とちょっと考えてみます。一括カテゴリ登録機能とかもある方が便利ですもんね。
もはや、かき氷の季節……。アイスクリームよりも。🍨🍨🍨
朝食はピザトースト。
🍵Re:2882◆word-breakとoverflow-wrapの違いを検索すると上位に出てくるこのページですが、W3Gなんですよね。(笑) 最初は私もW3Cがこんな分かりやすい解説を書いているのかと思いました。^^;
🍵Re:2883◆お知らせありがとうございます。驚きました。（公式以外で）てがろぐスキンを配布して下さった第1号ですね（少なくとも私の認識している範囲内では）。ありがたいことです。
🍵Re:2884◆『自動でリンクになるURL』だと自動改行されるのですよね？ だとすると、たしかに何らかのCSSで打ち消されているのでしょうかね……。他のスタイルで打ち消されるのが問題なら、body .comment { word-break: break-all !important; overflow-wrap: break-word !important; } のように書いておくと、さすがに(詳細度が上がって)上書きできて適用されるのではないかと思うのですが。（ボックスが無限に横方向に拡張されてしまうようなレイアウトになっているのかな……と一瞬思ったのですが、その場合は『自動でリンクになるURL』も横に伸びないとおかしいので、そうではないんですよね……。）もし設置されているサイトをメールででもお知らせ頂けるなら、こちらからアクセスして何が原因なのか究明することは可能です。
🍵Re:2885◆Sleipnirのシェアが今どれくらいなのか謎ですが、今でも精力的に更新されているので、何らかの収益は上がっているのでしょうかね？ 無料ソフトですけども。しかも、Ver.4系とVer.6系の開発が同時に進行していて、今でもVer.4系のアップデートも続いているのですよね。結構な開発リソースが必要だと思うのですが。私の環境にもインストールはしてあります。
雨が降っていなかったら銀行に行こうかと思っていたのだけど、降っておる。(´･ω･`) めちゃくちゃ風が強い。
🍵Re:2882◆word-breakとoverflow-wrapの違いを検索すると上位に出てくるこのページですが、W3Gなんですよね。(笑) 最初は私もW3Cがこんな分かりやすい解説を書いているのかと思いました。^^;
🍵Re:2883◆お知らせありがとうございます。驚きました。（公式以外で）てがろぐスキンを配布して下さった第1号ですね（少なくとも私の認識している範囲内では）。ありがたいことです。
🍵Re:2884◆『自動でリンクになるURL』だと自動改行されるのですよね？ だとすると、たしかに何らかのCSSで打ち消されているのでしょうかね……。他のスタイルで打ち消されるのが問題なら、body .comment { word-break: break-all !important; overflow-wrap: break-word !important; } のように書いておくと、さすがに(詳細度が上がって)上書きできて適用されるのではないかと思うのですが。（ボックスが無限に横方向に拡張されてしまうようなレイアウトになっているのかな……と一瞬思ったのですが、その場合は『自動でリンクになるURL』も横に伸びないとおかしいので、そうではないんですよね……。）もし設置されているサイトをメールででもお知らせ頂けるなら、こちらからアクセスして何が原因なのか究明することは可能です。
🍵Re:2885◆Sleipnirのシェアが今どれくらいなのか謎ですが、今でも精力的に更新されているので、何らかの収益は上がっているのでしょうかね？ 無料ソフトですけども。しかも、Ver.4系とVer.6系の開発が同時に進行していて、今でもVer.4系のアップデートも続いているのですよね。結構な開発リソースが必要だと思うのですが。私の環境にもインストールはしてあります。
雨が降っていなかったら銀行に行こうかと思っていたのだけど、降っておる。(´･ω･`) めちゃくちゃ風が強い。
おなかがへってきました。_(┐｢ε:)_
🍵Re:2873◆早速のバージョンアップをどうもありがとうございます。(╹◡╹)ﾉ
🍵Re:2875◆下げる機能の動作を果たして把握して頂けるかどうかが不安だったのですけども、把握どころか意外とご活用頂けていそうな感じで驚いています。^^;
🍵Re:2877◆ご活用ありがとうございます！
🍵Re:2878◆ブラウザには「英単語の途中では改行しない」という禁則処理があります。そのせいで、半角英字を長く連続させるとウインドウからはみ出て横スクロールが発生します。URLも「英字の連続」なので同様の禁則処理が働いてしまうのですよね。Firefoxだけは「/」記号を「単語の区切り」だと認識してくれるので、「/」が出てきたところで自動改行されるため、横には伸びずに済むのですが。
てがろぐでは、URLの自動リンクではa要素に class="url" という属性を付加してありまして、標準添付の各スキンのCSSではここに word-break: break-all; というスタイルを適用して、英単語だろうが何だろうが「描画領域の端」で強制的に改行するように指定してあります。なので、リンクになってさえいれば「URL」でも「長い英単語」でも何でも強制改行されます。
今回ご質問頂いたケースである「自動でリンクにはならないURLの書き方」は、「URLだとは認識されないから自動リンクにならない」わけですから、要するに普通の本文なので何のスタイルも適用されません。なのでブラウザ標準の禁則処理が働いてしまって、横に伸びるわけです。ブラウザ側の標準動作がそうなので、これを防ぐには何らかのスタイルを自ら適用しないとどうにもなりません。（てがろぐの問題ではなく、どんなWebでも同様です。）
▼解決策①
で、本文中に含まれるあらゆる英単語が途中で改行されても構わないなら .comment { word-break: break-all; } というCSSを追加すると解決します。
▼解決策①B
※サイドバーの存在しないレイアウトをお使いなら、.comment { overflow-wrap: break-word; } の方を使うと、短い英単語が途中でぶった切られるのを防げるので望ましいです。（サイドバーがあるレイアウトでこのCSSを使うと、段組の作り方によってはうまくいきません。例えば「標準スキン」や「Twitterっぽいスキン」ではこの方法では対処できません。しかし「ブログタイプスキン」は（サイドバーがあるものの）この方法で対処可能です。）※参考：word-break、overflow-wrap（＠MDN）
▼解決策②
なお、本文中に含まれるあらゆる英単語が途中でぶった切られると困るわい、という場合は、リンクにしたくないURLをとりあえず自由装飾記法を使って [F:longword:～] とかで装飾しておいて、 .deco-longword { word-break: break-all; } というCSSを追加すると良いと思います。
解決策①B ＞ 解決策② ＞ 解決策① の順でお勧めです。（解決策①Bが使えないスキンをお使いなら、解決策②がお勧めということになります。）
🍵Re:2879◆この場合は、Firefoxの動作が望ましいですね。URLに含まれる「/」記号で改行するなら自然だと思います。なぜ、他のレンダリングエンジンではそうならないのか……。^^;
🍵Re:2873◆早速のバージョンアップをどうもありがとうございます。(╹◡╹)ﾉ
🍵Re:2875◆下げる機能の動作を果たして把握して頂けるかどうかが不安だったのですけども、把握どころか意外とご活用頂けていそうな感じで驚いています。^^;
🍵Re:2877◆ご活用ありがとうございます！
🍵Re:2878◆ブラウザには「英単語の途中では改行しない」という禁則処理があります。そのせいで、半角英字を長く連続させるとウインドウからはみ出て横スクロールが発生します。URLも「英字の連続」なので同様の禁則処理が働いてしまうのですよね。Firefoxだけは「/」記号を「単語の区切り」だと認識してくれるので、「/」が出てきたところで自動改行されるため、横には伸びずに済むのですが。
てがろぐでは、URLの自動リンクではa要素に class="url" という属性を付加してありまして、標準添付の各スキンのCSSではここに word-break: break-all; というスタイルを適用して、英単語だろうが何だろうが「描画領域の端」で強制的に改行するように指定してあります。なので、リンクになってさえいれば「URL」でも「長い英単語」でも何でも強制改行されます。
今回ご質問頂いたケースである「自動でリンクにはならないURLの書き方」は、「URLだとは認識されないから自動リンクにならない」わけですから、要するに普通の本文なので何のスタイルも適用されません。なのでブラウザ標準の禁則処理が働いてしまって、横に伸びるわけです。ブラウザ側の標準動作がそうなので、これを防ぐには何らかのスタイルを自ら適用しないとどうにもなりません。（てがろぐの問題ではなく、どんなWebでも同様です。）
▼解決策①
で、本文中に含まれるあらゆる英単語が途中で改行されても構わないなら .comment { word-break: break-all; } というCSSを追加すると解決します。
▼解決策①B
※サイドバーの存在しないレイアウトをお使いなら、.comment { overflow-wrap: break-word; } の方を使うと、短い英単語が途中でぶった切られるのを防げるので望ましいです。（サイドバーがあるレイアウトでこのCSSを使うと、段組の作り方によってはうまくいきません。例えば「標準スキン」や「Twitterっぽいスキン」ではこの方法では対処できません。しかし「ブログタイプスキン」は（サイドバーがあるものの）この方法で対処可能です。）※参考：word-break、overflow-wrap（＠MDN）
▼解決策②
なお、本文中に含まれるあらゆる英単語が途中でぶった切られると困るわい、という場合は、リンクにしたくないURLをとりあえず自由装飾記法を使って [F:longword:～] とかで装飾しておいて、 .deco-longword { word-break: break-all; } というCSSを追加すると良いと思います。
解決策①B ＞ 解決策② ＞ 解決策① の順でお勧めです。（解決策①Bが使えないスキンをお使いなら、解決策②がお勧めということになります。）
🍵Re:2879◆この場合は、Firefoxの動作が望ましいですね。URLに含まれる「/」記号で改行するなら自然だと思います。なぜ、他のレンダリングエンジンではそうならないのか……。^^;
ぎゃあああああああああ！)ﾟoﾟ(
🍵Re:2863◆お知らせ下さってありがとうございます。製作方法は正しいです。skin-onelog.htmlでももちろん動作します（編集ボタンはskin-onelog.htmlにしか書けませんから）。が、現在の最新版で提供しているスキンに含まれているCSSだと、この方法では編集ボタンが消えなくなっている事実に気付きました。)ﾟoﾟ(
なんてこったい。
スキンに含まれている tegalog.css をご覧下さい。
ここの780行目付近に、以下のような記述があります。
/* ‥‥‥‥‥‥ */
/* ▼編集リンク */
/* ‥‥‥‥‥‥ */
.editlink a {
display: inline-block; /* インラインブロック化 */
font-size: 0.82em; /* 文字サイズ */
color: black; /* 文字色 */
： ： ：
ここの display: inline-block; を削除して下さい。
そうすると、本来の動作になります。
お手数ですがお試し下さい。
▼原因
ログインされていない状況では（条件を満たしたときにだけ） .Login-Required { display: none; } のCSSが出力される仕様です。そのために、編集ボタンを出力しているa要素に class="Login-Required" を加えると、ログインされていない場合にだけ編集ボタンを見えなくできるハズなのです……が、スキンのCSSファイル側に display: inline-block; という記述が含まれていると、そちらの方が（CSSでの詳細度が高い書き方になっているので）優先適用されてしまうために、（状況に関係なく常に）消せなくなっていました。orz
いつのバージョンから発生している問題なのか分かりませんが……。orz
いつからだ……？🤔
▼今後の対処
次のバージョン以後では、 .Login-Required { display: none !important; } と出力するように仕様変更しておきます……。
🍵Re:2863◆お知らせ下さってありがとうございます。製作方法は正しいです。skin-onelog.htmlでももちろん動作します（編集ボタンはskin-onelog.htmlにしか書けませんから）。が、現在の最新版で提供しているスキンに含まれているCSSだと、この方法では編集ボタンが消えなくなっている事実に気付きました。)ﾟoﾟ(
なんてこったい。
スキンに含まれている tegalog.css をご覧下さい。
ここの780行目付近に、以下のような記述があります。
/* ‥‥‥‥‥‥ */
/* ▼編集リンク */
/* ‥‥‥‥‥‥ */
.editlink a {
display: inline-block; /* インラインブロック化 */
font-size: 0.82em; /* 文字サイズ */
color: black; /* 文字色 */
： ： ：
ここの display: inline-block; を削除して下さい。
そうすると、本来の動作になります。
お手数ですがお試し下さい。
▼原因
ログインされていない状況では（条件を満たしたときにだけ） .Login-Required { display: none; } のCSSが出力される仕様です。そのために、編集ボタンを出力しているa要素に class="Login-Required" を加えると、ログインされていない場合にだけ編集ボタンを見えなくできるハズなのです……が、スキンのCSSファイル側に display: inline-block; という記述が含まれていると、そちらの方が（CSSでの詳細度が高い書き方になっているので）優先適用されてしまうために、（状況に関係なく常に）消せなくなっていました。orz
いつのバージョンから発生している問題なのか分かりませんが……。orz
いつからだ……？🤔
▼今後の対処
次のバージョン以後では、 .Login-Required { display: none !important; } と出力するように仕様変更しておきます……。
いつの間にか5月も半分が過ぎていた……？
🍵Re:2836◆ご質問の本文は……？^^;
🍵Re:2837◆てがろぐのご活用をどうもありがとうございます。ご要望もありがとうございます。てがろぐベースのスケジュールカレンダーCGIを現在開発中でして、もうほぼできあがっていて公開用ページを作成中の段階なのですけども、それに「祝日や記念日を登録する機能」があります。なので、その辺を、てがろぐ側にも流用して何か作ろうかな……という気が今のところはしています。実装する場合は、日付のカスタマイズ仕様の1つに加えることで、任意の位置に掲載できるようにします。日付の横に掲載したければできますし、単独でどこかに表示したければそうできるようになります。いつ頃に実装を始めるかは、まださっぱり計画していないのですが。気長にお待ち頂ければ幸いです。需要に応じて作りたいと思っていますので、ご要望が多ければ多いほど優先する可能性はあります。
ご要望はお気軽にどうぞー。(╹◡╹)ﾉ
🍵Re:2836◆ご質問の本文は……？^^;
🍵Re:2837◆てがろぐのご活用をどうもありがとうございます。ご要望もありがとうございます。てがろぐベースのスケジュールカレンダーCGIを現在開発中でして、もうほぼできあがっていて公開用ページを作成中の段階なのですけども、それに「祝日や記念日を登録する機能」があります。なので、その辺を、てがろぐ側にも流用して何か作ろうかな……という気が今のところはしています。実装する場合は、日付のカスタマイズ仕様の1つに加えることで、任意の位置に掲載できるようにします。日付の横に掲載したければできますし、単独でどこかに表示したければそうできるようになります。いつ頃に実装を始めるかは、まださっぱり計画していないのですが。気長にお待ち頂ければ幸いです。需要に応じて作りたいと思っていますので、ご要望が多ければ多いほど優先する可能性はあります。
ご要望はお気軽にどうぞー。(╹◡╹)ﾉ
てがろぐ上で動画を表示する方法 #🌱豆知識
🍵Re:2828◆Fancyboxを使う場合、（No.2829でご紹介した方法よりも）てがろぐ上でもっとスマートに動画を表示する方法を思いつきました。➡第2試験版のNo.69をご覧下さい。[テキストラベル:LB]動画のURL のように書くだけです。:LBは、テキストリンクのリンク先をLightboxで開くための記法ですが、設定で読み込むスクリプトがFancyboxになっているならFancyboxで表示されます。この方法なら、ブロークンなアイコンが表示されることなく、その場で動画を表示できます。
🍵Re:2828◆Fancyboxを使う場合、（No.2829でご紹介した方法よりも）てがろぐ上でもっとスマートに動画を表示する方法を思いつきました。➡第2試験版のNo.69をご覧下さい。[テキストラベル:LB]動画のURL のように書くだけです。:LBは、テキストリンクのリンク先をLightboxで開くための記法ですが、設定で読み込むスクリプトがFancyboxになっているならFancyboxで表示されます。この方法なら、ブロークンなアイコンが表示されることなく、その場で動画を表示できます。
葛餅を食べました。
🍵Re:2830◆「ある状況で適用する装飾」と「それ以外の状況で適用する装飾」を分けたいときにも:not()疑似クラスはとても便利ですね。わりと古いブラウザから対応しているので安心して使えます。
🍵Re:2831～2◆おおぅ……。確かにルビを振られる側の文字列が半角英数字だけだとうまくいかないですね。不具合のご報告をどうもありがとうございます。今の段階でもうまくいく裏技を発見したので以下にお知らせ致します。
Ⓐだと、12345 のようにうまくいきませんが、Ⓑだと 12345 のようにうまくいきました。
なんでⒶではダメでⒷではうまくいくのかまだ分かっていませんが。次のバージョンで何とかします。
🍵Re:2830◆「ある状況で適用する装飾」と「それ以外の状況で適用する装飾」を分けたいときにも:not()疑似クラスはとても便利ですね。わりと古いブラウザから対応しているので安心して使えます。
🍵Re:2831～2◆おおぅ……。確かにルビを振られる側の文字列が半角英数字だけだとうまくいかないですね。不具合のご報告をどうもありがとうございます。今の段階でもうまくいく裏技を発見したので以下にお知らせ致します。
Ⓐ 不具合例 ➡ [R:12345:半角]
Ⓑ ＯＫな例 ➡ [R: 12345 :半角] ルビを振られる側に半角空白記号を含めます。
Ⓐだと、12345 のようにうまくいきませんが、Ⓑだと 12345 のようにうまくいきました。
なんでⒶではダメでⒷではうまくいくのかまだ分かっていませんが。次のバージョンで何とかします。
目が乾く……。(>_<)
🍵Re:2823◆β版のご試用をどうもありがとうございます。「下げる」機能がお役に立って良かったです。自分で欲しいから作った機能だったので、どれくらい需要があるかはさっぱり分かっていなかったのですけども、需要はあったようですね。^^;
🍵Re:2824◆書き換え不要サーバのお知らせをどうもありがとうございます。わりとこの記述で行けそうな雰囲気ですね。私も教えて頂くまでは、こんな書き方があったとは知りませんでした。2000年代にこの書き方が広まっていれば、「1行目を書き換える」というCGI独特の作法も不要なのが当たり前になっていたかも知れませんね。
🍵Re:2825◆まず「人が来る理由」と「そこで話す理由」が先にないとコミュニティは形成されなさそうな気がしますので、「コミュニティを作る」という目的が先にあるだけだと難しい気はします。ここが「コミュニティ」と言えるのかどうかはよく分かりませんけども。(^_^;)
🍵Re:2826◆ありがとうございます。
🍵Re:2827◆完全に桜が散って、緑の葉が鮮やかになりましたね。^^;
🍵Re:2828◆てがろぐのご活用をどうもありがとうございます。強引な解決策ですが、LightboxではなくFancyboxを使うと裏技的に動画を表示できます。その方法は、てがろぐ上に直接動画ファイルをUPする(今のところの)裏技的な方法に書きましたのでご参照頂ければ幸いです。 それよりも、No.2835に書いた方法の方がスマートです。正式にもいつかは対応する予定ではおりますので、気長にお待ち頂ければ幸いです。今の時点でどうしてもその場で動画を再生させたい場合には、この方法をご活用下さい。（一番良さそうなのはYouTubeにUPしてそれを埋め込むことですが。）
なお、先の解説は1年前に書いたものなので、「動画ファイル名は（投稿画像と同じように）強制的に変更される」という弊害が書かれていますが、現在のバージョンでは元のファイル名を維持してUP可能なので、元のファイル名を維持してUPするよう設定していれば、この弊害はありません。
ドライアイ用の目薬は差しました。(>_<)
🍵Re:2823◆β版のご試用をどうもありがとうございます。「下げる」機能がお役に立って良かったです。自分で欲しいから作った機能だったので、どれくらい需要があるかはさっぱり分かっていなかったのですけども、需要はあったようですね。^^;
🍵Re:2824◆書き換え不要サーバのお知らせをどうもありがとうございます。わりとこの記述で行けそうな雰囲気ですね。私も教えて頂くまでは、こんな書き方があったとは知りませんでした。2000年代にこの書き方が広まっていれば、「1行目を書き換える」というCGI独特の作法も不要なのが当たり前になっていたかも知れませんね。
🍵Re:2825◆まず「人が来る理由」と「そこで話す理由」が先にないとコミュニティは形成されなさそうな気がしますので、「コミュニティを作る」という目的が先にあるだけだと難しい気はします。ここが「コミュニティ」と言えるのかどうかはよく分かりませんけども。(^_^;)
🍵Re:2826◆ありがとうございます。
🍵Re:2827◆完全に桜が散って、緑の葉が鮮やかになりましたね。^^;
🍵Re:2828◆てがろぐのご活用をどうもありがとうございます。強引な解決策ですが、LightboxではなくFancyboxを使うと裏技的に動画を表示できます。
なお、先の解説は1年前に書いたものなので、「動画ファイル名は（投稿画像と同じように）強制的に変更される」という弊害が書かれていますが、現在のバージョンでは元のファイル名を維持してUP可能なので、元のファイル名を維持してUPするよう設定していれば、この弊害はありません。
ドライアイ用の目薬は差しました。(>_<)
その月最後の金曜日が祝日の場合でもプレミアムフライデーと呼ぶのだろうか？
🍵Re:2815◆構成ファイルのアップロードができて、パーミッションの変更ができさえすれば良いので、No.2816さんのおっしゃるようにスマートフォンやタブレットからでも設置に問題はありません。設置時に tegalog.cgi の1行目を書き換えないと動かないサーバをお使いの場合には、スマートフォンやタブレットからだと少々面倒かも知れませんが。今回のβ版からは多くの環境で書き換えずに済みそうな記述に変えましたので、それがうまくいくようなら今後はもっと手間なく設置できるようになると期待しています。^^;
🍵Re:2819◆ご要望をありがとうございます。やはり需要はあるのですね。かなり初期の頃から「Twitterのように複数投稿を連結して表示したい」というご要望を頂いていまして、複数投稿を(手動で番号をリストアップすることで)連続表示する機能は、その連結機能の実現ステップの1つにもなるな……という気がしています。個人的にも欲しいので、いつかは作ると思います。気長にお待ち頂ければ幸いです。
🍵Re:2820◆早い。^^; 早速のお試しをどうもありがとうございます。(╹◡╹)ﾉ 問題なく動作したようで良かったです。Perlパスの書き換えが不要だと、設置はずいぶん楽になりますね。
そもそもプレミアムフライデー、今はどうなったんだ……。
🍵Re:2815◆構成ファイルのアップロードができて、パーミッションの変更ができさえすれば良いので、No.2816さんのおっしゃるようにスマートフォンやタブレットからでも設置に問題はありません。設置時に tegalog.cgi の1行目を書き換えないと動かないサーバをお使いの場合には、スマートフォンやタブレットからだと少々面倒かも知れませんが。今回のβ版からは多くの環境で書き換えずに済みそうな記述に変えましたので、それがうまくいくようなら今後はもっと手間なく設置できるようになると期待しています。^^;
🍵Re:2819◆ご要望をありがとうございます。やはり需要はあるのですね。かなり初期の頃から「Twitterのように複数投稿を連結して表示したい」というご要望を頂いていまして、複数投稿を(手動で番号をリストアップすることで)連続表示する機能は、その連結機能の実現ステップの1つにもなるな……という気がしています。個人的にも欲しいので、いつかは作ると思います。気長にお待ち頂ければ幸いです。
🍵Re:2820◆早い。^^; 早速のお試しをどうもありがとうございます。(╹◡╹)ﾉ 問題なく動作したようで良かったです。Perlパスの書き換えが不要だと、設置はずいぶん楽になりますね。
そもそもプレミアムフライデー、今はどうなったんだ……。
🍵Re:2805◆おそらく、豆知識ページで紹介している画像を直接埋め込まずに、画像へのテキストリンクとして掲載したいが、リンク先の画像はLightboxで見せたい場合の書き方 がお望みの動作ですかね？ テキストリンクのリンク名の最後に:LBと加えると、リンク先の画像がLightboxで表示されます。
昼食は、ハヤシライスうどん。
🍵Re:2792◆私は逆に、単体で見せるという発想がありませんでした。^^; 「装飾機能」という先入観があったので「何かに適用した装飾を使って、それっぽく見せる」みたいな考え方だったもので。
🍵Re:2793◆なるほど、.htaccessで何かしているディレクトリでは使えないのですか。てがろぐCGIは .htaccess 配下のディレクトリに置きつつ、doさんのプログラムそのものは .htaccess で何も制御していない別ディレクトリに置いておいて、てがろぐからは「別ディレクトリに存在するdoさんのプログラム」を呼び出す方法でもダメなのですか？
🍵Re:2794◆いろいろ試してみて下さい～。(╹◡╹)ﾉ
🍵Re:2795◆ムーヴキャンバスだと、ボディの中程より上が白のようですね。私が見たのは、本当に（人間が乗る部分の）屋根だけが白だったのです。屋根というのか天板というのか天井というのかよく分かりませんが。^^; まさしく上端だけが白色だったので阪急電車みたいだな、と思ったのでした。
ハヤシライスをうどん用のお椀に入れて、さらにうどんも入れたような感じ。（米＋うどん）
🍵Re:2792◆私は逆に、単体で見せるという発想がありませんでした。^^; 「装飾機能」という先入観があったので「何かに適用した装飾を使って、それっぽく見せる」みたいな考え方だったもので。
🍵Re:2793◆なるほど、.htaccessで何かしているディレクトリでは使えないのですか。てがろぐCGIは .htaccess 配下のディレクトリに置きつつ、doさんのプログラムそのものは .htaccess で何も制御していない別ディレクトリに置いておいて、てがろぐからは「別ディレクトリに存在するdoさんのプログラム」を呼び出す方法でもダメなのですか？
🍵Re:2794◆いろいろ試してみて下さい～。(╹◡╹)ﾉ
🍵Re:2795◆ムーヴキャンバスだと、ボディの中程より上が白のようですね。私が見たのは、本当に（人間が乗る部分の）屋根だけが白だったのです。屋根というのか天板というのか天井というのかよく分かりませんが。^^; まさしく上端だけが白色だったので阪急電車みたいだな、と思ったのでした。
ハヤシライスをうどん用のお椀に入れて、さらにうどんも入れたような感じ。（米＋うどん）
ロードマップに対するご要望をどうもありがとうございます。パスワード付与機能にもやはり需要はあったんですね。(^_^;) なんとなく実装仕様の方向性が見えてきました。まだ（全然実装は始まっていないので）ご要望は受け付けられますから、今からでも何か言っておきたいご要望があればお気軽にお知らせ下さい。頂いたご要望はすべて開発の参考にさせて頂きます。
🍵Re:2759～Re:2765◆ベースは『パターン➊ パスワードをあらかじめ設定しておいて、各投稿には「☑鍵付き」のようなチェックボックスを加える。』にしておいて、「☑鍵付き」にチェックが入っていれば管理画面で設定してある共通パスワードを要求する。しかし、「☑鍵付き」にチェックが入っている投稿の1行目先頭に [[KEY:hogehoge]] のようなコマンドが書かれている場合は、共通パスワードではなく hogehoge をパスワードにする。……というような感じでいこうかな……という気が（今のところは）しています。No.2765さんのおっしゃるとおり、パスワードは一律の方が実装はシンプルなので、『パターン➊がベースで、裏技的に➋も使える実装』みたいな感じですかね。これだと、「パスワードは加えたいが共通パスワードで良い」という場合には、いちいちパスワードを書かなくても「☑鍵付き」にチェックを入れるだけで済むので、操作も楽な気がします。
🍵Re:2762◆素晴らしい気づきをありがとうございます！ 「プレビューの代わりに使うことになりそう」というご意見で、「そうか、プレビュー機能がこれで作れるんだな」と気付きました。(笑) 下書きのプレビュー機能自体はご要望頂いていましたし私も欲しいと思っていたのですが、簡単な実装方法が思いつかなかったので先送りしていたのですけども、よく考えたら「プレビュー」という単独機能をわざわざ用意しなくても、投稿1件の単独表示時にログイン中のユーザIDをチェックして表示するかどうかを決めれば良いだけですね。そこに気付けたので、わりと簡単に実装できました。この後でβ版として配布します。
🍵Re:2767◆てがろぐのご使用をどうもありがとうございます。(╹◡╹) ご質問の回答です。➡ おっしゃるとおり「最初の１枚を注意書き」にした上で、その1枚を（通常の表示時には）非表示にする方法はいかがでしょうか。例えば、下記のような感じです。
①メインのスキンで読み込まれるCSSに、あらかじめ .deco-hide { display: none; } のような1行を加えておきます。
②次に注意書き用の画像を例えば attention.png というファイル名でimagesディレクトリにUPしておきます。
③ネタバレ対策で隠したい画像を投稿する際には、投稿本文内でその画像が現れるよりも前の位置に [F:hide:[PICT:attention.png]] のように書いておきます。
すると、「1枚目の画像」は attention.png になりますからギャラリーモードではこれが表示されます。しかし、この1枚目の画像は [F:hide:～] で囲まれているので、（メインのスキンで読まれるCSSでは display:none; が適用されますから）ページ上には表示されません。
……こんな対策ではいかがでしょうか？
🍵Re:2768◆私もその投稿で「そんな活用方法が！」と膝を打ちました。(笑)
🍵Re:2769◆たしかに、投稿にパスワードを加えると、「全体は検索に拾われるようにしている中、特定の投稿だけは拾われないようにする」という使い方もできますね。その視点はありませんでした。参考情報をどうもありがとうございます！
🍵Re:2759～Re:2765◆ベースは『パターン➊ パスワードをあらかじめ設定しておいて、各投稿には「☑鍵付き」のようなチェックボックスを加える。』にしておいて、「☑鍵付き」にチェックが入っていれば管理画面で設定してある共通パスワードを要求する。しかし、「☑鍵付き」にチェックが入っている投稿の1行目先頭に [[KEY:hogehoge]] のようなコマンドが書かれている場合は、共通パスワードではなく hogehoge をパスワードにする。……というような感じでいこうかな……という気が（今のところは）しています。No.2765さんのおっしゃるとおり、パスワードは一律の方が実装はシンプルなので、『パターン➊がベースで、裏技的に➋も使える実装』みたいな感じですかね。これだと、「パスワードは加えたいが共通パスワードで良い」という場合には、いちいちパスワードを書かなくても「☑鍵付き」にチェックを入れるだけで済むので、操作も楽な気がします。
🍵Re:2762◆素晴らしい気づきをありがとうございます！ 「プレビューの代わりに使うことになりそう」というご意見で、「そうか、プレビュー機能がこれで作れるんだな」と気付きました。(笑) 下書きのプレビュー機能自体はご要望頂いていましたし私も欲しいと思っていたのですが、簡単な実装方法が思いつかなかったので先送りしていたのですけども、よく考えたら「プレビュー」という単独機能をわざわざ用意しなくても、投稿1件の単独表示時にログイン中のユーザIDをチェックして表示するかどうかを決めれば良いだけですね。そこに気付けたので、わりと簡単に実装できました。この後でβ版として配布します。
🍵Re:2767◆てがろぐのご使用をどうもありがとうございます。(╹◡╹) ご質問の回答です。➡ おっしゃるとおり「最初の１枚を注意書き」にした上で、その1枚を（通常の表示時には）非表示にする方法はいかがでしょうか。例えば、下記のような感じです。
①メインのスキンで読み込まれるCSSに、あらかじめ .deco-hide { display: none; } のような1行を加えておきます。
②次に注意書き用の画像を例えば attention.png というファイル名でimagesディレクトリにUPしておきます。
③ネタバレ対策で隠したい画像を投稿する際には、投稿本文内でその画像が現れるよりも前の位置に [F:hide:[PICT:attention.png]] のように書いておきます。
すると、「1枚目の画像」は attention.png になりますからギャラリーモードではこれが表示されます。しかし、この1枚目の画像は [F:hide:～] で囲まれているので、（メインのスキンで読まれるCSSでは display:none; が適用されますから）ページ上には表示されません。
……こんな対策ではいかがでしょうか？
🍵Re:2768◆私もその投稿で「そんな活用方法が！」と膝を打ちました。(笑)
🍵Re:2769◆たしかに、投稿にパスワードを加えると、「全体は検索に拾われるようにしている中、特定の投稿だけは拾われないようにする」という使い方もできますね。その視点はありませんでした。参考情報をどうもありがとうございます！
朝食はサンドイッチ。
🍍Re:2752◆もしダメっぽそうならまたご連絡下さい。サイトマップをテキストの形で出力するか、サイトマップXML自体を静的なファイルに書き出せるようにするか何か検討します。
🍍Re:2753◆なるほど、確かに視界の邪魔になるならストレスも大きそうですね……。平らなマスクだと隙間なくフィットさせるのも大変でしょうし。
🍍Re:2754◆なるほど、軽トラ！ その存在は考えていませんでした。軽くググってみると、積み荷で重量が大きく変わる場合や坂道でエンジンブレーキを使う必要がある場合にはMTの方が有利という話もあって、なるほど、と思いました。そういう需要があったんですねえ……。
🍍ここのサンプルでカテゴリアイコンに使っている果物アイコンは、FAQページ内のてがろぐ上で自由にご活用頂けるアイコン画像などで配布しています。
🍍Re:2752◆もしダメっぽそうならまたご連絡下さい。サイトマップをテキストの形で出力するか、サイトマップXML自体を静的なファイルに書き出せるようにするか何か検討します。
🍍Re:2753◆なるほど、確かに視界の邪魔になるならストレスも大きそうですね……。平らなマスクだと隙間なくフィットさせるのも大変でしょうし。
🍍Re:2754◆なるほど、軽トラ！ その存在は考えていませんでした。軽くググってみると、積み荷で重量が大きく変わる場合や坂道でエンジンブレーキを使う必要がある場合にはMTの方が有利という話もあって、なるほど、と思いました。そういう需要があったんですねえ……。
🍍ここのサンプルでカテゴリアイコンに使っている果物アイコンは、FAQページ内のてがろぐ上で自由にご活用頂けるアイコン画像などで配布しています。
お腹減った……。_(┐｢ε:)_
🍘Re:2750◆『取得できませんでした』と表示されている部分をクリックするとエラーの詳細を教えてくれるページに移動できないか試してみて下さい。私の方での試したところ、Google Search ConsoleとBing Webmaster Toolsでサイトマップの認識はできました。ただ、Google Search Consoleの場合は、最初は『取得できませんでした』と表示されました(下図1枚目)。ただ、その『取得できませんでした』をクリックすると、読み込み自体はうまくいったようで「サイトマップは正常に処理されました」と表示されたのですが。(^_^;) その時点でも前のページに戻ると『取得できませんでした』と表示される謎な状態だったのですが、別タブでGoogle Search Consoleを読み込み直すと、ステータスは『成功しました』に変わっていました(下図2枚目)。
「Google Search Console」のロゴの右側にあるURL検査窓に、てがろぐCGIが出力するサイトマップXMLのURLを入力して、Googleが正しくそのページにアクセスできるかどうかを試してみて下さい。もしアクセスできないなら何か原因を特定する必要がありますし、アクセスできるなら待てば読んでくれるのではないかな……と思っています。
いくつかのSitemap XML Validatorで試したところ、HTTPヘッダが「application/xml」ではなく何故か「text/html; charset=iso-8859-1」で認識されるケースがあるようで、そこがエラーが出る原因のような気がしています。ただ、毎回そうなるわけではなく、正しく「application/xml」のヘッダが認識されるときもあるのですが。なんとなくですが、CGIの動作速度の問題で、反応が遅すぎるとヘッダが誤解されるのかな……という気もしているのですが。
XMLで出力するからそういう問題が起きるのかもしれないので、次回のバージョンでは「サイトマップXML」ではなく「サイトマップテキストファイル」の形でも出力できるようにしようかと思います。そうすると、HTTPヘッダの問題はなさそうな気がしますので。
とりあえず、Search Consoleの「URL検査」を試してみて頂けますでしょうか。
なお、管理画面の［設定］→［システム設定］→【フルパス設定】で、『固定』の方を選択している場合で、値をURLで書いていない場合（＝「/」で始まる絶対パス等で書いている場合）は、正しいサイトマップの出力になりませんのでご注意下さい。サイトマップに収録するURLは「 http(s):// 」から始める必要があるのですが、この設定を『固定』にしている場合は、この項目の値を使ってフルパスが生成されますので。
🍘Re:2750◆『取得できませんでした』と表示されている部分をクリックするとエラーの詳細を教えてくれるページに移動できないか試してみて下さい。私の方での試したところ、Google Search ConsoleとBing Webmaster Toolsでサイトマップの認識はできました。ただ、Google Search Consoleの場合は、最初は『取得できませんでした』と表示されました(下図1枚目)。ただ、その『取得できませんでした』をクリックすると、読み込み自体はうまくいったようで「サイトマップは正常に処理されました」と表示されたのですが。(^_^;) その時点でも前のページに戻ると『取得できませんでした』と表示される謎な状態だったのですが、別タブでGoogle Search Consoleを読み込み直すと、ステータスは『成功しました』に変わっていました(下図2枚目)。
「Google Search Console」のロゴの右側にあるURL検査窓に、てがろぐCGIが出力するサイトマップXMLのURLを入力して、Googleが正しくそのページにアクセスできるかどうかを試してみて下さい。もしアクセスできないなら何か原因を特定する必要がありますし、アクセスできるなら待てば読んでくれるのではないかな……と思っています。
いくつかのSitemap XML Validatorで試したところ、HTTPヘッダが「application/xml」ではなく何故か「text/html; charset=iso-8859-1」で認識されるケースがあるようで、そこがエラーが出る原因のような気がしています。ただ、毎回そうなるわけではなく、正しく「application/xml」のヘッダが認識されるときもあるのですが。なんとなくですが、CGIの動作速度の問題で、反応が遅すぎるとヘッダが誤解されるのかな……という気もしているのですが。
XMLで出力するからそういう問題が起きるのかもしれないので、次回のバージョンでは「サイトマップXML」ではなく「サイトマップテキストファイル」の形でも出力できるようにしようかと思います。そうすると、HTTPヘッダの問題はなさそうな気がしますので。
とりあえず、Search Consoleの「URL検査」を試してみて頂けますでしょうか。
なお、管理画面の［設定］→［システム設定］→【フルパス設定】で、『固定』の方を選択している場合で、値をURLで書いていない場合（＝「/」で始まる絶対パス等で書いている場合）は、正しいサイトマップの出力になりませんのでご注意下さい。サイトマップに収録するURLは「 http(s):// 」から始める必要があるのですが、この設定を『固定』にしている場合は、この項目の値を使ってフルパスが生成されますので。
🍵Re:2744◆「逆の入れ子」にする意図ではないのですが、その出力順になるのは意図通りです。
これは以下のような歴史的な経緯によるものです。^^;
Ⓐカテゴリ名「サンプル」(ID:sample) の出力例
Ⓑカテゴリなし の出力例
▼➊最初の仕様
「カテゴリなし」が表示できるようになった初期は、以下のような出力でした。
Ⓐ <a href="..." class="categorylink cat-sample">サンプル</a>
Ⓑ <span class="nocategory">カテゴリなし</span>
カテゴリがある場合はリンクにしますが、カテゴリがない場合はリンクにならなかったので、a要素の代わりにspan要素で出力したのです。
▼➋次の仕様
「カテゴリなし」がリンクにできるようになった時点で、以下のような出力になりました。
Ⓐ <a href="..." class="categorylink cat-sample">サンプル</a>
Ⓑ <span class="nocategory"><a href="..." class="categorylink cat-">カテゴリなし</a></span>
既に span.nocategory に対して装飾を加えているスキンがあるかもしれないことを考慮して、span要素の中にa要素を追加しました。
▼➌次の次の仕様
カテゴリアイコンなど諸々の掲載をサポートした結果、「カテゴリ名だけ」や「カテゴリアイコンだけ」等を個別に装飾できるように、a要素の内側にもspan要素を加えました。しかし、「カテゴリなし」はテキストだけしか表示できない仕様のままなので、何も変わっていません。
Ⓐ <a href="..." class="categorylink cat-sample"><span class="categoryname cat-sample">サンプル</span></a>
Ⓑ <span class="nocategory"><a href="..." class="categorylink cat-">カテゴリなし</a></span>
上記が現状です。
今回の Ver 3.6.0 では、「カテゴリなし」の存在を全く考慮していなかったので、「カテゴリなし」用の出力仕様を一切変えていません。よく考えると、ここは以下のようにした方が良いかもしれませんね。
▼将来の案(？)
Ⓐ <a href="..." class="categorylink cat-sample"><span class="categoryname cat-sample">サンプル</span></a>
Ⓑ <span class="nocategory"><a href="..." class="categorylink cat-"><span class="categoryname cat-">カテゴリなし</span></a></span>
ちょっと階層が深くなりすぎる気もしますけども。(^_^;;;
今のところ、「カテゴリなし」の場合には、アイコンも概要もなく単に「カテゴリなし用のテキスト」が出るだけですので、上記のようにするとしたら、まず「カテゴリなし」の場合でもアイコンや概要文を登録できる仕組みを用意するところから始めないといけませんけども。ただ、カテゴリ機能を実装した当初は「カテゴリなし」の存在を全く考慮していなかったために、「カテゴリなし」の表示機能(仕様)は結構な『後付け』での実装になっているのですよね……。今の仕様のままでそれを追加すると設定項目が複雑になりすぎて望ましくない気がします。なので、もし「カテゴリなし」にもアイコンや概要文を登録できるようにするなら、その辺のUIを根本的に作り直す必要があるかな……とちょっと思っています。
これは以下のような歴史的な経緯によるものです。^^;
Ⓐカテゴリ名「サンプル」(ID:sample) の出力例
Ⓑカテゴリなし の出力例
▼➊最初の仕様
「カテゴリなし」が表示できるようになった初期は、以下のような出力でした。
Ⓐ <a href="..." class="categorylink cat-sample">サンプル</a>
Ⓑ <span class="nocategory">カテゴリなし</span>
カテゴリがある場合はリンクにしますが、カテゴリがない場合はリンクにならなかったので、a要素の代わりにspan要素で出力したのです。
▼➋次の仕様
「カテゴリなし」がリンクにできるようになった時点で、以下のような出力になりました。
Ⓐ <a href="..." class="categorylink cat-sample">サンプル</a>
Ⓑ <span class="nocategory"><a href="..." class="categorylink cat-">カテゴリなし</a></span>
既に span.nocategory に対して装飾を加えているスキンがあるかもしれないことを考慮して、span要素の中にa要素を追加しました。
▼➌次の次の仕様
カテゴリアイコンなど諸々の掲載をサポートした結果、「カテゴリ名だけ」や「カテゴリアイコンだけ」等を個別に装飾できるように、a要素の内側にもspan要素を加えました。しかし、「カテゴリなし」はテキストだけしか表示できない仕様のままなので、何も変わっていません。
Ⓐ <a href="..." class="categorylink cat-sample"><span class="categoryname cat-sample">サンプル</span></a>
Ⓑ <span class="nocategory"><a href="..." class="categorylink cat-">カテゴリなし</a></span>
上記が現状です。
今回の Ver 3.6.0 では、「カテゴリなし」の存在を全く考慮していなかったので、「カテゴリなし」用の出力仕様を一切変えていません。よく考えると、ここは以下のようにした方が良いかもしれませんね。
▼将来の案(？)
Ⓐ <a href="..." class="categorylink cat-sample"><span class="categoryname cat-sample">サンプル</span></a>
Ⓑ <span class="nocategory"><a href="..." class="categorylink cat-"><span class="categoryname cat-">カテゴリなし</span></a></span>
ちょっと階層が深くなりすぎる気もしますけども。(^_^;;;
今のところ、「カテゴリなし」の場合には、アイコンも概要もなく単に「カテゴリなし用のテキスト」が出るだけですので、上記のようにするとしたら、まず「カテゴリなし」の場合でもアイコンや概要文を登録できる仕組みを用意するところから始めないといけませんけども。ただ、カテゴリ機能を実装した当初は「カテゴリなし」の存在を全く考慮していなかったために、「カテゴリなし」の表示機能(仕様)は結構な『後付け』での実装になっているのですよね……。今の仕様のままでそれを追加すると設定項目が複雑になりすぎて望ましくない気がします。なので、もし「カテゴリなし」にもアイコンや概要文を登録できるようにするなら、その辺のUIを根本的に作り直す必要があるかな……とちょっと思っています。
ふと気付いたら1週間以上放置していました。すみません。てがろぐ次期正式版に合わせた解説ページのアップデートを今ゴリゴリ書いています。もしよろしければβ版のご試用にご協力頂ければ幸いです。
🍵Re:2713◆β版のご試用をどうもありがとうございます。「カテゴリなし」の存在は素で忘却していました。┌(:3」└)┐ 今は「カテゴリなし」だけが特別な扱いになっていますが、「カテゴリなし」もその他のカテゴリと同様の方法で（＝カテゴリ一覧画面の表内で）編集できる仕様にした方が良いのだろうな……という気がしています。ただ、そうするとちょっと大がかりな変更になりそうなので、できるとしてももうちょっと先になりそうです。
🍵Re:2714◆お褒め下さってありがとうございます。お役に立っているようで嬉しいです。(╹◡╹) いろいろスキンを作ってみて下さい。
🍵Re:2715◆なるほど、最近のネクタイは結ばなくて良いんですね……！ 便利！ 学ランの硬いカラーがなくなったのは良いことです。
🍵Re:2716～17,19,20,23◆誕生日に風船が飛んでくれば、生年月日は登録されていますね。ただ、Twitter側が「生年月日を追加して下さい」と表示するなら登録していないのだろうと思いますが。生年月日は、もしパスワードを忘れた際の本人確認の1種に生年月日を尋ねてくるようなサービスの場合には危険が増しますから、特別必要でなければダミーの年月日を登録する方針が無難だとは思います（登録したダミーの年月日はサービスごとにどこかにメモっておかねばなりませんが、忘れるはずのない推しの誕生日とかがあればそれでも良いかもしれませんけども：笑）。Twitterで誕生日に風船を飛ばしたい場合は、月日だけ正しく入れておけば良いでしょう。
🍵Re:2718◆そうらしいですね。需要はあるでしょうけども、新しく作られる場合はCGIではなくPHPになりそうな気はします。doさんの「いいねボタン改」のように。
🍵Re:2721◆β版のご試用とカテゴリアイコン機能のご活用をありがとうございます。新着リストとして表示されるタイトル出力機能の改修と同時に、管理画面の投稿一覧の表示もちょっとだけ改修しました。気付いて下さってありがとうございます。(笑)
🍵Re:2724◆いろいろ作ってみて下さい～。配布して頂けるとなお嬉しいです。(╹◡╹)ﾉ 今のところ選択肢が公式配布スキンしかありませんから……。^^;
さて、昼食を食べてきます。🍙
🍵Re:2713◆β版のご試用をどうもありがとうございます。「カテゴリなし」の存在は素で忘却していました。┌(:3」└)┐ 今は「カテゴリなし」だけが特別な扱いになっていますが、「カテゴリなし」もその他のカテゴリと同様の方法で（＝カテゴリ一覧画面の表内で）編集できる仕様にした方が良いのだろうな……という気がしています。ただ、そうするとちょっと大がかりな変更になりそうなので、できるとしてももうちょっと先になりそうです。
🍵Re:2714◆お褒め下さってありがとうございます。お役に立っているようで嬉しいです。(╹◡╹) いろいろスキンを作ってみて下さい。
🍵Re:2715◆なるほど、最近のネクタイは結ばなくて良いんですね……！ 便利！ 学ランの硬いカラーがなくなったのは良いことです。
🍵Re:2716～17,19,20,23◆誕生日に風船が飛んでくれば、生年月日は登録されていますね。ただ、Twitter側が「生年月日を追加して下さい」と表示するなら登録していないのだろうと思いますが。生年月日は、もしパスワードを忘れた際の本人確認の1種に生年月日を尋ねてくるようなサービスの場合には危険が増しますから、特別必要でなければダミーの年月日を登録する方針が無難だとは思います（登録したダミーの年月日はサービスごとにどこかにメモっておかねばなりませんが、忘れるはずのない推しの誕生日とかがあればそれでも良いかもしれませんけども：笑）。Twitterで誕生日に風船を飛ばしたい場合は、月日だけ正しく入れておけば良いでしょう。
🍵Re:2718◆そうらしいですね。需要はあるでしょうけども、新しく作られる場合はCGIではなくPHPになりそうな気はします。doさんの「いいねボタン改」のように。
🍵Re:2721◆β版のご試用とカテゴリアイコン機能のご活用をありがとうございます。新着リストとして表示されるタイトル出力機能の改修と同時に、管理画面の投稿一覧の表示もちょっとだけ改修しました。気付いて下さってありがとうございます。(笑)
🍵Re:2724◆いろいろ作ってみて下さい～。配布して頂けるとなお嬉しいです。(╹◡╹)ﾉ 今のところ選択肢が公式配布スキンしかありませんから……。^^;
さて、昼食を食べてきます。🍙
🍵Re:2710◆鋭いツッコミをありがとうございます。「カテゴリなし」にアイコンを設定する機能はありません。┌(:3」└)┐ やっぱり要ります？(^_^;)
確定申告をせねば……。（仕事は一区切りつきました。）
☕Re:2692◆なんとか早めに作りたい……という気持ちはあるんですけどもね。^^; 気長にお待ち頂ければ幸いです。
☕Re:2693◆SVGファイルでも問題ありません。HTMLのimg要素のsrc属性値に指定できる内容なら何でも大丈夫です。Base64でエンコードされた文字列でも。
☕Re:2694◆記事を見つけて下さってありがとうございます。All Aboutは記事の更新日が分かりにくいのですが、この記事は2017年のなのですよね。グリッドレイアウトは、もはやCSS GridとかFlexboxで柔軟に作れるので、CSS自体の仕様だけで充分で、フレームワークを読み込む必要性はなくなっていると言って良い気もします。よほど古いブラウザもターゲットにしたい場合は別ですが。
CSS Gridはわりと新しいので概ね2017年以降のバージョンのブラウザでしかサポートされていませんが、flexboxは8～10年前くらいのバージョンからサポートされていますので、古い環境を考慮する場合でも使って問題ないと思っています。私が仕事でWeb製作をする場合でも、CSS Gridはまだ念のために避けていますが、Flexboxは普通に使っています。
☕Re:2692◆なんとか早めに作りたい……という気持ちはあるんですけどもね。^^; 気長にお待ち頂ければ幸いです。
☕Re:2693◆SVGファイルでも問題ありません。HTMLのimg要素のsrc属性値に指定できる内容なら何でも大丈夫です。Base64でエンコードされた文字列でも。
☕Re:2694◆記事を見つけて下さってありがとうございます。All Aboutは記事の更新日が分かりにくいのですが、この記事は2017年のなのですよね。グリッドレイアウトは、もはやCSS GridとかFlexboxで柔軟に作れるので、CSS自体の仕様だけで充分で、フレームワークを読み込む必要性はなくなっていると言って良い気もします。よほど古いブラウザもターゲットにしたい場合は別ですが。
CSS Gridはわりと新しいので概ね2017年以降のバージョンのブラウザでしかサポートされていませんが、flexboxは8～10年前くらいのバージョンからサポートされていますので、古い環境を考慮する場合でも使って問題ないと思っています。私が仕事でWeb製作をする場合でも、CSS Gridはまだ念のために避けていますが、Flexboxは普通に使っています。
