現状の機能では、毎日監視する運用でないと検索が厳しいです。 せめて、詳細検索時は7日分をまとめて表示できないでしょうか。
本当に欲しい機能としては、以下の内容を確認するため、クッキー・IP・ホスト名・SMSトークン、いずれかの完全一致での編集差分（または編集したことがあるページ一覧）を表示してほしいです。
https://z.wikiwiki.jp/wikiwiki-request/topic/481 こちらの改修が関係している可能性を考えています。
WCAGのコントラスト比の基準を満たさない組み合わせは読みにくいので（例：白地に黄文字）そこは考慮してほしいですね。
https://webaim.org/resources/contrastchecker/
追記
AVIFの現状の最大の弱点は圧縮に時間・計算量がかかる（特に最大圧縮率を追求した場合）ことですが、ユーザが勝手に自分の端末で圧縮する場合はWikiWikiのシステム側の懸念事項はありません。
リミッターの画像を仮にAVIFにする場合は圧縮率を必要に応じて下げるなどが必要になるかも知れません。
圧縮の時に使うAV1エンジンでSVT-AV1というものを選べば時短になりますが、YUV420固定なため非可逆WebPの弱点を引き継いでしまいます。とはいえ非可逆WebPからの切り替えであれば改悪ではありません。
パレットを追加するメリットはあまり無いように思えます。
細かく色を設定したいのならカラーコード(#xxxxxx)で事足りますし、選択肢が多すぎることで逆に編集の妨げになるケースも考えられます。 （似たような別の色を使ってバラバラに設定されてしまうと、後から変更したい時に一括置換ができなくなるなど）
特定の色だけに限定するとしても、パレットの〇〇番目を使ってくださいと説明するよりもカラーコードを直接指定した方がより確実です。
追記です。 結果的に早計な変更になってしまい申し訳ありませんでした。 私の環境でも動作することを確認できました。 対応いただき、ありがとうございました。
おそらく運営側にて対処されたかと思いますが、本日Edge、Chromeにて動作することを確認しました。 ただし設定文字数によってスクロール速度が変わったり、リピートまでに少し長い間が空いてしまうなど以前とは使い勝手が異なる点にご注意ください。 こちらの事象は解消されたようです。
トピ主です。 皆さん、情報ありがとうございました。 wikiwiki側の不具合ではなさそうとのことなので、タグを変更しました。
私のwikiではさほど多用しているわけではないので、代わりのプラグインを私から要望を出すことはいたしません。 もし他に希望する方がいれば、お任せします。
ありがとうございました。
marquee自体の廃止に1票です。 Webブラウザが拒否しているのですからどうしようもありません。 廃止といっても互換性維持のため現在のまま放置されるのかと思います。
代用品を求める場合は再提案をお願いします。
wikiwikiの不具合ではなく、 単に各ブラウザがmarqueeのサポートを終了しつつあるというだけの話かと。 私のスマホ（Android 16 / Firefox 148.0.2）では動作していますが、 今後もサポートが続く保証はありませんし（Windows版Firefoxでは、かなり前のVer.から動作していません） 環境ごとに動作がバラバラでは困るので、廃止に一票です。
個人的には全く不要でどうでも良い機能ですが、どうしても必要なら、 代替プラグインの実装を要望されたらよろしいのではないでしょうか。 要望者が多いようなら、ひょっとしたら実装してくれるかも知れません。
本日、スマートフォン(android)でも機能しなくなっているのを確認しました。
元になったと思われるHTMLのmarquee要素は大昔に非推奨機能となり、今後サポートの保証はありません。 参考
これを機に廃止してしまって良いのではないでしょうか。
脚注の文字色の修正を確認いたしました。
デザインテンプレートのsampleページを閲覧したところ、 モバイルだけでなくPCでもソースコードが表示され、 あらためてよく見ると、ページのソースコードではなく、 こちらの内容が表示されているようです。 これにどのような意味があるのか、知識がない自分にはさっぱりわかりませんが、 右上にCopyボタンがあることから、一先ず仕様と判断いたしました。
従ってトピックは解決済みとさせていただきます。
ご対応いただきありがとうございました！
(行頭#とかが有効なことに気づかず謎フォーマットになったけど気にしないでね🐱)
結論から言うと、提示してくれたページは現状のままで全く問題なしです！✨ 理由は、このページのPV(T.7, Y.11)なら、少しくらい負荷が高くてもサーバー全体への影響はほとんどないからです。 トップページ(T.4523, Y.11151)のレベルなら話は別ですが、このページなら今のままで大丈夫。💡
■ なぜ #lazy_fold でも本文コストが減らないの？ 右上の「本文コスト」は、サーバーが「wiki構文を読み込んでHTML表示用のデータを作る手間」を表しています。
サーバー側の「ページを組み立てる作業(コスト)」自体を減らす魔法ではないんです。 ■ 計測結果(参考) 全体: 11.1ms 本文コスト: 659.5ms この数値なら、メーターがオレンジ〜赤に見えても実際はスムーズに動いている範囲内(安全圏)ですよ。(※1) ■ 今後の対策 どうしても根本的にコストを下げたいなら「ページ分割」が必要になりますが、 現在の画像一覧(wiki共用のファイル置き場)という構成上、分割は少し難しそうですよね。
ってGemini(代筆)がいってた 【補足】 ・このページは3.に該当 (あとこのページは画像サイズ小さいので#lazy_なしでもいいかもね) ・#lazy_が機能していることは「読み込みリソース数」(画像数)が減ったことで確認できるよ ・部分的なコメントアウトをしていってコスト食いポイントを確認するのもいいね 【脚注】 (※1) アクセスめちゃ多いページの場合は対策取ろうね
こちら私が運営する別のwikiでも同様の問題が発生しております。有用な情報があればぜひお教えいただきたいです。
SteamのF12キーで撮影するスクリーンショットは画質の悪いjpegか画質はいいけどWIKIに適さない大きさのpngの他にAVIF形式が選択できるので、PCゲームのプレイヤー層としてはAVIF形式ができると非常に助かりますね。現状だと画質恒常のためにはpngで保存してからWebPに再圧縮しなければならない都合上手間も容量も食いますし
たしかに、外部のサイトにある画像をcssboxの背景に利用可能です。 ですが、使いる画像は外部である必要はなく、CDN上のURL（例としてサンプルWIKIの添付ファイルを使う場合：https://cdn.wikiwiki.jp/to/w/sample/FrontPage/::attach/bn_image2.gif ）を参照することでwikiwikiに添付した画像も利用可能です。 しかしながら、CDN上のURLを直接参照する手段は、正規の方法とは言えません。 やはり、何らかの変更が必要に思いますし、background-imageでURLの参照が禁止されても妥当という印象です。
指摘が事実であれば単純にコミュニティ疲弊要因ですので賛同します。 ただし、対応困難ということでbackground-image自体の禁止となってもそれはそれで賛同します。
新機能の実装ありがとうございます！ 添付時に画像を複数同時に選択してアップロードできるようにすることは可能でしょうか
同じ症状に悩まされていたので投稿させて頂きます 私自身もiPhone端末で編集することがあるので、ご対処して貰いたいです
新しいファイルマネージャの要望はこちらでよろしいのでしょうか？ 軽く使ってみましたが、添付する際に毎回スクロールが発生するので現行同様に上部に配置希望です。 添付ファイルドラッグの仕様も現行同様に新しいファイルをドラッグした場合は上書き出来るようにして欲しいです。間違ったファイルを選択した際にキャンセルを押す手間が増えているので
ファイル添付の画面右上に「新しいファイルマネージャを使う」というリンクを設置いたしました。
将来的にファイルの管理はこちらの画面に移行する予定です。 現在はページ単位の操作となりますが、WIKI全体のファイル操作につきましても、 今後別のアプローチにてアクセスできるよう準備を進めております。
なお、初見での操作状況を把握したいため、現時点では詳細な操作説明の記載は控えさせていただきます。
個人的にはemailでの認証が欲しいかな 6桁のコードを入力するやつ
ちなみに「やや改善」（ややのレベルじゃない）、「不具合」（不具合ではないが普通に不便）、 「要望」（運営に要望するようなことでは十分あります,自分も引っ掛かりまくってます）、です。
(￣￣￣￣￣@ |￣￣￣￣￣|゜人 |2026年| Ｙ |¨¨¨¨¨| ゜＋ ＋| 実 |人 | 家 | Ｙ 。 | 安 の | ＋ 。| 心 様 |∩ /フ | 感 な |||㎜ | ！ |=¨=
迅速なご対応ありがとうございました！ タグを「解決済」に変更しました。
下部に余白が生じる原因は、スタイルシートのimg.vertical-alignの設定がbaseline（デフォルト値）になっているためと思われます。 文章中に小さな画像をアイコンとして挿入した際に上へズレる原因にもなっているので、この設定をbottomなどに変えてほしいです。
二年前のトピックのようですが、私も困っていたので横から失礼します。
実際に試せばわかると思いますが、CENTER:MIDDLE:だろうがMIDDLE:CENTER:だろうが何を指定しても指定しなくても上に寄ります。 そもそも表内ではデフォルトでLEFT/MIDDLE指定になっており、あくまでc行でTOP等を指定したときに一部を例外的にMIDDLEにするための機能という認識です。
ではなぜこの問題が起きるのかという話ですが、添付した画像の下側に1割ほど謎の余白が追加されることが原因です。 背景が白以外の画像を貼り、ブラウザの範囲選択をして強調表示（こういうやつ）にすると余白があることがわかります。 表がこの余白を含めた大きさで画像を表示しているせいで、下が空く＝上に寄るというわけです。
というわけで、この謎の余白を追加しないようにできればこの問題は解決するはずです。 よろしくお願いします。
要望であるならば、なぜ・どのような場面で必要なのか記載するべきです。 察するに、下記トピックの作成者と同一人物ではないでしょうか。 https://z.wikiwiki.jp/wikiwiki-request/topic/482 ページ編集時のSMS認証についてのお話であるならば、既に上記トピックにて解決していますし、そうでないならより詳細に説明をするべきです。 強い言い方ですが、意味のない提案を繰り返されても迷惑になるだけです。
ここ（リクエスト広場）に投稿するトピックとして不適当に思えます。 また、タグが3つ付いていますが、 「やや改善」（意味不明）、「不具合」（不具合ではない）、 「要望」（運営に要望するようなことではない）、です。
日本語、理解できていますか？
追記：
元のトピックは、サガ用語辞典というWikiの新管理人募集だったのが、 タイトル&内容を書き換えられて意味不明なリプライになってしまいました。 下で副管理人(WoTBWiki)さんも仰っていますが、 ホントあなたは迷惑です。
いつの間にかできるようになってたし上にあげてたpcブラウザ版のものも解決してた
Google Chrome 143.0.7499.170 Microsoft Edge 144.0.3719.35 どちらも現象継続確認(どちらもごく稀に「検証に予想以上に時間がかかっています」のメッセージは出る)
他の認証方法 リクエスト広場 - zawazawa https://z.wikiwiki.jp/wikiwiki-request/topic/482
SMSが何の略か、何故電話番号が必要なのか一度考えた方がよいかと思います メールアドレスで認証できるようにするとしても、GoogleやYahooなどのメールアドレスは認証に使えないようにしなければ意味を成さないでしょう
oembedによる埋め込みですし、それはPixivやImgurに言ってくださいという話では……
もしかして生成AIで記事を作成・編集していたからですか？
そもそもSMS認証を設けている理由は、荒らし等の迷惑行為を抑止するためです。提案されている手法は、どれも本人確認を行う(一意性を確認する)ための手法でSMS認証の意図と異なります。
コメントのあと、確かに複数ファイルの添付ができた方が楽だと感じたのでREST APIを利用したツールを作りました。 解決策になるか分かりませんが、お役に立てば幸いです。 https://github.com/chansei/wikiwiki-attachment-tool
こちら実装を確認しました。アップロード後のリロード待機時間が無くなり快適です。 実装ありがとうございました。
現状の機能では、毎日監視する運用でないと検索が厳しいです。
せめて、詳細検索時は7日分をまとめて表示できないでしょうか。
本当に欲しい機能としては、以下の内容を確認するため、クッキー・IP・ホスト名・SMSトークン、いずれかの完全一致での編集差分（または編集したことがあるページ一覧）を表示してほしいです。
-- 初犯かどうか（何らかの操作ミスの可能性があるのかどうか）
https://z.wikiwiki.jp/wikiwiki-request/topic/481
こちらの改修が関係している可能性を考えています。
WCAGのコントラスト比の基準を満たさない組み合わせは読みにくいので（例：白地に黄文字）そこは考慮してほしいですね。
https://webaim.org/resources/contrastchecker/
追記
AVIFの現状の最大の弱点は圧縮に時間・計算量がかかる（特に最大圧縮率を追求した場合）ことですが、ユーザが勝手に自分の端末で圧縮する場合はWikiWikiのシステム側の懸念事項はありません。
リミッターの画像を仮にAVIFにする場合は圧縮率を必要に応じて下げるなどが必要になるかも知れません。
圧縮の時に使うAV1エンジンでSVT-AV1というものを選べば時短になりますが、YUV420固定なため非可逆WebPの弱点を引き継いでしまいます。とはいえ非可逆WebPからの切り替えであれば改悪ではありません。
パレットを追加するメリットはあまり無いように思えます。
細かく色を設定したいのならカラーコード(#xxxxxx)で事足りますし、選択肢が多すぎることで逆に編集の妨げになるケースも考えられます。
（似たような別の色を使ってバラバラに設定されてしまうと、後から変更したい時に一括置換ができなくなるなど）
特定の色だけに限定するとしても、パレットの〇〇番目を使ってくださいと説明するよりもカラーコードを直接指定した方がより確実です。
追記です。
結果的に早計な変更になってしまい申し訳ありませんでした。
私の環境でも動作することを確認できました。
対応いただき、ありがとうございました。
おそらく運営側にて対処されたかと思いますが、本日Edge、Chromeにて動作することを確認しました。
ただし設定文字数によってスクロール速度が変わったり、リピートまでに少し長い間が空いてしまうなど以前とは使い勝手が異なる点にご注意ください。こちらの事象は解消されたようです。トピ主です。
皆さん、情報ありがとうございました。
wikiwiki側の不具合ではなさそうとのことなので、タグを変更しました。
私のwikiではさほど多用しているわけではないので、代わりのプラグインを私から要望を出すことはいたしません。
もし他に希望する方がいれば、お任せします。
ありがとうございました。
marquee自体の廃止に1票です。
Webブラウザが拒否しているのですからどうしようもありません。
廃止といっても互換性維持のため現在のまま放置されるのかと思います。
代用品を求める場合は再提案をお願いします。
wikiwikiの不具合ではなく、
単に各ブラウザがmarqueeのサポートを終了しつつあるというだけの話かと。
私のスマホ（Android 16 / Firefox 148.0.2）では動作していますが、
今後もサポートが続く保証はありませんし（Windows版Firefoxでは、かなり前のVer.から動作していません）
環境ごとに動作がバラバラでは困るので、廃止に一票です。
個人的には全く不要でどうでも良い機能ですが、どうしても必要なら、
代替プラグインの実装を要望されたらよろしいのではないでしょうか。
要望者が多いようなら、ひょっとしたら実装してくれるかも知れません。
本日、スマートフォン(android)でも機能しなくなっているのを確認しました。
元になったと思われるHTMLのmarquee要素は大昔に非推奨機能となり、今後サポートの保証はありません。
参考
これを機に廃止してしまって良いのではないでしょうか。
脚注の文字色の修正を確認いたしました。
デザインテンプレートのsampleページを閲覧したところ、
モバイルだけでなくPCでもソースコードが表示され、
あらためてよく見ると、ページのソースコードではなく、
こちらの内容が表示されているようです。
これにどのような意味があるのか、知識がない自分にはさっぱりわかりませんが、
右上にCopyボタンがあることから、一先ず仕様と判断いたしました。
従ってトピックは解決済みとさせていただきます。
ご対応いただきありがとうございました！
(行頭#とかが有効なことに気づかず謎フォーマットになったけど気にしないでね🐱)
結論から言うと、提示してくれたページは現状のままで全く問題なしです！✨
理由は、このページのPV(T.7, Y.11)なら、少しくらい負荷が高くてもサーバー全体への影響はほとんどないからです。
トップページ(T.4523, Y.11151)のレベルなら話は別ですが、このページなら今のままで大丈夫。💡
■ なぜ #lazy_fold でも本文コストが減らないの？
右上の「本文コスト」は、サーバーが「wiki構文を読み込んでHTML表示用のデータを作る手間」を表しています。
lazy_foldは「ブラウザが画像を表示するタイミング」を遅らせてデータ転送量を減らすためのもので、
サーバー側の「ページを組み立てる作業(コスト)」自体を減らす魔法ではないんです。
■ 計測結果(参考) 全体: 11.1ms 本文コスト: 659.5ms
この数値なら、メーターがオレンジ〜赤に見えても実際はスムーズに動いている範囲内(安全圏)ですよ。(※1)
■ 今後の対策
どうしても根本的にコストを下げたいなら「ページ分割」が必要になりますが、
現在の画像一覧(wiki共用のファイル置き場)という構成上、分割は少し難しそうですよね。
現状維持でOKです！サーバーの負荷軽減に協力しようというそのお気持ちだけで100点満点です！💖
ってGemini(代筆)がいってた
【補足】
・このページは3.に該当 (あとこのページは画像サイズ小さいので#lazy_なしでもいいかもね)
・#lazy_が機能していることは「読み込みリソース数」(画像数)が減ったことで確認できるよ
・部分的なコメントアウトをしていってコスト食いポイントを確認するのもいいね
【脚注】
(※1) アクセスめちゃ多いページの場合は対策取ろうね
こちら私が運営する別のwikiでも同様の問題が発生しております。有用な情報があればぜひお教えいただきたいです。
SteamのF12キーで撮影するスクリーンショットは画質の悪いjpegか画質はいいけどWIKIに適さない大きさのpngの他にAVIF形式が選択できるので、PCゲームのプレイヤー層としてはAVIF形式ができると非常に助かりますね。現状だと画質恒常のためにはpngで保存してからWebPに再圧縮しなければならない都合上手間も容量も食いますし
たしかに、外部のサイトにある画像をcssboxの背景に利用可能です。
ですが、使いる画像は外部である必要はなく、CDN上のURL（例としてサンプルWIKIの添付ファイルを使う場合：https://cdn.wikiwiki.jp/to/w/sample/FrontPage/::attach/bn_image2.gif ）を参照することでwikiwikiに添付した画像も利用可能です。
しかしながら、CDN上のURLを直接参照する手段は、正規の方法とは言えません。
やはり、何らかの変更が必要に思いますし、background-imageでURLの参照が禁止されても妥当という印象です。
指摘が事実であれば単純にコミュニティ疲弊要因ですので賛同します。
ただし、対応困難ということでbackground-image自体の禁止となってもそれはそれで賛同します。
新機能の実装ありがとうございます！
添付時に画像を複数同時に選択してアップロードできるようにすることは可能でしょうか
同じ症状に悩まされていたので投稿させて頂きます
私自身もiPhone端末で編集することがあるので、ご対処して貰いたいです
新しいファイルマネージャの要望はこちらでよろしいのでしょうか？
軽く使ってみましたが、添付する際に毎回スクロールが発生するので現行同様に上部に配置希望です。
添付ファイルドラッグの仕様も現行同様に新しいファイルをドラッグした場合は上書き出来るようにして欲しいです。間違ったファイルを選択した際にキャンセルを押す手間が増えているので
ファイル添付の画面右上に「新しいファイルマネージャを使う」というリンクを設置いたしました。
将来的にファイルの管理はこちらの画面に移行する予定です。
現在はページ単位の操作となりますが、WIKI全体のファイル操作につきましても、
今後別のアプローチにてアクセスできるよう準備を進めております。
なお、初見での操作状況を把握したいため、現時点では詳細な操作説明の記載は控えさせていただきます。
個人的にはemailでの認証が欲しいかな
6桁のコードを入力するやつ
ちなみに「やや改善」（ややのレベルじゃない）、「不具合」（不具合ではないが普通に不便）、
「要望」（運営に要望するようなことでは十分あります,自分も引っ掛かりまくってます）、です。
(￣￣￣￣￣@
|￣￣￣￣￣|゜人
|2026年| Ｙ
|¨¨¨¨¨| ゜＋
＋| 実 |人
| 家 | Ｙ 。
| 安 の | ＋
。| 心 様 |∩ /フ
| 感 な |||㎜
| ！ |=¨=
(＿＿＿＿＿@ U―U
¨¨¨¨¨¨¨¨¨
(￣￣￣￣￣@
|￣￣￣￣￣|゜人
|2026年| Ｙ
|¨¨¨¨¨| ゜＋
＋| 実 |人
| 家 | Ｙ 。
| 安 の | ＋
。| 心 様 |∩ /フ
| 感 な |||㎜
| ！ |=¨=
(＿＿＿＿＿@ U―U
¨¨¨¨¨¨¨¨¨
迅速なご対応ありがとうございました！
タグを「解決済」に変更しました。
下部に余白が生じる原因は、スタイルシートのimg.vertical-alignの設定がbaseline（デフォルト値）になっているためと思われます。
文章中に小さな画像をアイコンとして挿入した際に上へズレる原因にもなっているので、この設定をbottomなどに変えてほしいです。
二年前のトピックのようですが、私も困っていたので横から失礼します。
実際に試せばわかると思いますが、CENTER:MIDDLE:だろうがMIDDLE:CENTER:だろうが何を指定しても指定しなくても上に寄ります。
そもそも表内ではデフォルトでLEFT/MIDDLE指定になっており、あくまでc行でTOP等を指定したときに一部を例外的にMIDDLEにするための機能という認識です。
ではなぜこの問題が起きるのかという話ですが、添付した画像の下側に1割ほど謎の余白が追加されることが原因です。
背景が白以外の画像を貼り、ブラウザの範囲選択をして強調表示（こういうやつ）にすると余白があることがわかります。
表がこの余白を含めた大きさで画像を表示しているせいで、下が空く＝上に寄るというわけです。
というわけで、この謎の余白を追加しないようにできればこの問題は解決するはずです。
よろしくお願いします。
要望であるならば、なぜ・どのような場面で必要なのか記載するべきです。
察するに、下記トピックの作成者と同一人物ではないでしょうか。
https://z.wikiwiki.jp/wikiwiki-request/topic/482
ページ編集時のSMS認証についてのお話であるならば、既に上記トピックにて解決していますし、そうでないならより詳細に説明をするべきです。
強い言い方ですが、意味のない提案を繰り返されても迷惑になるだけです。
ここ（リクエスト広場）に投稿するトピックとして不適当に思えます。
また、タグが3つ付いていますが、
「やや改善」（意味不明）、「不具合」（不具合ではない）、
「要望」（運営に要望するようなことではない）、です。
日本語、理解できていますか？
追記：
元のトピックは、サガ用語辞典というWikiの新管理人募集だったのが、
タイトル&内容を書き換えられて意味不明なリプライになってしまいました。
下で副管理人(WoTBWiki)さんも仰っていますが、
ホントあなたは迷惑です。
いつの間にかできるようになってたし上にあげてたpcブラウザ版のものも解決してた
Google Chrome 143.0.7499.170
Microsoft Edge 144.0.3719.35
どちらも現象継続確認(どちらもごく稀に「検証に予想以上に時間がかかっています」のメッセージは出る)
他の認証方法 リクエスト広場 - zawazawa https://z.wikiwiki.jp/wikiwiki-request/topic/482
SMSが何の略か、何故電話番号が必要なのか一度考えた方がよいかと思います
メールアドレスで認証できるようにするとしても、GoogleやYahooなどのメールアドレスは認証に使えないようにしなければ意味を成さないでしょう
oembedによる埋め込みですし、それはPixivやImgurに言ってくださいという話では……
もしかして生成AIで記事を作成・編集していたからですか？
そもそもSMS認証を設けている理由は、荒らし等の迷惑行為を抑止するためです。提案されている手法は、どれも本人確認を行う(一意性を確認する)ための手法でSMS認証の意図と異なります。
コメントのあと、確かに複数ファイルの添付ができた方が楽だと感じたのでREST APIを利用したツールを作りました。
解決策になるか分かりませんが、お役に立てば幸いです。
https://github.com/chansei/wikiwiki-attachment-tool
こちら実装を確認しました。アップロード後のリロード待機時間が無くなり快適です。
実装ありがとうございました。