Mucha charla alrededor del viejo <details>
y <summary>
elementos últimamente! Yo vi Lea Verou tuiteó recientemente una observación sobre el elemento display
comportamiento y eso se dividió en más observaciones y notas de uso de la gente, incluido un debate revivido de si <summary>
se debe permitir que contenga elementos interactivos o no.
Hay muchos puntos para conectar y haré todo lo posible aquí para hacer exactamente eso.
<details>
¿elemento?
¿Podemos cambiar la visualización de los elementos anidados en el ¡Súper raro! Si abrimos DevTools, la hoja de estilo del agente de usuario nos dice <details>
se muestra como un elemento de bloque.
Note el requerido <summary>
elemento y los dos adicionales <div>
está ahí. Podemos anular la display
, ¿derecho?
Lo que podríamos esperar es que <details>
ahora tiene una altura explícita de 40vh
y tres filas donde la tercera fila ocupa el espacio sobrante de las dos primeras. Como esto:
Uf, pero la tercera fila no... hace... eso.
Aparentemente, lo que estamos tratando es un contenedor de cuadrícula que no puede aplicar el comportamiento de cuadrícula a sus elementos de cuadrícula. Pero la especificación HTML nos dice:
La
details
elemento es se espera que se represente como un caja de bloque. También se espera que el elemento tenga un interior árbol de sombra con dos ranuras.(El énfasis es mío)
Y un poco más tarde:
La
details
segundo del elemento espacio se espera que tenga sustyle
atributo establecido en “display: block; content-visibility: hidden;
" cuando eldetails
elemento no tiene unopen
atributo. cuando tiene laopen
atributo, elstyle
se espera que el atributo se elimine del segundo espacio.(Énfasis mío, otra vez)
Entonces, la especificación dice que la segunda ranura, las dos adicionales <div>
s del ejemplo, solo son obligados a ser elementos de bloque cuando <details>
está cerrado. Cuando está abierto - <details open>
- deben ajustarse a la visualización de la cuadrícula que anula el estilo del agente de usuario... ¿verdad?
Ese es el debate. Lo entiendo slots
se ponen a display: contents
por defecto, pero atascar elementos anidados en las ranuras y eliminar la capacidad de aplicarles estilo no parece correcto. ¿Es un problema de especificaciones que los contenidos son ranuras o un problema del navegador que no podemos anular su display
aunque estén en el boj? Las personas más inteligentes pueden iluminarme, pero parece una implementación incorrecta.
<details>
¿un contenedor o un elemento interactivo?
Is mucha gente es usando <details>
para alternar menús abierto y cerrado. es una práctica popularizado por GitHub.
Parece razonable. La especificación seguro lo permite:
La
details
elementos representa un widget de divulgación desde el que el usuario puede obtener información adicional o controles.(El énfasis es mío)
Muy bien, entonces podríamos esperar que <details>
es el contenedor (tiene un implícitamente role=group
) y <summary>
es un elemento interactivo que configura el contenedor open
estado. Tiene sentido desde <summary>
tiene un implícito button
papel en algunos contextos (pero sin el papel correspondiente de WAI-ARIA).
Pero Melanie Sumner investigó un poco que no sólo parece contradecir eso, sino que lleva a la conclusión de que usar <details>
como menú probablemente no sea lo mejor. Mira lo que sucede cuando <details>
se presenta sin el <summary>
elemento:
Hace exactamente lo que sugiere la especificación cuando falta un <summary>
- hace su propia:
El Primer
summary
elemento hijo del elemento, si alguno, representa el resumen o leyenda de los detalles. si no hay niñosummary
elemento, el agente de usuario debe proporcionar su propia leyenda (por ejemplo, "Detalles").(El énfasis es mío)
Melanie ejecutó eso a través de un validador de HTML y, ¡sorpresa! — no es válido:
¿Entonces <details>
requiere el <summary>
. Y cuando <summary>
Está perdido, <details>
crea el suyo propio, aunque se transmite como marcado no válido. Todo es miel sobre hojuelas y es válido cuando <summary>
esta ahí:
Todo lo cual lleva a una nueva pregunta: por que es <summary>
dado un implícito button
papel cuando <details>
es lo que parece ser el elemento interactivo? ¿Quizás este es otro caso en el que la implementación del navegador es incorrecta? Por otra parte, la especificación clasifica a ambos como elementos interactivos. Puedes ver lo completamente confuso que se vuelve todo esto.
De cualquier manera, la conclusión final de Melanie de que debemos evitar usar <details>
para los menús se basa en cómo la tecnología de asistencia lee y anuncia <details>
que contienen elementos interactivos. El elemento se anuncia, pero no se mencionan los controles interactivos más allá de eso hasta que usted, er, interactuar <details>
. Solo entonces se anunciará algo así como una lista de enlaces.
Además, el contenido dentro de un colapsado <details>
está excluido de la búsqueda en la página (excepto en los navegadores Chromium, que pueden acceder al contenido colapsado en el momento de la escritura), lo que hace que las cosas sean aún más difíciles de encontrar.
<summary>
permitir elementos interactivos?
Debería Esa es la pregunta planteada en este hilo abierto. La idea es que algo como esto no sería válido:
<details>
<summary><a href="...">Link element</a></summary>
</details>
<!-- or -->
<details>
<summary><input></summary>
</details>
Scott O'Hara resume muy bien por qué esto es un problema:
El enlace no es detectable en absoluto por JAWS cuando se navega con su cursor virtual. Si navega al elemento de resumen a través de la tecla Tabulador, JAWS anuncia "texto de ejemplo, botón" como nombre y función del elemento. Si vuelve a pulsar la tecla Tabulador, JAWS anuncia de nuevo "texto de ejemplo, botón" aunque el foco del teclado esté en el enlace.
[...]
Hay más sobre los que podría continuar con los diversos problemas que diferentes AT tienen con el modelo de contenido para resumir... pero eso solo extendería este comentario más allá de lo necesario. tldr; el modelo de contenido resumido produce experiencias muy inconsistentes y, a veces, simplemente incompletas para las personas que usan AT.
Scott abrió tickets para corregir este comportamiento en Cromo y WebKit. ¡Gracias, Scott!
Sin embargo, es HTML válido:
Scott va más allá en un entrada en el blog independiente. Por ejemplo, explica cómo abofetear role=button
on <summary>
puede parecer una solución razonable para garantizar que la tecnología de asistencia lo anuncie constantemente. Eso también resolvería el debate sobre si <summary>
debería permitir elementos interactivos porque los botones no pueden contener elementos interactivos. El único problema es que Safari luego trata <summary>
como un botón estándar, que pierde su expanded
y collapsed
estados Entonces, se anuncia el rol correcto, pero ahora no su estado. 🙃
Adónde vamos ahora?
¿Tienes miedo de usar <details>
/<summary>
con todos estos problemas e inconsistencias? Seguro que sí, pero solo en la medida en que se asegure de que lo que contiene proporcione el tipo correcto de experiencia y expectativas para los usuarios.
Me alegro de que estas conversaciones estén ocurriendo y de que se estén llevando a cabo al aire libre. Por eso, puede comentar las tres soluciones propuestas por Scott sobre cómo el modelo de contenido para <summary>
está definido, vote a favor de sus tickets e informe sus propios problemas y casos de uso mientras lo hace. Con suerte, cuanto mejor comprendamos cómo se utilizan los elementos y qué esperamos que hagan, mejor se implementarán.