Tema: html
-
Imagens responsivas com srcset, sizes e picture
O srcset com descritores de largura, combinado com o atributo sizes, permite ao navegador escolher o menor arquivo de imagem que preenche o espaço disponível na viewport e na densidade de pixels atuais. Os descritores x servem imagens de tamanho fixo em várias densidades, e o picture com elementos source cobre direção de arte e fallback de formato. Mantenha sempre width e height para que o layout não se desloque durante o carregamento da imagem.
-
Validação nativa de formulários em HTML: required, pattern, type e a Constraint Validation API
O HTML valida os controles de um formulário antes do envio, sem script: required, minlength, min/max, pattern e inputs tipados definem restrições, o navegador bloqueia o envio e mostra uma mensagem, o CSS pode estilizar :user-invalid e a Constraint Validation API expõe o mesmo estado a scripts. É uma camada de usabilidade, não de segurança; o servidor valida de novo.
-
Web components: custom elements, shadow DOM e onde termina o encapsulamento
Custom elements registram uma classe sob um nome de tag com hífen e callbacks de ciclo de vida; o shadow DOM lhe dá uma subárvore isolada, cujos estilos não vazam em nenhuma direção; templates e shadow roots declarativos fornecem a marcação. Tudo o que atravessa a fronteira, de estilização (com parts e custom properties) a participação em formulários via ElementInternals e associação de labels, precisa ser aberto de forma deliberada.
-
Formulários com restrições HTML nativas geram menos rejeições de validação no servidor por envio do que formulários validados apenas com JavaScript personalizado
Hipótese: o navegador bloqueia o envio interativo de um formulário cujas restrições nativas (required, pattern, type, min e max) falham, embora a MDN note que chamar submit() contorna isso e novalidate o desativa. A proposta é que formulários com restrições nativas que espelham as regras do servidor chegam a ele com menos rejeições por envio do que formulários cujas verificações estão só em scripts personalizados, porque as verificações nativas continuam a funcionar quando o script não carrega ou dá erro; propõe-se um teste A/B, sem alegar resultado.
-
Favicons e web app manifest: quais arquivos publicar e como declará-los
Sem um link rel=icon declarado, os navegadores recorrem a /favicon.ico, então mantenha esse arquivo no lugar. Declare um SVG escalável ou um PNG com tamanho definido via link rel=icon, um apple-touch-icon e um manifest cujos ícones tenham sizes e purpose (any, maskable, monochrome). Os mecanismos de busca querem um favicon quadrado e estável por hostname.
-
Formulários acessíveis: rótulos, mensagens de erro e autocomplete
Associe cada controle a um rótulo por meio de for e id, indique os campos obrigatórios no texto e com o atributo, use tokens autocomplete para que navegadores e tecnologias assistivas conheçam a finalidade do campo e informe os erros num resumo e em mensagens por campo ligadas com aria-describedby.
-
dialog versus popover: comportamento modal, top layer e light dismiss
dialog com showModal() é modal: top layer, página inerte, ::backdrop, Escape, closedby e form method=dialog; o atributo popover transforma qualquer elemento numa sobreposição não modal na top layer, alternada por um botão sem script e fechada por light dismiss no estado auto. Use dialog para avisos bloqueantes e formulários, popover para menus, tooltips e toasts.
-
Papéis ARIA: por que um elemento HTML nativo é melhor que uma div com role
A primeira regra de uso de ARIA do W3C é preferir um elemento ou atributo HTML nativo que já tenha a semântica e o comportamento necessários; ARIA só muda o que é informado às tecnologias assistivas, nunca o que o elemento faz. Uma div com role=button ainda precisa de foco, tratamento de teclado e estados implementados manualmente, e qualquer erro passa despercebido em testes visuais.
-
Gerenciamento de foco em interações de página única: diálogos, mudanças de rota e elementos removidos
Quando a página muda sem um carregamento completo, o foco do teclado precisa ser movido de propósito: para dentro do diálogo ao abri-lo e de volta ao seu acionador ao fechá-lo, para o título da nova visualização após uma mudança de rota no cliente e para um elemento vizinho adequado quando o elemento focado é excluído. Caso contrário, o foco cai no body do documento e os usuários de leitores de tela voltam ao topo da página.
-
Acessibilidade: os quatro princípios das WCAG aplicados na prática
As WCAG 2.2 organizam todos os critérios de sucesso em quatro princípios: perceptível, operável, compreensível e robusto. Conhecendo as violações mais comuns de cada princípio (falta de alternativas em texto, armadilhas de teclado, contraste insuficiente, campos sem rótulo, alvos pequenos demais), é possível encontrar muitas barreiras sem ferramentas especiais; o nível AA é o objetivo habitual.
-
details e summary: widgets de divulgação nativos, acordeões exclusivos e hidden=until-found
details/summary é um widget de divulgação sem script: o atributo open exibe o conteúdo, um atributo name compartilhado torna o grupo exclusivo (abrir um fecha os outros), o evento toggle informa as mudanças e o summary tem estilo display: list-item. Para conteúdo recolhido que precisa continuar pesquisável, hidden=until-found o revela na busca da página ou na navegação por fragmento.
-
Entrega de imagens: AVIF e WebP com fallbacks, lazy loading e prioridade de busca
Sirva formatos modernos por meio de elementos source em picture com o atributo type e uma img em JPEG ou PNG como fallback (ou negocie via Accept com Vary). Aplique lazy loading apenas a imagens abaixo da primeira viewport, com width e height definidos, e marque a maior imagem acima da dobra com fetchpriority=high em vez de lazy.
Legível por máquina: JSON