Olá, tags summary e figcaption

Vimos, há algum tempo, o surgimento não de um, mas
de duas tags no HTML5↳HTML45 conteúdosA importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Como hostear seu site HTML gratuitamente com GitHub PagesDev (Back & Front) · jun 2025SQL Server – Como criar um versionamento de código das suas Stored Procedures em HTML e com comentários da alteraçãoData · nov 2020Ver tudo em Dev (Back & Front) →.

A tag summary (não o atributo summary no elemento
table) que vai dentro do elemento details:

<details>
<summary>More information</summary>
<p>Here is the source data that is discussed in the article ... </p>
</details>

Isso
é feito para produzir uma box “expando” que é fechada por padrão (mas pode ser
aberta por padrão usando o atributo boolean open), exibindo somente o texto
especificado pelo summary como controle. Ao ser ativado, o controle abre todos os
detalhes do elemento; reativar o fecha novamente. Se não houver tag summary, o navegador exibirá o conteúdo que existe dentro de details normalmente. Em browsers que suportam details, esse comportamento não depende
do script do autor, e deve funcionar mesmo se o JavaScript estiver desabilitado ou não estiver presente.

O figcaption deve ser localizado dentro da tag figure:

<figure>
<img ... > (or video, table etc)
<figcaption>A rabid unicorn goring a fairy.</figcaption>
</figure>

Se
você estiver interessado em um pouco de história, continue lendo. Caso
contrário, bye bye!

Antigamente,
o elemento legend era especificado para fazer o trabalho de ambos.
Infelizmente,
cada browser tinha
problemas de análise ao reutilizá-lo fora dos
formulários. Problemas parecidos foram encontrados na tentativa de reutilizar
o elemento caption fora de tabelas. Por sugestão de Jeremy Keith, o spec
reutilizou dd e dt, mas isso  quebra também.

Agora,
dois novos elementos são cunhados (Eu realmente gostei de um novo elemento –
rubric para ambos, mas é uma palavra bastante esotérica).

Uma
das objeções aos detalhes, como descrito por Shelley Powers, “é o uso do de Javascript para mostrar e esconder pedaços de conteúdo é uma prática bem comum em aplicações web. Mais importante,
seguindo o conceito de melhorias progressivas, as ações de mostrar e
esconder conteúdo não funcionariam se o JavaScript estivesse
desabilitado e todo o conteúdo estaria visível por padrão. Ter
uma seção que é dinâmica, mas não é controlada por script irá gerar confusão,
particularmente entre pessoas que desligam o script e acreditam que não existem
seções “expando” na página web.Na
verdade, eu não vejo como esse elemento irá simplificar o desenvolvimento de
aplicações web. Esse tipo de funcionalidade é trivial com o JS.”

Meu
contra-argumento é que uma área expanding/collapsing na página é uma
necessidade bastante comum. Eu já vi sites buscarem uma biblioteca inteira de
JavaScript somente para conseguirem isso (presumindo que o desenvolvedor não
fosse familiarizado com JS), o que “incha” o tamanho da página para o usuário.
Já vi páginas em que as informações de “detalhes” são configuradas para
display:none por padrão, e o usuário não
consegue expandir a informação sem JS, tornando assim o conteúdo inacessível se
o JS não estiver presente.

Reativar
esse elemento seria vantajoso para desenvolvedores que não precisariam aprender
JS para completar uma tarefa comum; seria vantajoso para usuários que ganhariam um bônus em acessibilidade↳Acessibilidade11 conteúdosO que é Acessibilidade Web e como tornar seu site mais acessívelDev (Back & Front) · mar 2019Design para veteranos digitais: acessibilidade para nós mesmosProduto & UX · jan 2020Dicas de Front-End para usabilidade, acessibilidade, performance e responsividadeProduto & UX · fev 2025Ver tudo em Produto & UX → tendo esse comportamento nativamente em seu
browser.

Enquanto
acredito que existe uma lógica irrefutável em meu argumento, juntamente com os
floreios retóricos e minha capacidade de arrancar lágrimas com a minha prosa que
capturaram o coração e a mente do editor, suspeito que o que o persuadiu
foi Maciej Stachowiak da Apple dizendo
que “a comunidade webkit” estava interessada em implementar detalhes, uma vez
que o spec estivesse redondo. A implementação ganhou o dia.

 ?

Texto original disponível em http://html5doctor.com/summary-figcaption-element/