下部に余白が生じる原因は、スタイルシートの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
こちら実装を確認しました。アップロード後のリロード待機時間が無くなり快適です。 実装ありがとうございました。
直接的な解決策ではありませんが、REST APIを使うことで手間を減らすことは可能です。 (参考)https://z.wikiwiki.jp/wikiwiki-rest-api/topic/3 例えば指定ディレクトリ配下の画像に対して、自動で繰り返しアップロードをするといったスクリプトが考えられます。 ご参考になれば。
同時に10枚アップすれば、単純に同時処理負荷は10倍になり、 複数人でDoS攻撃を仕掛けるDDoS攻撃がそれだけやり易くなります。 wikiwiki.jpにアクセスし難い状況になれば、 利用者全員が迷惑を被るということに思い至りませんか？ それとも自分が楽できれば他のことは知らんがなということでしょうか。
枚数や容量で制限したところで、悪意ある人物が簡単にサーバーをいじめること(DoS攻撃)がやりやすくなってしまうことは大して変わりませんよ…… そうでなくとも、グロ画像のような不快な画像を大量に添付するイタズラは随分やりやすくなりそうです
私も複数枚まとめてアップデートできるようになると助かります。 一括添付は画像10枚まで、または合計○○KBまで、などの制限付きでも良いので、いくらか編集作業の負担が減るととても嬉しいです。
おそらく同様の現象を今年の3月あたりから確認しています。 https://z.wikiwiki.jp/wikiwiki-request/topic/386 こちらも未だに継続しており困っています…。
必死ですね。
無理な要望だと思います。 （何故1枚ずつしかアップできない仕様なのか考えたことありますか？）
貴方のリクエストは、 （貴方にその自覚がなくても）DoS攻撃させろと言っているのと同義です。
しばらく、元の仕様、一枚ずつアップロードのままやっています。「アップロード時にページをリロードしない」機能で少し便利になりましたが、やはり一度にたくさんの画像を添付したいです。どうにかできないでしょうか？
https://z.wikiwiki.jp/wikiwiki-request/topic/427/16
私のほうでも確認できました ご対応いただきありがとうございました！
恐らく今日？「アップロード後にページをリロードしない(チェックマーク)」の機能が添付ページ追加されたようです。 「1回開くための負荷」と「添付ページに更新を反映させるために再読み込みする負荷(添付自体は行われているため必須ではない)」以外は高負荷にならなくなったため、非常に助かりました。 暫定的な対応か分かりませんが、対応ありがとうございました。
https://wikiwiki.jp/p/information/view?id=10
・WikiWiki全体に季節性の荒らし行為が多発している。 ・管理人以外のユーザーには規制が必要。 ・生成AIが多い。 ・他のWikiから引用している。 ・永久にSMS認証を続けてほしい。 ・その他
リクエスト広場トップに書かれている文言を引用します。
・案件にあったタグを使用する ・提案（要望）を具体的に書く ・なぜそれが必要か理由を書く ・他のユーザーに賛同してもらえるように書く
本件は通称ニコニコ外部プレーヤーのことを指していると推測します。動画ページの共有ボタンから埋め込みコードを表示できます。※PC版限定です
WIKIWIKIの現機能は2007年に導入されているのでそうなっています。現在のニコニコ動画に直リンク禁止規定はありません。そもそも共有ボタンで配布しているURLが直リンクと変わりありません。
ニコニコ動画様は動画の直リンクを許可しておりませんので サムネイル形式の表示になります。
https://wikiwiki.jp/sample/ニコニコ動画
ご確認ありがとうございます。 ご不便をおかけしてしまい、申し訳ありませんでした。
>> 5 ありがとうございます。いくつか可能なパターンがあるのは確認できました。ただ、どのように&br;を入れると任意の行数でも意図した表が実現できるのかが分からないので、ちょっとすぐには使えなさそうですね……
なるほど、たしかに閲覧に使用するブラウザによって結果が変わるようです。最初に示した方法は、chromeやedgeでうまくいきませんでした。 以下の書き方なら、chromeでも意図した結果になりました。
|左1&br;左1|右1| |~|右2| |左2&br;左2|~| |~|右3|
空白だけの行を入れたりしてセルの縦幅を変えることで、見え方を調整できると思います。
>> 3 上記環境はGoogle Chrome (PCおよびiPad)とSafari (iPhone)で発生していたのですが、 試しにFirefoxで開いてみたら上手く表示されました。 このあたりは既知の現象なのでしょうか？
なお、Chrome環境下で https://wikiwiki.jp/sandbox/ を編集すると同様の事象が発生するので、デザインテンプレートに起因する現象ではないと思われます。
示した方法は事前に試していますし、今改めて試しても、やはりうまくいきます。そういったおかしな表示にはなりません。 もしかしたら、使用しているデザインテンプレートによっては、起きるのかもしれません。 実際にうまくいかなかったwikiの場所をハッキリさせたほうが、解決しやすいと思います。
それがですね、このような表示になってしまうのです
そう断言する根拠は何でしょう？
「再圧縮めんどくせー」「iPhone 6s・7を見殺しにできねー」という大きな障害がある割に、
https://www.microsoft.com/ja-jp/ https://studio.design/ja https://www.wix.com/
この3ページ（下2つはWeb上でホームページを作成できるサービスのトップページ）の画像のAVIF率が高いのはその需要の（潜在的な）高さを物語っています。
特に現在WebP止まりなサイトも多い一番の原因が「iPhone 6s・7を見殺しにできねー」であり、WikiWikiが対応したとして広く認知される頃にはこれの影響度合いもさらに減っていくでしょう。
リミッターを超過した画像をWebPで再圧縮して表示しています
元がJPEGの場合、これをWebPの代わりにAVIFに再圧縮すれば、より少ないストレージ容量でより粗が目立たない高品質な画像を提供できます。 特に、一部のJPEG画像（YUV444のもの）は、YUV420固定の非可逆WebPにしてしまうと特に色線の色が変わってしまいます。
AVIFはロスレス圧縮にも対応しています
全く実用的ではありません。WebPのロスレスは優秀ですので、JPEG XLが全ブラウザで解禁されるまでは、ロスレスWebP、非可逆はAVIFの流れに着実になっていくでしょう。
Windows 11のペイントも未対応な現状で「既にメジャー」は言い過ぎでしょう。
WebPも非対応ですが？
以下のように書けば、実現できます
|左1|右1| |~|右2| |左2|~| |~|右3|
ご確認・ご対応ありがとうございます。 手元でも確かに不具合修正が適用されている事を確認しました。
ご確認ありがとうございます。
こちらでの反映がうまく行われておらず、修正が適用されていない状態になっていました。 お時間を取らせてしまい、申し訳ありません。
現在は反映を完了しており、正常に動作することを確認しております。 お手数をおかけしますが、もう一度ご確認いただけますと幸いです。
下記Wikiで自分の編集履歴から動作確認しましたが、当該症状は改善していないように見られます。 お手数ですが、改めてご確認の程お願いします。 https://wikiwiki.jp/he8_hw2jo/
便乗するような形になるのと、結果として負荷が増す可能性のある提案となって申し訳ないのですが、添付ファイルのサムネイル表示も望みます。 現状、添付ファイルはファイル名でしか一覧確認できず、重複したアップロードが起こりやすい環境にあります。この点をサムネイル表示等で改善できれば、仮にページ分割して画像を管理するとしても、重複するアップロードを減らすことができるのではないかと思った次第です。
賛成します。 Wikiの種別や用途によって必要性は変わってくるとは思いますが、既に>> 5さんがいくつか例示されている通り、画像添付専用のページを用意するという方法は決してマイナーではないと思います。
当方のWikiでも同様の手法を取っており、質問主さんの「ある特定のページに画像を集中させることによる編集負荷軽減」にも大いに賛同できます。カテゴリーごとに分散してアップロードすれば良いという意見もごもっともですが、不特定多数が編集する以上、どこにどのような画像をアップロードするのか、あるいはされたのか管理することは現実的ではありません。(その結果重複してアップロードした場合、逆に負荷が増すと見なすこともできます。) そういった点では、>> 1さんが指摘されている「倉庫利用」や>> 3さんの「そのWikiでの特別な事情」には当てはまらないと思います。
また、一般的なページの利用方法であっても、極端に画像が多いページでは同様の事象が発生する可能性があり、改善を望みます。
下部に余白が生じる原因は、スタイルシートの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
こちら実装を確認しました。アップロード後のリロード待機時間が無くなり快適です。
実装ありがとうございました。
直接的な解決策ではありませんが、REST APIを使うことで手間を減らすことは可能です。
(参考)https://z.wikiwiki.jp/wikiwiki-rest-api/topic/3
例えば指定ディレクトリ配下の画像に対して、自動で繰り返しアップロードをするといったスクリプトが考えられます。
ご参考になれば。
同時に10枚アップすれば、単純に同時処理負荷は10倍になり、
複数人でDoS攻撃を仕掛けるDDoS攻撃がそれだけやり易くなります。
wikiwiki.jpにアクセスし難い状況になれば、
利用者全員が迷惑を被るということに思い至りませんか？
それとも自分が楽できれば他のことは知らんがなということでしょうか。
枚数や容量で制限したところで、悪意ある人物が簡単にサーバーをいじめること(DoS攻撃)がやりやすくなってしまうことは大して変わりませんよ……
そうでなくとも、グロ画像のような不快な画像を大量に添付するイタズラは随分やりやすくなりそうです
私も複数枚まとめてアップデートできるようになると助かります。
一括添付は画像10枚まで、または合計○○KBまで、などの制限付きでも良いので、いくらか編集作業の負担が減るととても嬉しいです。
おそらく同様の現象を今年の3月あたりから確認しています。
https://z.wikiwiki.jp/wikiwiki-request/topic/386
こちらも未だに継続しており困っています…。
必死ですね。
無理な要望だと思います。
（何故1枚ずつしかアップできない仕様なのか考えたことありますか？）
貴方のリクエストは、
（貴方にその自覚がなくても）DoS攻撃させろと言っているのと同義です。
しばらく、元の仕様、一枚ずつアップロードのままやっています。「アップロード時にページをリロードしない」機能で少し便利になりましたが、やはり一度にたくさんの画像を添付したいです。どうにかできないでしょうか？
https://z.wikiwiki.jp/wikiwiki-request/topic/427/16
私のほうでも確認できました
ご対応いただきありがとうございました！
恐らく今日？「アップロード後にページをリロードしない(チェックマーク)」の機能が添付ページ追加されたようです。
「1回開くための負荷」と「添付ページに更新を反映させるために再読み込みする負荷(添付自体は行われているため必須ではない)」以外は高負荷にならなくなったため、非常に助かりました。
暫定的な対応か分かりませんが、対応ありがとうございました。
https://wikiwiki.jp/p/information/view?id=10
・WikiWiki全体に季節性の荒らし行為が多発している。
・管理人以外のユーザーには規制が必要。
・生成AIが多い。
・他のWikiから引用している。
・永久にSMS認証を続けてほしい。
・その他
リクエスト広場トップに書かれている文言を引用します。
本件は通称ニコニコ外部プレーヤーのことを指していると推測します。動画ページの共有ボタンから埋め込みコードを表示できます。※PC版限定です
WIKIWIKIの現機能は2007年に導入されているのでそうなっています。現在のニコニコ動画に直リンク禁止規定はありません。そもそも共有ボタンで配布しているURLが直リンクと変わりありません。
https://wikiwiki.jp/sample/ニコニコ動画
ご確認ありがとうございます。
ご不便をおかけしてしまい、申し訳ありませんでした。
>> 5
ありがとうございます。いくつか可能なパターンがあるのは確認できました。ただ、どのように&br;を入れると任意の行数でも意図した表が実現できるのかが分からないので、ちょっとすぐには使えなさそうですね……
なるほど、たしかに閲覧に使用するブラウザによって結果が変わるようです。最初に示した方法は、chromeやedgeでうまくいきませんでした。
以下の書き方なら、chromeでも意図した結果になりました。
空白だけの行を入れたりしてセルの縦幅を変えることで、見え方を調整できると思います。
>> 3
上記環境はGoogle Chrome (PCおよびiPad)とSafari (iPhone)で発生していたのですが、
試しにFirefoxで開いてみたら上手く表示されました。
このあたりは既知の現象なのでしょうか？
なお、Chrome環境下で https://wikiwiki.jp/sandbox/ を編集すると同様の事象が発生するので、デザインテンプレートに起因する現象ではないと思われます。
示した方法は事前に試していますし、今改めて試しても、やはりうまくいきます。そういったおかしな表示にはなりません。
もしかしたら、使用しているデザインテンプレートによっては、起きるのかもしれません。
実際にうまくいかなかったwikiの場所をハッキリさせたほうが、解決しやすいと思います。
それがですね、このような表示になってしまうのです
「再圧縮めんどくせー」「iPhone 6s・7を見殺しにできねー」という大きな障害がある割に、
https://www.microsoft.com/ja-jp/
https://studio.design/ja
https://www.wix.com/
この3ページ（下2つはWeb上でホームページを作成できるサービスのトップページ）の画像のAVIF率が高いのはその需要の（潜在的な）高さを物語っています。
特に現在WebP止まりなサイトも多い一番の原因が「iPhone 6s・7を見殺しにできねー」であり、WikiWikiが対応したとして広く認知される頃にはこれの影響度合いもさらに減っていくでしょう。
元がJPEGの場合、これをWebPの代わりにAVIFに再圧縮すれば、より少ないストレージ容量でより粗が目立たない高品質な画像を提供できます。
特に、一部のJPEG画像（YUV444のもの）は、YUV420固定の非可逆WebPにしてしまうと特に色線の色が変わってしまいます。
全く実用的ではありません。WebPのロスレスは優秀ですので、JPEG XLが全ブラウザで解禁されるまでは、ロスレスWebP、非可逆はAVIFの流れに着実になっていくでしょう。
WebPも非対応ですが？
以下のように書けば、実現できます
ご確認・ご対応ありがとうございます。
手元でも確かに不具合修正が適用されている事を確認しました。
ご確認ありがとうございます。
こちらでの反映がうまく行われておらず、修正が適用されていない状態になっていました。
お時間を取らせてしまい、申し訳ありません。
現在は反映を完了しており、正常に動作することを確認しております。
お手数をおかけしますが、もう一度ご確認いただけますと幸いです。
ご確認ありがとうございます。
下記Wikiで自分の編集履歴から動作確認しましたが、当該症状は改善していないように見られます。
お手数ですが、改めてご確認の程お願いします。
https://wikiwiki.jp/he8_hw2jo/
便乗するような形になるのと、結果として負荷が増す可能性のある提案となって申し訳ないのですが、添付ファイルのサムネイル表示も望みます。
現状、添付ファイルはファイル名でしか一覧確認できず、重複したアップロードが起こりやすい環境にあります。この点をサムネイル表示等で改善できれば、仮にページ分割して画像を管理するとしても、重複するアップロードを減らすことができるのではないかと思った次第です。
賛成します。
Wikiの種別や用途によって必要性は変わってくるとは思いますが、既に>> 5さんがいくつか例示されている通り、画像添付専用のページを用意するという方法は決してマイナーではないと思います。
当方のWikiでも同様の手法を取っており、質問主さんの「ある特定のページに画像を集中させることによる編集負荷軽減」にも大いに賛同できます。カテゴリーごとに分散してアップロードすれば良いという意見もごもっともですが、不特定多数が編集する以上、どこにどのような画像をアップロードするのか、あるいはされたのか管理することは現実的ではありません。(その結果重複してアップロードした場合、逆に負荷が増すと見なすこともできます。)
そういった点では、>> 1さんが指摘されている「倉庫利用」や>> 3さんの「そのWikiでの特別な事情」には当てはまらないと思います。
また、一般的なページの利用方法であっても、極端に画像が多いページでは同様の事象が発生する可能性があり、改善を望みます。