Mucha charla alrededor del viejo
y
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
se debe permitir que contenga elementos interactivos o no.
Hay muchos puntos para conectar y haré todo lo posible aquí para hacer exactamente eso.
¿elemento?
¡Súper raro! Si abrimos DevTools, la hoja de estilo del agente de usuario nos dice
se muestra como un elemento de bloque.
Note el requerido
elemento y los dos adicionales
está ahí. Podemos anular la
display
, ¿derecho?
Lo que podríamos esperar es que
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:
El
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:
El
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
s del ejemplo, solo son obligados a ser elementos de bloque cuando
está cerrado. Cuando está abierto -
- 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.
¿un contenedor o un elemento interactivo?
mucha gente es usando
para alternar menús abierto y cerrado. es una práctica popularizado por GitHub.
Parece razonable. La especificación seguro lo permite:
El
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
es el contenedor (tiene un implícitamente
role=group
) y
es un elemento interactivo que configura el contenedor
open
estado. Tiene sentido desde
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
como menú probablemente no sea lo mejor. Mira lo que sucede cuando
se presenta sin el
elemento:
Hace exactamente lo que sugiere la especificación cuando falta un
- 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
requiere el
. Y cuando
Está perdido,
crea el suyo propio, aunque se transmite como marcado no válido. Todo es miel sobre hojuelas y es válido cuando
esta ahí:
Todo lo cual lleva a una nueva pregunta: por que es
dado un implícito
button
papel cuando
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
para los menús se basa en cómo la tecnología de asistencia lee y anuncia
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
. Solo entonces se anunciará algo así como una lista de enlaces.
Además, el contenido dentro de un colapsado
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.
permitir elementos interactivos?
Esa es la pregunta planteada en este hilo abierto. La idea es que algo como esto no sería válido:
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
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
debería permitir elementos interactivos porque los botones no pueden contener elementos interactivos. El único problema es que Safari luego trata
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
/
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
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.