オールの周りでたくさんのおしゃべり <details> および <summary> 最近の要素！ 私が見た Lea Verou は最近、観察をツイートしました エレメントについて display 行動とそれは、人々からのより多くの観察と使用上のメモに分割されました。 議論の復活 かどうかに <summary> インタラクティブな要素を含めるかどうかを許可する必要があります。
接続する点はたくさんありますが、ここでまさにそれを行うために最善を尽くします。
ネストされた要素の表示を変更できますか <details> 素子？
超変！ DevTools を開くと、ユーザー エージェント スタイルシートが教えてくれます <details> ブロック要素として表示されます。
必要なことに注意してください <summary> 要素と XNUMX つの追加要素 <div>そこにいる。 オーバーライドできます display、 右？
私たちが期待できることは、 <details> の明示的な高さを持つようになりました 40vh XNUMX 行目は、最初の XNUMX 行の残りのスペースを XNUMX 行目で占有します。 このような：
うーん、でも XNUMX 列目は… そう… そうじゃない。
どうやら、私たちが扱っているのは、グリッド アイテムにグリッド動作を適用できないグリッド コンテナーです。 しかし、HTML 仕様では次のように説明されています。
details要素は としてレンダリングされると予想される ブロックボックス. 要素には内部要素もあると予想されます 影の木 二人で スロット.（強調鉱山）
そして少し後で：
details要素の秒 スロット が期待されるstyleに設定された属性display: block; content-visibility: hidden;」のときdetails要素にはありませんopen属性。 それが持っているときopen属性、style属性は XNUMX 番目から削除される予定です スロット.(再び私のものを強調)
そのため、仕様には XNUMX 番目のスロットと記載されています — 追加の XNUMX つのスロット <div>例の s — ブロック要素になるように強制されるのは、 <details> 閉じています。 開いているとき— <details open> — それらは、ユーザー エージェントのスタイル設定をオーバーライドするグリッド表示に準拠する必要があります…そうですか?
それが議論です。 わかりました slots に設定されている display: contents 初期設定で、しかし、ネストされた要素をスロットに詰め込み、それらをスタイルする機能を削除することはオフのようです. コンテンツがスロットであることは仕様の問題ですか、それともブラウザの問題で上書きできませんか display ボックスツリーにあるのに？ 賢い人は私を啓発することができますが、それは間違った実装のようです.
Is <details> コンテナまたはインタラクティブな要素？
多くの人は <details> メニューを切り替える オープンとクローズ。 練習です GitHub によって普及.
合理的なようです。 仕様は確かにそれを許可します:
details素子 表し ユーザーが追加情報を取得できる公開ウィジェット またはコントロール.（強調鉱山）
よし、だから我々はそれを期待するかもしれません <details> はコンテナです（ 暗黙 role=group）と <summary> コンテナの open 州。 理にかなっています <summary> 暗示があります button 役割 一部のコンテキストでは (ただし、対応する WAI-ARIA ロールはありません)。
だけど メラニー・サムナーは掘り下げました それはそれと矛盾しているように見えるだけでなく、 <details> メニューとしてはおそらく最高のものではありません。 いつ何が起こるか見てください <details> なしでレンダリングされます <summary> 素子：
不足しているときに仕様が示唆することを正確に行います <summary> —それはそれ自身を作ります：
最初の
summary要素の子要素、 もしあれば, 表し 詳細の要約または凡例。 子供がいない場合summary要素の場合、ユーザー エージェントは独自の凡例 (「詳細」など) を提供する必要があります。（強調鉱山）
Melanie はそれを HTML バリデーターで実行しました。 — 無効です:
そう、 <details> が必要です <summary>。 そしていつ <summary> 不足している、 <details> 無効なマークアップとして中継されますが、独自に作成します。 それはすべてハンキードーリーであり、いつでも有効です <summary> ある：
これらはすべて、新しい質問につながります。 どうして <summary> 暗黙のうちに与えられた button ときの役割 <details> インタラクティブな要素と思われるものは何ですか? おそらく、これはブラウザーの実装が正しくない別のケースでしょうか? 繰り返しますが、仕様は両方を次のように分類します インタラクティブな要素. これらすべてがいかに混乱を招くかがわかります。
いずれにせよ、使用を避けるべきであるというメラニーの最終的な結論は、 <details> メニューの場合は、支援技術がどのように読み上げ、アナウンスするかに基づいています <details> インタラクティブな要素が含まれています。 要素は発表されていますが、それ以上のインタラクティブなコントロールについては言及されていません。 対話 <details>. そうして初めて、リンクのリストのようなものが発表されます。
また、折りたたまれた <details> ページ内検索から除外されているため (執筆時点で折りたたまれたコンテンツにアクセスできる Chromium ブラウザーを除く)、検索がさらに難しくなっています。
すべき <summary> インタラクティブな要素を許可しますか?
それが提起された質問です このオープンスレッド. アイデアは、次のようなものは無効になるということです:
<details>
<summary><a href="...">Link element</a></summary>
</details>
<!-- or -->
<details>
<summary><input></summary>
</details>スコットオハラ うまくまとめます なぜこれが問題なのか:
仮想カーソルを使用してナビゲートする場合、リンクは JAWS に対してまったく検出できません。 Tab キーを使用して概要要素に移動すると、JAWS は要素の名前と役割として「サンプル テキスト、ボタン」をアナウンスします。 Tab キーをもう一度押すと、キーボード フォーカスがリンクにある場合でも、JAWS は再び「サンプル テキスト、ボタン」と読み上げます。
[...]
要約のために、さまざまな AT がコンテンツ モデルで抱えているさまざまな問題について、さらに詳しく説明できます。 tldr; 要約コンテンツ モデルは非常に一貫性がなく、AT を使用しているユーザーのエクスペリエンスが完全に崩れてしまうこともあります。
Scott は、この動作を修正するためにチケットをオープンしました。 クロム および WebKitの. ありがとう、スコット！
それでも、有効な HTML です。
スコットはさらに 別のブログ記事. たとえば、彼はどのように平手打ちをするかを説明します。 role=button on <summary> 支援技術によって一貫して発表されるようにするための合理的な修正のように思えるかもしれません。 それはまた、 <summary> インタラクティブな要素を許可する必要があるため ボタンにインタラクティブな要素を含めることはできません. 唯一の問題は、Safariがそれを処理することです <summary> を失う標準ボタンとして expanded および collapsed 州。 そのため、正しい役割が発表されていますが、現在その状態は発表されていません。 🙃
今どこに行きますか？
使うのが怖い？ <details>/<summary> これらの問題と矛盾のすべてで？ 確かにそうですが、その内容がユーザーに適切な種類のエクスペリエンスと期待を提供することを確認する場合に限ります.
これらの会話が行われていて、オープンに行われていることをうれしく思います. そのため、Scott が提案した XNUMX つの解決策についてコメントすることができます。 <summary> が定義されている場合は、彼のチケットに賛成票を投じ、自分の問題と使用例を報告してください。 うまくいけば、要素がどのように使用され、何を期待するかを理解すればするほど、要素がより適切に実装されます。
