https://wikiwiki.jp/paradigm_/ https://wikiwiki.jp/phigros/ Discordの埋め込みリンクが無い為、っぽいものをいくつかCSSで再現してるwikiもあるので、需要はそこそこあると思います
これはどちらも非常によさそうに感じました、強く支持します
返信ありがとうございます。 Steamウィジェットは>> 2様のおっしゃる通り、Steamゲームストアのセール中の価格を自動的に表示できるのようになるので見栄えアップと編集の手間を減らす目的です。
Discordウィジェットは特定のゲームのコミュニティサーバーへの窓口・案内を表示するものですが、オンライン(アクティブ)人数の表示、ボイスチャンネル(ボイスチャット)の人数表示などをリアルタイムで表示することが可能です。
自分が管理しているWikiでは、かなりマイナーな対戦ゲームを扱っており、日本人コミュニティではひっそりとDiscordで対戦・交流を行っている状態です。交流は今のところ閉鎖的な環境で「日本人ユーザーがいない」と勘違いされることも多いのかな思っており、それが外部の目に触れることでのコミュニティの活発化が狙いです。 サーバーウィジェットの詳細はこちらで紹介されています。 https://ja.101-help.com/1cc9b0b4d0-discord-widgetwowebsitenizhui-jia-surufang-fa/ しかし、Discordサーバーウィジェットの存在は日本ではあまり活用されておらず、賛同は得られにくいかなと思います。
やや改善タグは外しました。wikiwikiを使い始めてまだ数週間でまだわかっていないこともあり適当につけておりました。申し訳ございません。
はやしさんの指摘は正論ですね。 ここはリクエストと同時に、それについて議論する場所なのですから。
何ができてどんなメリットがあるのか分からないと賛同は得られにくいですし、 賛同が集まらないと、運営にスルーされる可能性が大きくなります。
Steamの方に関して言えば、Steamで扱っているゲームの攻略Wikiしか利用はないでしょうが、 それでもそれなりに需要はあると思います。 私が管理しているWikiのうち2つが該当するのですが、 私の場合は、トップページにセール情報の記述→終了後にコメントアウト、をセールの度に繰り返しており、 ストアウィジェットが埋め込み可能になれば、その手間が不要になり見栄えもアップすると思うので、 使えるならぜひ利用したいです。
Discordの方は、サーバーへの参加窓口が表示される、みたいなことでしょうか？ よくわからないので、やはり説明が必要です。
それと「やや改善」タグは外してください。まだ何も改善されていないのですから。
追記：
Discordの方、理解しました。
コミュニティ目的なら、zawazawa掲示板を埋め込む方法もありますが、 既にDiscordが活用されているなら、 参加ボタンとともに参加人数などが随時表示されるのは確かに便利だと思います。
なので、Steam、Discordどちらのウィジェット埋め込みプラグインの導入要望も支持します。
SteamやDiscordと関係があるwikiはよく目にするので何か便利な機能だとしたら賛成したいのですが、これらはいったい何をするプラグインなのですか？
ここのトップページ (https://z.wikiwiki.jp/wikiwiki-request/) に以下のような注意書きがあるのですが、あまり守られていないように思えます。
以下の留意点を抑えて下さい。 ・なぜそれが必要か理由を書く ・他のユーザーに賛同してもらえるように書く
SourceForgeのページを見ましたが、どちらのページも使い方などは書いてあってもどういった機能なのか・何を表示するのかが書いてないので、判断のしようがありません。
賛成します。機能として置いておくなら、色増やしてほしいです。 編集者内での共有が目的であればカラーコードで目的達成できますが、パレットはワンタップでカラー指定できるお手頃さを目当てに使っているので、カラーコードがあってもパレットの色増加はしてほしいです。
やってみたのですが文字色が白なので文字が潰れてしまいますね colorプラグインで囲っても文字色の変更はできず 赤褐色と白だとコントラスト がかなり異なるので両色の視認性がしっかり確保される背景色はないですね
確かにかなり読みにくいですね…文字と背景の境界線の認識が困難になっており、視覚的不快感も感じます。 恐らく、背景色と文字色の明度差があまりない為だと考えられます。文字をもう少し明るくすれば読めそうな気がします。(偉そうなコメントで申し訳ございません)
今すぐユーザー側で可能な対処として、異なる背景色を指定したcssboxで囲ってしまう手はあります。
//白背景で囲う #cssbox("background-color:RGB(255,255,255);"){{ #recentdetail(20,30m,3h,12h,24h,3d,1w) }}
色指定可能になるorスキンに合わせて調節されるなら、その方が親切だとは思います。
default_deepgrayでrecentdetailを使っているサイトを見ましたが、たしかにこの配色は問題です。不具合と言っていいレベルです。 recentdetailだけでなくnewプラグインも同様に、MenuBar上では赤字がまともに読めません。
機能の要望というよりも不具合に属する話題だと思うので、メンションを付けておきます。@wikiwiki
一つ例を挙げると、キャラクターが左右に移動する横長のGIF画像を使用する場面があります。 その画像の見た目にもよりますが、PC画面では見栄えがよくても、スマホ画面では不格好になりがちです。
現状の素材で見せ方を工夫するというのは確かに大切な考え方だと思いますが、 上記はあまりにも使いにくいケースであったため、画像の使用自体を断念しています。
これはあくまで一例で、最もやりたいことそのものではありません。 こういったデザイン面の悩みがいくつかあり、ページ幅がネックになることが多いため、 画面幅に応じてコンテンツの配置だけでなく、表示・非表示や使用する要素自体を切り替えられるようにしたい、というのが今回の要望です。
疑似的にスマホ用のページを別に作りたいわけではありませんが、同じページをPC・スマホのどちらで閲覧しても見栄えのする形にしたいと考えています。
需要については、以前この掲示板に表組みのレスポンシブ対応ができる機能がほしいというトピックを作成しました。 その時は対応策をご教授いただき、おかげさまでcssboxで表組みモドキを作成し、flex_boxで制御することで対応できました。
その後、似たようなトピックがあることも確認しました。 こちらも画面幅に応じて表示内容を変更したいという要望で、機能的に近いものだと思います。
例が少なく恐縮ですが、このような要望が過去にもあることから、少なくとも画面幅に応じてコンテンツを制御したいという需要はあるのではないでしょうか。
表組みに限らず、ページ幅を条件としてコンテンツ自体を制御できるプラグインがあれば、こうした問題をまとめて解決できるのではないかと思っています。 指摘いただいた悪用のリスクについて考えてみると、確かにそのような使われ方をする可能性もあると思います。 そういった点まで考慮すると、総合的に見て良い機能なのかは判断が難しいところではあります。 一方で、実現できればページ作成の幅は広がるのではないかと思います。
失礼ながら、Natchさんはより具体的に何をしたいのでしょうか。 例として挙げられた矢印の向きは文章の書き方などの"運用でカバーできそう"なので、メリットや便利さを考えづらいです。 リクエスト広場の説明文 https://z.wikiwiki.jp/wikiwiki-request/ にも書かれていますが、"他のWIKIでも需要がありそうか""なぜそれが必要か"、より深く考え、掘り下げて伝えた方が良さそうです。
flex_boxとResponsive_layoutでは、今回想定していることは実現できないと思います。
少し説明不足だったかもしれません。 重要なのはコンテンツ1、コンテンツ2ではなく、その間に挟まっている矢印です。 文字でもいいですが、例えば矢印が画像だった場合、右矢印と下矢印の画像をそれぞれ用意しておき、画面幅に応じて表示する画像を自動的に切り替える、といった処理を想定しています。
>例えばPCとスマホでソースを一部切り分けるようなものを指しているのであれば、それは言ってしまえば同一内容を指し示す部分が2つに分裂すること、 >分裂しつつも同一内容であるように編集しなくてはならないことを意味します。 仰っている内容に、やりたいことは近いです。
仮に実装された場合のデメリットまで考えていただいたことについて、ありがとうございます。 ただ、実際にそれによってどの程度のデメリットが生じるかについては、 WikiWiki運営側で判断される部分だと思いますので、そこについては何とも言えません。 あくまで一つの要望として考えていただければと思います。
現状のレスポンシブ対応は、配置の調整に限られるため、機能的に不自由さを感じる部分があります。こういった機能があれば便利ではないかと思い、要望しました。
例として挙げられたものは、https://wikiwiki.jp/sample/Flexbox または https://wikiwiki.jp/sample/Responsive_layout で十分に実現可能です。 要素の表示領域や余白の調整についても https://wikiwiki.jp/sample/cssbox で如何様にもなります。 難しい内容ですから、説明を読んで粘り強く試してみることをおすすめします。 もちろん、場合によってはそういったことをせずとも、画像の最小幅指定などで上手く収められることもあることでしょう。
もしcssにおける@media(1280px <= width)のように、特定の画面幅を閾値として要素の表示を切り替えるもの…… 例えばPCとスマホでソースを一部切り分けるようなものを指しているのであれば、それは言ってしまえば同一内容を指し示す部分が2つに分裂すること、分裂しつつも同一内容であるように編集しなくてはならないことを意味します。 加えて、閲覧環境によって表示内容に差異が生まれてしまうと閲覧者同士のコミュニケーションにも齟齬が生まれたり、特定の環境でのみ見える嫌がらせが可能となってしまったりなど、混乱を招いたり悪用されたりする可能性も十分考えられます。 そして投稿文だけでは、そうまでして"何をしたいか"が分からないというのが正直な所です。
ありがとうございます。 ひとまず、「スマブラ美術館」や個人への暴言が残っているページは削除しました。
具体的な違反箇所を列挙するのは簡単ですが、それを書いてもサイト閉鎖の危機を回避するのにほとんど役に立たない、という判断から書きませんでした。 以下に、違反の例をあげながらその理由を説明します。
禁止事項の中に「15歳以下を対象としたコミュニティの運営や、記事を作成する行為」という項目があるのは、当然ご存じのはずです。 そして判断基準の中に「4.小学生が描いたようなイラスト」という項目がありますが、「スマブラ美術館」のページはこの基準に強く当てはまっています。
ではスマブラ美術館を消せば解決するのかというと、そうではありません。 禁止事項に該当するページが存在しているのにそれを長年にわたって自力で認識できなかったという、管理体制の欠如が問題なのです。 他人から言われたところを言われたとおりに修正しても、それでは管理体制が正常化したことになりません。外部から介護を受けないと正常な管理ができない体制が継続するだけです。 wikiwiki運営が要求しているのはスマブラ美術館を消すことではなく、違反を自ら発見および解決できる管理体制だと考えるべきです。 なお、スマブラ美術館の話は複数ある問題のうちの一つにすぎません。
ありがとうございます。 恐れ入りますが、「利用規約に明確に違反しており」と判断されているのは現状どういった部分か、教えていだだきたいです。
同じように警告（のちに閉鎖）されたwikiをいくつも見てきましたが、それらと今回のwikiには共通する問題点があります。
現状でお勧めするのは、以下の方針で行動することです。何が問題なのか分からない段階でも、できることはあります。
認証に成功しても書き込めないのは、多分あなたの電話番号が個別に規制されてるよ
規制は無期限かもね 管理人は無給だし、あくまで趣味だし、個別に対応してやる義理が無い
ここはWIKIWIKIのサービスについて議論する場なんだが、トンマナ合わせず書き込めちゃうあたりそういう所なんじゃない？
私も仕様改善に賛成です。
特に「新しいファイルマネージャ」での認証要求頻度が高く、4、5回ほどファイルを選択すると以後エラーが発生し、ページをリロードして再度認証を通過しないと読み込めなくなります。
私のwikiでは画像参照用のページに画像を添付し、そこから参照する形で画像を表示させているので、1度に複数枚画像を追加する必要がある時は2、3回は認証を行う必要があり、大変作業が煩わしいです。
数時間単位での認証か、短時間における参照回数の上限を引き上げるかなどの対策を検討していただきたいです。
追記 >> 1の方の指摘を見て確認したところ、こちらでも認証が緩和されていることを確認できました。 対応いただき、ありがとうございました。
ほんとに消してほしいみんなが売ってるとこを見るだけは寂しい こいつです『ソルかが図鑑」こいつがforsaken wikiにこの制限をつけた終わってる！！！
以前は、ロボットでないことの確認が取れたら、 一定期間再チェックなしでアクセス可能だったけど、 現在は仕様変更で指摘通りになってますね。 （こちらにある「一度チェックを通過したブラウザは…」の文面は修正した方が良いです）
正直鬱陶しいし、 そう思うユーザーが多ければWikiを忌避する原因にもなり、 ユーザーだけでなく会社にとってもマイナスになるのではと思います。 なので、「閲覧者の利便性を損なわないような仕様の検討」に一票です。
改善されたようです。 ページを頻繁に切り替えてもチェック画面が現れなくなりました。 説明ページの文言も修正されています。 なので、「解決済」のタグを付けて良いのではと思います。
行・列の存在ではなく、画像とテキストの組み合わせを1セットとしてそれを縦横に並べていく目的なら、表ではなくcssboxとflexの組み合わせの方が向いています。 cssboxであればflexで生じる隙間を埋めることが可能ですし、サイズの下限・上限の指定や固定も可能です。
ありがとうございます。これから試してみます。
現在は画像と説明文を1セットとした横に長い1行の表組みを作成しています。 |画像|文字|画像|文字|画像|文字|... このような表組みです。
表組みでは画面サイズの影響で文字の折り返しが発生します。 画像のセルには背景色を設定していることもあり、セル自体のサイズが変化してしまうと見た目への影響が大きいです。 セルの縦横比を維持するために文字ではなく、表組み自体を折り返すことで見た目のバランスを維持したいと思い投稿させていただきました。
何をしたいのか想像しづらいですが、#nobrや#tablescrollの利用を検討してみてはいかがでしょうか。 どうしても並び替えた表を見せたいのであれば#tab_containerで2パターンの表を置くことはできます。
解決済は私が付けました 分かりづらいことをして申し訳ありません
前回確認した時に解決したと思っていたのですが、また同じ現象が起こっているのが確認できたので戻しておきます
2026.8.3現在、確認したところ、 ポップアウトされた表では、tablesortが無効化される仕様に変更されたようです。 「解決済」のタグが付いていますが、これを解決したというのでしょうか。 編集に関わる要素を、通知なくサイレント修正（というか改変）する運営の姿勢も疑問です。
サイレント修正は私の勘違いのようです。 （何らかの理由で、正常に動作する場合と、動作しない場合がある） ちなみに、動作確認はさんぷるWikiで行っていますが、 実際にpopout & tablesortを同時使用している別サイト（新・カイロパーク攻略Wiki）で確認したところ、 バリバリさんの報告通り、初回訪問時は正常動作、2回目訪問時は機能しない（無効化状態）を確認しました。 （念のためスーパーリロード、キャッシュの削除を試みましたが、変化は見られず） つまりこの案件は解決しておらず、原因究明と対策が求められます。 この事象について、運営の見解をお聞かせください。 @wikiwiki
先ほど同じ現象が再発していましたのでタグを不具合に戻しておきます。 確認していただけますと幸いです。
正常に動作しているのを確認しましたので解決済にしておきます。
サンプルWiki内に同様の記述がありますが、そちらでは正常に動作しているように見えます。
具体的なパラメータ指定や利用環境(ブラウザ)などを詳細に記載することで何かしら進展があるかもしれません。
サンプルWikiにおいても同事象の再現を確認しました。 環境を変えて何度か試してみましたが、２回目以降ではなく初回表示時に既に機能しなくなっていました。 誰かが一度ポップアウトを表示することがトリガーになっている可能性があります。
自分も同意見です。 ついでに言えば、リクエストした時点で「やや改善」されているのも意味不明です。
文面などから察すると、過去に無意味な提案を繰り返してきた人物と同一人物のように思われます。
https://z.wikiwiki.jp/wikiwiki-request/topic/482 https://z.wikiwiki.jp/wikiwiki-request/topic/483 https://z.wikiwiki.jp/wikiwiki-request/topic/484 https://z.wikiwiki.jp/wikiwiki-request/topic/485 https://z.wikiwiki.jp/wikiwiki-request/topic/476
指摘を受けて一部修正したようですが、 「やや改善」タグを外したのはともかく、 文章の方は「最近では管理者権限やご意見などでサポート履歴に重複が起きています」 と、ますます意味不明なものになっています。
>> 1さんが指摘しているように、
を具体的に説明しないと何も伝わらず、誰にも賛同されないと思います。 勿論、運営も動かないでしょう。 （意味不明なのですから、困惑しかないでしょう）
まず「サポート履歴」が何を指すのか分かりませんので、重複がどのような状況なのかも分かりません。 何が問題でどう改善してほしいかも全く分かりません。
もう少し具体的に説明されてはいかがでしょうか。
画像の添付自体は>> 1の方の方法でできます。 ただしwikiwikiでは512KBまでのファイルしか添付できず、それを超えるものは自動で圧縮されてしまいます。 GIFの場合はこの自動圧縮がかかると静止画になってしまうため、添付時点で512KB以下にしておく必要があります。 「GIF 圧縮」などで検索をかければ圧縮用のサイトがいくつか出てくると思うので、そちらを利用してみてください。
こちら私からも対応をお願いしたいです。 こうしたNGワード機能はコメントが完全ブロックされるのが一般的かと思うので、それをSMS認証によって回避出来るという現象は直感に反するように思えます。 （不具合としてリクエスト広場に起票する前に試しに検索してみたら、このトピックを見つけました）
zawazawaのNGワード機能は無条件でブロックされるかと思いますので、それに統一して頂きたいです。 何卒よろしくお願いします。
ありがとうございます。不具合修正確認しました。
ご連絡ありがとうございます。
上記の不具合、修正いたしました。
ご確認のほどよろしくお願い申し上げます。
https://wikiwiki.jp/sample/ファイルを添付する https://wikiwiki.jp/sample/ファイル(画像)を貼り付ける https://wikiwiki.jp/sample/他のページの添付画像を貼り付ける
特にlazy_foldを多用しているページの使用感が著しく損なわれますね。 公式のアナウンスが無いので何とも言えないですが、lazy_accordionで発生しないなら置き換えたほうがいいですかね。
賛成します。
できれば管理側でパレットの色、数は変更できると助かります。 色の検討をせず、「テンプレにあるから」で使用され、大変読みにくいwikiが散見されます。
管理人様、先ほど書き込みが制限されている件でご連絡差し上げた者です。
改めてお詫びさせてください。先ほどは操作の不手際から、大変ご迷惑をおかけして申し訳ありませんでした。決して荒らす意図はなく、記事を編集したいという気持ちが先走ってしまい、配慮に欠ける行動をしてしまいました。
今後は同じようなことは二度としません。もし制限を解除していただけるのなら、今度こそルールを守り、しっかりとした記事作成に貢献したいと考えています。
身勝手なお願いで大変恐縮ですが、ご検討いただけますと幸いです。どうぞよろしくお願いいたします。
https://wikiwiki.jp/paradigm_/
https://wikiwiki.jp/phigros/
Discordの埋め込みリンクが無い為、っぽいものをいくつかCSSで再現してるwikiもあるので、需要はそこそこあると思います
これはどちらも非常によさそうに感じました、強く支持します
返信ありがとうございます。
Steamウィジェットは>> 2様のおっしゃる通り、Steamゲームストアのセール中の価格を自動的に表示できるのようになるので見栄えアップと編集の手間を減らす目的です。
Discordウィジェットは特定のゲームのコミュニティサーバーへの窓口・案内を表示するものですが、オンライン(アクティブ)人数の表示、ボイスチャンネル(ボイスチャット)の人数表示などをリアルタイムで表示することが可能です。
自分が管理しているWikiでは、かなりマイナーな対戦ゲームを扱っており、日本人コミュニティではひっそりとDiscordで対戦・交流を行っている状態です。交流は今のところ閉鎖的な環境で「日本人ユーザーがいない」と勘違いされることも多いのかな思っており、それが外部の目に触れることでのコミュニティの活発化が狙いです。
サーバーウィジェットの詳細はこちらで紹介されています。
https://ja.101-help.com/1cc9b0b4d0-discord-widgetwowebsitenizhui-jia-surufang-fa/
しかし、Discordサーバーウィジェットの存在は日本ではあまり活用されておらず、賛同は得られにくいかなと思います。
やや改善タグは外しました。wikiwikiを使い始めてまだ数週間でまだわかっていないこともあり適当につけておりました。申し訳ございません。
はやしさんの指摘は正論ですね。
ここはリクエストと同時に、それについて議論する場所なのですから。
何ができてどんなメリットがあるのか分からないと賛同は得られにくいですし、
賛同が集まらないと、運営にスルーされる可能性が大きくなります。
Steamの方に関して言えば、Steamで扱っているゲームの攻略Wikiしか利用はないでしょうが、
それでもそれなりに需要はあると思います。
私が管理しているWikiのうち2つが該当するのですが、
私の場合は、トップページにセール情報の記述→終了後にコメントアウト、をセールの度に繰り返しており、
ストアウィジェットが埋め込み可能になれば、その手間が不要になり見栄えもアップすると思うので、
使えるならぜひ利用したいです。
Discordの方は、サーバーへの参加窓口が表示される、みたいなことでしょうか？
よくわからないので、やはり説明が必要です。
それと「やや改善」タグは外してください。まだ何も改善されていないのですから。
追記：
Discordの方、理解しました。
コミュニティ目的なら、zawazawa掲示板を埋め込む方法もありますが、
既にDiscordが活用されているなら、
参加ボタンとともに参加人数などが随時表示されるのは確かに便利だと思います。
なので、Steam、Discordどちらのウィジェット埋め込みプラグインの導入要望も支持します。
SteamやDiscordと関係があるwikiはよく目にするので何か便利な機能だとしたら賛成したいのですが、これらはいったい何をするプラグインなのですか？
ここのトップページ (https://z.wikiwiki.jp/wikiwiki-request/) に以下のような注意書きがあるのですが、あまり守られていないように思えます。
SourceForgeのページを見ましたが、どちらのページも使い方などは書いてあってもどういった機能なのか・何を表示するのかが書いてないので、判断のしようがありません。
賛成します。機能として置いておくなら、色増やしてほしいです。
編集者内での共有が目的であればカラーコードで目的達成できますが、パレットはワンタップでカラー指定できるお手頃さを目当てに使っているので、カラーコードがあってもパレットの色増加はしてほしいです。
やってみたのですが文字色が白なので文字が潰れてしまいますね
colorプラグインで囲っても文字色の変更はできず
赤褐色と白だとコントラスト
がかなり異なるので両色の視認性がしっかり確保される背景色はないですね
確かにかなり読みにくいですね…文字と背景の境界線の認識が困難になっており、視覚的不快感も感じます。
恐らく、背景色と文字色の明度差があまりない為だと考えられます。文字をもう少し明るくすれば読めそうな気がします。(偉そうなコメントで申し訳ございません)
今すぐユーザー側で可能な対処として、異なる背景色を指定したcssboxで囲ってしまう手はあります。
//白背景で囲う
#cssbox("background-color:RGB(255,255,255);"){{
#recentdetail(20,30m,3h,12h,24h,3d,1w)
}}
色指定可能になるorスキンに合わせて調節されるなら、その方が親切だとは思います。
default_deepgrayでrecentdetailを使っているサイトを見ましたが、たしかにこの配色は問題です。不具合と言っていいレベルです。
recentdetailだけでなくnewプラグインも同様に、MenuBar上では赤字がまともに読めません。
機能の要望というよりも不具合に属する話題だと思うので、メンションを付けておきます。@wikiwiki
一つ例を挙げると、キャラクターが左右に移動する横長のGIF画像を使用する場面があります。
その画像の見た目にもよりますが、PC画面では見栄えがよくても、スマホ画面では不格好になりがちです。
現状の素材で見せ方を工夫するというのは確かに大切な考え方だと思いますが、
上記はあまりにも使いにくいケースであったため、画像の使用自体を断念しています。
これはあくまで一例で、最もやりたいことそのものではありません。
こういったデザイン面の悩みがいくつかあり、ページ幅がネックになることが多いため、
画面幅に応じてコンテンツの配置だけでなく、表示・非表示や使用する要素自体を切り替えられるようにしたい、というのが今回の要望です。
疑似的にスマホ用のページを別に作りたいわけではありませんが、同じページをPC・スマホのどちらで閲覧しても見栄えのする形にしたいと考えています。
需要については、以前この掲示板に表組みのレスポンシブ対応ができる機能がほしいというトピックを作成しました。
その時は対応策をご教授いただき、おかげさまでcssboxで表組みモドキを作成し、flex_boxで制御することで対応できました。
その後、似たようなトピックがあることも確認しました。
こちらも画面幅に応じて表示内容を変更したいという要望で、機能的に近いものだと思います。
例が少なく恐縮ですが、このような要望が過去にもあることから、少なくとも画面幅に応じてコンテンツを制御したいという需要はあるのではないでしょうか。
表組みに限らず、ページ幅を条件としてコンテンツ自体を制御できるプラグインがあれば、こうした問題をまとめて解決できるのではないかと思っています。
指摘いただいた悪用のリスクについて考えてみると、確かにそのような使われ方をする可能性もあると思います。
そういった点まで考慮すると、総合的に見て良い機能なのかは判断が難しいところではあります。
一方で、実現できればページ作成の幅は広がるのではないかと思います。
失礼ながら、Natchさんはより具体的に何をしたいのでしょうか。
例として挙げられた矢印の向きは文章の書き方などの"運用でカバーできそう"なので、メリットや便利さを考えづらいです。
リクエスト広場の説明文 https://z.wikiwiki.jp/wikiwiki-request/ にも書かれていますが、"他のWIKIでも需要がありそうか""なぜそれが必要か"、より深く考え、掘り下げて伝えた方が良さそうです。
flex_boxとResponsive_layoutでは、今回想定していることは実現できないと思います。
少し説明不足だったかもしれません。
重要なのはコンテンツ1、コンテンツ2ではなく、その間に挟まっている矢印です。
文字でもいいですが、例えば矢印が画像だった場合、右矢印と下矢印の画像をそれぞれ用意しておき、画面幅に応じて表示する画像を自動的に切り替える、といった処理を想定しています。
>例えばPCとスマホでソースを一部切り分けるようなものを指しているのであれば、それは言ってしまえば同一内容を指し示す部分が2つに分裂すること、
>分裂しつつも同一内容であるように編集しなくてはならないことを意味します。
仰っている内容に、やりたいことは近いです。
仮に実装された場合のデメリットまで考えていただいたことについて、ありがとうございます。
ただ、実際にそれによってどの程度のデメリットが生じるかについては、
WikiWiki運営側で判断される部分だと思いますので、そこについては何とも言えません。
あくまで一つの要望として考えていただければと思います。
現状のレスポンシブ対応は、配置の調整に限られるため、機能的に不自由さを感じる部分があります。こういった機能があれば便利ではないかと思い、要望しました。
例として挙げられたものは、https://wikiwiki.jp/sample/Flexbox または
https://wikiwiki.jp/sample/Responsive_layout で十分に実現可能です。
要素の表示領域や余白の調整についても https://wikiwiki.jp/sample/cssbox で如何様にもなります。
難しい内容ですから、説明を読んで粘り強く試してみることをおすすめします。
もちろん、場合によってはそういったことをせずとも、画像の最小幅指定などで上手く収められることもあることでしょう。
もしcssにおける@media(1280px <= width)のように、特定の画面幅を閾値として要素の表示を切り替えるもの……
例えばPCとスマホでソースを一部切り分けるようなものを指しているのであれば、それは言ってしまえば同一内容を指し示す部分が2つに分裂すること、分裂しつつも同一内容であるように編集しなくてはならないことを意味します。
加えて、閲覧環境によって表示内容に差異が生まれてしまうと閲覧者同士のコミュニケーションにも齟齬が生まれたり、特定の環境でのみ見える嫌がらせが可能となってしまったりなど、混乱を招いたり悪用されたりする可能性も十分考えられます。
そして投稿文だけでは、そうまでして"何をしたいか"が分からないというのが正直な所です。
ありがとうございます。
ひとまず、「スマブラ美術館」や個人への暴言が残っているページは削除しました。
具体的な違反箇所を列挙するのは簡単ですが、それを書いてもサイト閉鎖の危機を回避するのにほとんど役に立たない、という判断から書きませんでした。
以下に、違反の例をあげながらその理由を説明します。
禁止事項の中に「15歳以下を対象としたコミュニティの運営や、記事を作成する行為」という項目があるのは、当然ご存じのはずです。
そして判断基準の中に「4.小学生が描いたようなイラスト」という項目がありますが、「スマブラ美術館」のページはこの基準に強く当てはまっています。
ではスマブラ美術館を消せば解決するのかというと、そうではありません。
禁止事項に該当するページが存在しているのにそれを長年にわたって自力で認識できなかったという、管理体制の欠如が問題なのです。
他人から言われたところを言われたとおりに修正しても、それでは管理体制が正常化したことになりません。外部から介護を受けないと正常な管理ができない体制が継続するだけです。
wikiwiki運営が要求しているのはスマブラ美術館を消すことではなく、違反を自ら発見および解決できる管理体制だと考えるべきです。
なお、スマブラ美術館の話は複数ある問題のうちの一つにすぎません。
ありがとうございます。
恐れ入りますが、「利用規約に明確に違反しており」と判断されているのは現状どういった部分か、教えていだだきたいです。
共通点
同じように警告（のちに閉鎖）されたwikiをいくつも見てきましたが、それらと今回のwikiには共通する問題点があります。
お勧めする今後の方針
現状でお勧めするのは、以下の方針で行動することです。何が問題なのか分からない段階でも、できることはあります。
（何が悪いのか分からないのなら、正しく判断できるようになるまで一旦全部引っ込める、という考え）
認証に成功しても書き込めないのは、多分あなたの電話番号が個別に規制されてるよ
規制は無期限かもね
管理人は無給だし、あくまで趣味だし、個別に対応してやる義理が無い
ここはWIKIWIKIのサービスについて議論する場なんだが、トンマナ合わせず書き込めちゃうあたりそういう所なんじゃない？
私も仕様改善に賛成です。
特に「新しいファイルマネージャ」での認証要求頻度が高く、4、5回ほどファイルを選択すると以後エラーが発生し、ページをリロードして再度認証を通過しないと読み込めなくなります。
私のwikiでは画像参照用のページに画像を添付し、そこから参照する形で画像を表示させているので、1度に複数枚画像を追加する必要がある時は2、3回は認証を行う必要があり、大変作業が煩わしいです。
数時間単位での認証か、短時間における参照回数の上限を引き上げるかなどの対策を検討していただきたいです。
追記
>> 1の方の指摘を見て確認したところ、こちらでも認証が緩和されていることを確認できました。
対応いただき、ありがとうございました。
ほんとに消してほしいみんなが売ってるとこを見るだけは寂しい
こいつです『ソルかが図鑑」こいつがforsaken wikiにこの制限をつけた終わってる！！！
以前は、ロボットでないことの確認が取れたら、
一定期間再チェックなしでアクセス可能だったけど、
現在は仕様変更で指摘通りになってますね。
（こちらにある「一度チェックを通過したブラウザは…」の文面は修正した方が良いです）
正直鬱陶しいし、
そう思うユーザーが多ければWikiを忌避する原因にもなり、
ユーザーだけでなく会社にとってもマイナスになるのではと思います。
なので、「閲覧者の利便性を損なわないような仕様の検討」に一票です。
追記：
改善されたようです。
ページを頻繁に切り替えてもチェック画面が現れなくなりました。
説明ページの文言も修正されています。
なので、「解決済」のタグを付けて良いのではと思います。
行・列の存在ではなく、画像とテキストの組み合わせを1セットとしてそれを縦横に並べていく目的なら、表ではなくcssboxとflexの組み合わせの方が向いています。
cssboxであればflexで生じる隙間を埋めることが可能ですし、サイズの下限・上限の指定や固定も可能です。
ありがとうございます。これから試してみます。
現在は画像と説明文を1セットとした横に長い1行の表組みを作成しています。
|画像|文字|画像|文字|画像|文字|... このような表組みです。
表組みでは画面サイズの影響で文字の折り返しが発生します。
画像のセルには背景色を設定していることもあり、セル自体のサイズが変化してしまうと見た目への影響が大きいです。
セルの縦横比を維持するために文字ではなく、表組み自体を折り返すことで見た目のバランスを維持したいと思い投稿させていただきました。
何をしたいのか想像しづらいですが、#nobrや#tablescrollの利用を検討してみてはいかがでしょうか。
どうしても並び替えた表を見せたいのであれば#tab_containerで2パターンの表を置くことはできます。
解決済は私が付けました
分かりづらいことをして申し訳ありません
前回確認した時に解決したと思っていたのですが、また同じ現象が起こっているのが確認できたので戻しておきます
2026.8.3現在、確認したところ、
ポップアウトされた表では、tablesortが無効化される仕様に変更されたようです。
「解決済」のタグが付いていますが、これを解決したというのでしょうか。
編集に関わる要素を、通知なくサイレント修正（というか改変）する運営の姿勢も疑問です。
追記：
サイレント修正は私の勘違いのようです。
（何らかの理由で、正常に動作する場合と、動作しない場合がある）
ちなみに、動作確認はさんぷるWikiで行っていますが、
実際にpopout & tablesortを同時使用している別サイト（新・カイロパーク攻略Wiki）で確認したところ、
バリバリさんの報告通り、初回訪問時は正常動作、2回目訪問時は機能しない（無効化状態）を確認しました。
（念のためスーパーリロード、キャッシュの削除を試みましたが、変化は見られず）
つまりこの案件は解決しておらず、原因究明と対策が求められます。
この事象について、運営の見解をお聞かせください。
@wikiwiki
先ほど同じ現象が再発していましたのでタグを不具合に戻しておきます。
確認していただけますと幸いです。
正常に動作しているのを確認しましたので解決済にしておきます。
サンプルWiki内に同様の記述がありますが、そちらでは正常に動作しているように見えます。具体的なパラメータ指定や利用環境(ブラウザ)などを詳細に記載することで何かしら進展があるかもしれません。サンプルWikiにおいても同事象の再現を確認しました。
環境を変えて何度か試してみましたが、２回目以降ではなく初回表示時に既に機能しなくなっていました。
誰かが一度ポップアウトを表示することがトリガーになっている可能性があります。
自分も同意見です。
ついでに言えば、リクエストした時点で「やや改善」されているのも意味不明です。
文面などから察すると、過去に無意味な提案を繰り返してきた人物と同一人物のように思われます。
https://z.wikiwiki.jp/wikiwiki-request/topic/482
https://z.wikiwiki.jp/wikiwiki-request/topic/483
https://z.wikiwiki.jp/wikiwiki-request/topic/484
https://z.wikiwiki.jp/wikiwiki-request/topic/485
https://z.wikiwiki.jp/wikiwiki-request/topic/476
追記：
指摘を受けて一部修正したようですが、
「やや改善」タグを外したのはともかく、
文章の方は「最近では管理者権限やご意見などでサポート履歴に重複が起きています」
と、ますます意味不明なものになっています。
>> 1さんが指摘しているように、
を具体的に説明しないと何も伝わらず、誰にも賛同されないと思います。
勿論、運営も動かないでしょう。
（意味不明なのですから、困惑しかないでしょう）
まず「サポート履歴」が何を指すのか分かりませんので、重複がどのような状況なのかも分かりません。
何が問題でどう改善してほしいかも全く分かりません。
もう少し具体的に説明されてはいかがでしょうか。
画像の添付自体は>> 1の方の方法でできます。
ただしwikiwikiでは512KBまでのファイルしか添付できず、それを超えるものは自動で圧縮されてしまいます。
GIFの場合はこの自動圧縮がかかると静止画になってしまうため、添付時点で512KB以下にしておく必要があります。
「GIF 圧縮」などで検索をかければ圧縮用のサイトがいくつか出てくると思うので、そちらを利用してみてください。
こちら私からも対応をお願いしたいです。
こうしたNGワード機能はコメントが完全ブロックされるのが一般的かと思うので、それをSMS認証によって回避出来るという現象は直感に反するように思えます。
（不具合としてリクエスト広場に起票する前に試しに検索してみたら、このトピックを見つけました）
zawazawaのNGワード機能は無条件でブロックされるかと思いますので、それに統一して頂きたいです。
何卒よろしくお願いします。
ありがとうございます。不具合修正確認しました。
ご連絡ありがとうございます。
上記の不具合、修正いたしました。
ご確認のほどよろしくお願い申し上げます。
https://wikiwiki.jp/sample/ファイルを添付する
https://wikiwiki.jp/sample/ファイル(画像)を貼り付ける
https://wikiwiki.jp/sample/他のページの添付画像を貼り付ける
特にlazy_foldを多用しているページの使用感が著しく損なわれますね。
公式のアナウンスが無いので何とも言えないですが、lazy_accordionで発生しないなら置き換えたほうがいいですかね。
賛成します。
できれば管理側でパレットの色、数は変更できると助かります。
色の検討をせず、「テンプレにあるから」で使用され、大変読みにくいwikiが散見されます。
管理人様、先ほど書き込みが制限されている件でご連絡差し上げた者です。
改めてお詫びさせてください。先ほどは操作の不手際から、大変ご迷惑をおかけして申し訳ありませんでした。決して荒らす意図はなく、記事を編集したいという気持ちが先走ってしまい、配慮に欠ける行動をしてしまいました。
今後は同じようなことは二度としません。もし制限を解除していただけるのなら、今度こそルールを守り、しっかりとした記事作成に貢献したいと考えています。
身勝手なお願いで大変恐縮ですが、ご検討いただけますと幸いです。どうぞよろしくお願いいたします。