Muita conversa em torno do velho <details> e <summary> elementos ultimamente! Eu vi Lea Verou tweetou recentemente uma observação sobre o elemento display comportamento e isso meio que se dividiu em mais observações e notas de uso de pessoas, incluindo um discussão revivida em se <summary> deve poder conter elementos interativos ou não.
Há muitos pontos para conectar e farei o meu melhor aqui para fazer exatamente isso.
Podemos alterar a exibição dos elementos aninhados no <details> elemento?
Muito estranho! Se abrirmos o DevTools, a folha de estilo do agente do usuário nos informará <details> é exibido como um elemento de bloco.
Observe o necessário <summary> elemento e os dois adicionais <div>está aí. Podemos substituir o display, certo?
O que poderíamos esperar é que <details> agora tem uma altura explícita de 40vh e três linhas onde a terceira linha ocupa o espaço restante das duas primeiras. Assim:
Ugh, mas a terceira linha não… faz… isso.
Aparentemente, estamos lidando com um contêiner de grade que não consegue aplicar o comportamento de grade aos seus itens de grade. Mas a especificação HTML nos diz:
A
detailselemento é espera-se que seja renderizado como um caixa de bloco. Espera-se também que o elemento tenha um árvore da sombra com dois caça-níqueis.(Ênfase minha)
E um pouco mais tarde:
A
detailssegundo do elemento ranhura espera-se que tenha o seustyleatributo definido como “display: block; content-visibility: hidden;" quando odetailselemento não possuiopenatributo. Quando tiver oopenatributo, ostyleespera-se que o atributo seja removido do segundo ranhura.(ênfase minha, novamente)
Então, a especificação diz o segundo slot – os dois adicionais <div>s do exemplo - só são coagidos a serem elementos de bloco quando <details> está fechado. Quando está aberto - <details open> - eles devem estar em conformidade com a exibição da grade que substitui o estilo do agente do usuário... certo?
Esse é o debate. entendi slots estão definidos para display: contents por padrão, mas inserir elementos aninhados em slots e remover a capacidade de estilizá-los parece errado. É um problema de especificação que o conteúdo seja slots ou um problema do navegador que não podemos substituir seu display mesmo estando no buxo? Pessoas mais inteligentes podem me esclarecer, mas parece uma implementação incorreta.
Is <details> um contêiner ou um elemento interativo?
Muitas pessoas estão utilização <details> para alternar menus aberto e fechado. É uma prática popularizado pelo GitHub.
Parece razoável. A especificação certamente permite:
A
detailselemento representa um widget de divulgação a partir do qual o usuário pode obter informações adicionais ou controles.(Ênfase minha)
Tudo bem, então podemos esperar que <details> é o contêiner (ele tem um implicitamente role=group) e <summary> é um elemento interativo que define o contêiner open estado. Faz sentido desde <summary> tem um implícito button papel em alguns contextos (mas nenhuma função WAI-ARIA correspondente).
BUT Melanie Sumner fez algumas pesquisas isso não apenas parece contradizer isso, mas leva à conclusão de que o uso <details> como menu provavelmente não é a melhor coisa. Veja o que acontece quando <details> é renderizado sem o <summary> elemento:
Ele faz exatamente o que a especificação sugere quando falta um <summary> - faz o seu próprio:
O primeiro
summaryelemento filho do elemento, caso existam, representa o resumo ou legenda dos detalhes. Se não houver criançasummaryelemento, o agente do usuário deve fornecer sua própria legenda (por exemplo, “Detalhes”).(Ênfase minha)
Melanie executou isso através de um validador HTML e – surpresa! - é inválido:
então, <details> requer o <summary>. E quando <summary> está desaparecido, <details> cria o seu próprio, embora seja retransmitido como marcação inválida. É tudo ótimo e válido quando <summary> existe:
Tudo isso leva a uma nova questão: porque é <summary> dado um implícito button papel quando <details> é o que parece ser o elemento interativo? Talvez este seja outro caso em que a implementação do navegador está incorreta? Então, novamente, a especificação categoriza ambos como elementos interativos. Você pode ver como tudo isso se torna totalmente confuso.
De qualquer forma, a conclusão final de Melanie de que deveríamos evitar o uso <details> para menus é baseado em como a tecnologia assistiva lê e anuncia <details> que contêm elementos interativos. O elemento é anunciado, mas não há menção a controles interativos além disso até que você, er, interagir de <details>. Só então será anunciada algo como uma lista de links.
Além disso, o conteúdo dentro de um arquivo recolhido <details> é excluído da pesquisa na página (exceto nos navegadores Chromium, que podem acessar o conteúdo recolhido no momento da escrita), tornando as coisas ainda mais difíceis de encontrar.
Deveria <summary> permitir elementos interativos?
Essa é a questão colocada em esse tópico aberto. A ideia é que algo assim seria inválido:
<details>
<summary><a href="...">Link element</a></summary>
</details>
<!-- or -->
<details>
<summary><input></summary>
</details>Scott O'Hara resume bem por que isso é um problema:
O link não pode ser descoberto pelo JAWS ao navegar com seu cursor virtual. Se navegar para o elemento de resumo através da tecla Tab, o JAWS anuncia “texto de exemplo, botão” como o nome e a função do elemento. Se pressionar a tecla Tab novamente, o JAWS anuncia novamente “texto de exemplo, botão” mesmo que o foco do teclado esteja no link.
[...]
Há mais coisas que eu poderia falar sobre os vários problemas que diferentes AT têm com o modelo de conteúdo para resumo… mas isso apenas estenderia este comentário além do necessário. tldr; o modelo de conteúdo resumido produz experiências muito inconsistentes e, às vezes, totalmente interrompidas para pessoas que usam TA.
Scott abriu tickets para corrigir esse comportamento em crômio e WebKit. Obrigado, Scott!
No entanto, é HTML válido:
Scott vai mais longe em um postagem separada do blog. Por exemplo, ele explica como dar um tapa role=button on <summary> pode parecer uma solução razoável para garantir que seja anunciado de forma consistente pela tecnologia assistiva. Isso também resolveria o debate sobre se <summary> deve permitir elementos interativos porque botões não podem conter elementos interativos. O único problema é que o Safari trata <summary> como um botão padrão, que perde sua expanded e collapsed estados. Assim, o papel correto é anunciado, mas agora o seu estado não. 🙃
Para onde vamos agora?
Você está com medo de usar <details>/<summary> com todos esses problemas e inconsistências? Claro que estou, mas apenas na medida em que garanto que o que está nele fornece o tipo certo de experiência e expectativas para os usuários.
Estou feliz que essas conversas estejam acontecendo e que estejam acontecendo abertamente. Por causa disso, você pode comentar as três soluções propostas por Scott sobre como o modelo de conteúdo para <summary> está definido, vote positivamente em seus tickets e relate seus próprios problemas e casos de uso enquanto estiver fazendo isso. Esperamos que quanto melhor compreendermos como os elementos são usados e o que esperamos que façam, melhor serão implementados.
