プラグイン #ActivityPub が6.0.0に更新された時からの症状だが、6.0.2に更新されても直ってないので、このまま続きそうだから、メモしておく。以前の方が良かった。
フォローボタンを押した時に表示されるウインドウが6.0.0から変わって、モーダルウィンドウ風になった。そのせいだと思うが、 #WordPress の記事を作成する際の設定が反映されてるのか、見出しが追加されてしまった。さらに、z-indexの問題のように、ウインドウの下の文字が透けて表示されている。指摘されている様子がないから、 #Cocoon の問題なのか?


コメント
"z-indexは、親要素のz-indexの影響を受ける。
つまり、モーダルで開くウィンドウのz-indexは30ですが、その親要素のメインウィンドウがz-index:10であるため、その影響を受けているという事です。
サイドにあるお問い合わせボタンは、メインのウィンドウの外にありますので、z-index:20となりますが、モーダルで開くウィンドウのz-indexは、その親要素のメインウィンドウの影響を受け、z-index:10になるためです。
"
モーダルウィンドウでz-indexが効かない事象に遭遇 | RishunTrading
https://rishuntrading.co.jp/blog/css/modal_z-index_not_use/#modal
ここでのケースは、それとは別の原因らしい。
.sidebar-scroll{position: -webkit-sticky; position: sticky; top: 0;}の「top: 0」を無効にすると直る。「position: sticky;」を無効にしても直る。
違った。
.sidebar-scroll{position: -webkit-sticky; position: sticky; top: 0;}のstickyを触ったら画面から消えただけでモーダルウィンドウの下に移ったわけではなかった。
問題のz-indexに関しては親ウインドウで見当たらないし、上になっているサイドバーのz-indexはauto。
もっとよく探せば良いのかもしれないが、これはテーマに問題があるとするべきか、プラグイン #ActivityPub に問題があるとするべきか?
モーダルウインドウを使わない通常のボップアップウインドウの時は問題が無かった。元に戻してほしい。
モーダルウインドウのスタイル。
「z-index: 100000;」と異常に高くしてある。その親ウインドウのz-indexはauto。サイドバーのz-indexもauto。
.activitypub-modal__overlay {
align-items: center;
background-color: rgba(0,0,0,.5);
bottom: 0;
color: initial;
display: flex;
justify-content: center;
left: 0;
padding: 1rem;
position: fixed;
right: 0;
top: 0;
z-index: 100000;
}
こっちの方は、重なっているサイドバーのプロフィールボックス(.author-box)のposition: relative;をオフにすることでモーダルウインドウの下に隠れる。
z-indexの無視は「CSSのスタッキングコンテキストという概念が原因」との #Gemini のアドバイスがあったが、Geminiにも再現コードは作れなかった。
ちなみに、モーダルウインドウのdivはメインウインドウの内側にあり、サイドバーのdivはメインウインドウの内側にはない。それでも、メインウインドウ内のモーダルウインドウがサイドバーも隠す。それなのに、サイドバー内のposition: relative;ブロックやposition: sticky;ブロックはモーダルウインドウの上に表示されてしまう。この「上」とはレイヤーで上ということで、Geminiは画面内の位置の上下と勘違いしてしまうので、相談する際には注意が必要。
他にも「目次」が勝手に生成される問題があるので、モーダルウインドウを使うことにしたことがそもそもの間違いなんだと思う。
"z-indexは、親要素のz-indexの影響を受ける。
"
モーダルウィンドウでz-indexが効かない事象に遭遇 | RishunTrading
https://rishuntrading.co.jp/blog/css/modal_z-index_not_use/#modal
これは少し違うかも。
「お問い合わせ」の.blog0513-sideには「position: fixed;」がある。これを無くすと、同じz-indexでも、「お問い合わせ」はモーダルウインドウに隠される。
ちなみに、モーダルウインドウの背景画像に透かしがあると分かりにくいから、
モーダルウインドウをbackground-color: rgba(0, 0, 0, 1.0);にした方が分かりやすい。
確認するためのコード。
#Gemini に尋ねたら
「申し訳ありませんが、ご提示のコードのCSS設定(特にrgba(0,0,0,1.0))では、「お問い合わせ」ボタンがモーダルウィンドウに隠れずに見える状況は通常起こり得ません。z-index: 30がz-index: 20より優先され、かつ背景が不透明であれば、手前の要素が後ろの要素を覆い隠すのがCSSの標準的な挙動だからです。」とのこと。
この回答を得るまで、「隠れない」と質問文に書いたのに「隠れた」と解釈して解説するなど、こちらの質問の意図を理解させるのに苦労した。
さらに #Gemini に尋ねた結果。
この現象が他のウェブサイトでも見られるとのことなので、これは単なるCSSのバグや実装の癖というよりは、z-indexとスタックコンテキストの、開発者が見落としがちな複雑な相互作用によるものと考えられます。
特に、position: fixed、position: sticky、position: relativeといった要素が異なるスタックコンテキストを形成し、その中でz-indexがどのように作用するかは、直感に反することがあります。
結論として、ご提供いただいたコードと画像だけでは、z-indexの数値が示す通常の挙動と異なるため、具体的な原因を特定するのは非常に困難です。 しかし、positionプロパティを無効にすると解決するという情報から、やはりスタックコンテキストの予期せぬ生成と、そのスタックコンテキスト間の描画順序の決定方法が複雑に絡み合っていることが最も有力な推測です。
これは「原因不明」というよりは、「ごく一般的なCSSのルールだけでは説明しきれない、より深いスタックコンテキストの挙動が絡んでいる可能性が高い」と言えます。特に、ブラウザがどのように描画ツリーを構築し、どの要素をどのレイヤーに配置するかは、非常に複雑なプロセスであり、具体的な原因はブラウザの開発者ツールで詳細なレイヤー情報(Layersパネルなど)を確認しないと特定が難しい場合が多いです。
やっぱり
"z-indexは、親要素のz-indexの影響を受ける。
"
モーダルウィンドウでz-indexが効かない事象に遭遇 | RishunTrading
https://rishuntrading.co.jp/blog/css/modal_z-index_not_use/#modal
これで正しいのかも。親要素z-indexを上げると、確かに正常になる。
では、私の #WordPress で起こっているのは?
見つけた。
#WordPress のコンテンツ側 .main に「z-index: 0;」。
一番下にするようになっているから、サイドバーは確実にこれよりも上。
.mainの中にあるモーダルウインドウは.mainの「z-index: 0;」に引っ張られてサイドバーのコンテンツよりも下になったのかもしれない。
.mainの「z-index: auto;」にすれば、モーダルウインドウの方が上になる。
確認用コード。
#Gemini の解説。
以前のコードから`#main`と`.sub-in`の`z-index`が`0`から`auto`に変更されたことで「サブウインドウの中身」がモーダルウィンドウに隠れるようになったのは、**`z-index: auto`がスタッキングコンテキストの生成と重なり順に与える影響**によるものです。
---
### 原因の詳細
以前のコードでは、`#main`に`z-index: 0;`、`.sub-in`に`z-index: 200;`が設定されていました。
* **前回のコードの問題点**:
* `#main` (`position: relative; z-index: 0;`) は**新しいスタッキングコンテキスト**を生成します。その子要素である`.demo-modal` (`position: fixed; z-index: 1000;`) はこの`#main`のスタッキングコンテキスト内で最も高い層に描画されます。
* `.sub-in` (`position: relative; z-index: 200;`) も**新しいスタッキングコンテキスト**を生成します。
* ここで重要なのは、`#main`と`#sub`(`.sub-in`の親要素)は、**同じ親`div`の兄弟要素**であるという点です。`z-index`は、基本的に**同じスタッキングコンテキスト内の兄弟要素間**で重なり順を決定します。
* `#main`と`#sub`はそれぞれ異なるスタッキングコンテキストを持つため、それぞれの内部要素の`z-index`(`demo-modal`の`1000`と`sub-in`の`200`)が直接比較されることはありませんでした。
* `#main`と`#sub`の間で`z-index`が設定されていなかった(または`#main`が`0`、`#sub`がデフォルトの`auto`)ため、DOMの描画順が優先され、DOMで後に記述されている`#sub`(そしてその子である`.sub-in`)が`#main`(そしてその子である`.demo-modal`)の上に描画されていました。これが「隠れない」原因でした。
* **今回のコードで解決した理由 (`z-index: auto`へ変更)**:
* `#main`の`z-index`が`auto`になりました。
* `.sub-in`の`z-index`も`auto`になりました。
`z-index: auto`が指定された要素は、`position`プロパティが`static`以外に設定されていても、**新しいスタッキングコンテキストを生成しません**(ただし、特定のCSSプロパティの組み合わせによってはスタッキングコンテキストが生成される場合もありますが、このケースでは該当しません)。
したがって、今回のコードでは:
1. `#main`は`position: relative;`ですが、`z-index: auto`であるため、それ自体では**新しいスタッキングコンテキストを生成しません**。代わりに、親要素のスタッキングコンテキストに属します。
2. `.demo-modal`は`position: fixed;`であり、**新しいスタッキングコンテキストを生成し、かつビューポートを基準に配置されます**。`position: fixed`の要素は、`z-index`が`auto`でも常に新しいスタッキングコンテキストを生成し、その`z-index`の値(ここでは`1000`)はルートのスタッキングコンテキスト(`body`)に対して有効になります。
3. `#sub`内の`.sub-in`も`position: relative;`ですが、`z-index: auto`であるため、**新しいスタッキングコンテキストを生成しません**。`#sub`(`position: static;` `z-index: auto;`)も新しいスタッキングコンテキストを生成しないため、`.sub-in`も親`div`のスタッキングコンテキストに属します。
結果として、`position: fixed;`である`.demo-modal`は、その高い`z-index: 1000;`によって**他のほとんどの通常フロー内の要素や、`position: relative;`で`z-index: auto;`の要素よりも常に前面に描画される**という特性が発揮されます。`position: fixed`はビューポートに対して固定されるため、親の`div`のスタッキングコンテキストに影響されにくく、かつ最も高い`z-index`を持つことで「サブウインドウの中身」を覆い隠すことができるようになったのです。
---
つまり、以前のコードでは`#main`と`.sub-in`がそれぞれ独自のスタッキングコンテキストを持っていたため、`demo-modal`の`z-index`が`sub-in`に適用されなかったのに対し、今回のコードでは`demo-modal`が**`position: fixed`によって独立したスタッキングコンテキストを生成し、かつ他の要素のスタッキングコンテキストの制限を受けずに高い`z-index`で最前面に表示される**ようになったため、結果として「隠れる」ようになったということです。
.mainのz-indexが0になっているのには理由があると思うのだが、autoや他の数字で良いのなら、ユーザー側で対処できるはず。どうなんだろう?
2023年11月28日 18:16の #Cocoon での質問。
"添付した画像の通り、プラグインが生成した要素と、サイドバーが重なるときにサイドバーが上に来てしまいます。
※プラグインが生成した要素は通常、スクロールに追従しませんが、positon: fixed;で追従するようにしています。
z-indexで、プラグインが生成した要素を最前面にしようとしたのですが、うまくいきません。
この場合、どういったことをすればプラグインが生成した要素は、サイドバーに隠れることなく前面に表示できるのですか?
ご教示いただけると幸いです。
"
"#main {
z-index: 1;
}
#sidebar {
z-index: 0;
}
"
要素の重なり順について、プラグインが生成した要素と、サイドバーが重なるときにサイドバーが上に来てしまう【wpForo Ads Manager】 | CSSカスタマイズ相談 | Cocoon フォーラム
https://wp-cocoon.com/community/customs/%E8%A6%81%E7%B4%A0%E3%81%AE%E9%87%8D%E3%81%AA%E3%82%8A%E9%A0%86%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/
追加CSSに次のコードを追加した。
/*モーダルウインドウがサイドバーの上面に表示されるようにする*/
.main{z-index:auto;}
/*モーダルウインドウがサイドバーの上面に表示されるようにする*/
/*フォローウインドウの「目次」を非表示にする*/
.activitypub-modal__header .toc{display:none;}
/*フォローウインドウの「目次」を非表示にする*/
こんな感じでユーザーが工夫しなければいけないのって、良くないよね。
#Gemini に尋ねたら、.main{z-index:auto;}は良くないということで、次のような提案をされた。これはプラグインの作者が行うこと。
1. モーダルウィンドウを<body>直下に配置する(推奨)
多くのモダンなモーダルウィンドウライブラリや実装が採用している方法です。
モーダルウィンドウのHTML要素を、<body>タグの直下に配置します。これにより、モーダルウィンドウはどのメインコンテンツやサイドバーの積層コンテキストからも独立した、最も基本的な積層コンテキスト内で管理されます。
この状態でモーダルウィンドウのコンテナにposition: fixed;(画面全体に固定表示する場合)またはposition: absolute;(特定の親要素内で固定表示する場合)を設定し、非常に高いz-index(例: 9999以上)を設定すれば、サイドバーを含め、他の全てのコンテンツの上に表示されるようになります。
サンプルコード。
追加CSSに追加した次のコードを削除した。
プラグイン #ActivityPub のアップデートで改善されることを願う。
"親要素のz-index値に依存するというのは、親要素同士のz-index値の序列を子要素が超えることはできないということです。
"
迷わない戸惑わないためのz-indexの考え方|muro
https://note.com/suznary/n/n48c202be64d0#328327d0-aaa5-4a5a-a0a1-cf2900f3ee04