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.

¿Podemos cambiar la visualización de los elementos anidados en el

¿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:

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 su style atributo establecido en “display: block; content-visibility: hidden;" cuando el details elemento no tiene un open atributo. cuando tiene la open atributo, el style 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.

Is

¿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:

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

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ño summary 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

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.

Debería

permitir elementos interactivos?

Esa es la pregunta planteada en este hilo abierto. La idea es que algo como esto no sería válido:

  
Link element





  

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.