<picture>. Depois disso, discorra sobre o seu funcionamento e intuito:Bloco de revisão:
<picture>
<source media="(min-width: 1024px)" srcset="desktop-image.jpg">
<img alt="Imagem de teste" src="mobile-image.jpg">
</picture>
O funcionamento da tag <picture> é simples: caso a condição de tela em source não seja atendida, a imagem definida no src da tag de imagem será renderizada. Caso seja atendida, a imagem definida em srcset do source que será.
Isso traz diversos benefícios, como evitar gambiarras utilizando display: none; para esconder elementos, duas imagens sendo renderizadas ao mesmo tempo, dois atributos alt diferentes sendo necessários.
aria-label e construa um exemplo de uso:Bloco de código:
<button aria-label="Button function description"><img></button>
O atributo aria-label é utilizado para adicionar uma descrição a elementos que não possuem conteúdo textual visível. Isso permite que tecnologias assistivas, como leitores de tela, consigam compreender o propósito e a função daquele elemento.
scroll-behavior quando utilizada com o valor smooth:Essa propriedade faz com que elementos com scroll interno ou redirecionamentos via âncoras (Ex.: #secao) tenham suas transições de movimentação mais suaves.
O navegador aplicará todas as media queries. Se regras conflitarem, vale a última declarada. Breakpoints mais complexos devem ser posicionados por último no arquivo responsive.css.
Bloco de Código:
const adviceIdEl = document.getElementById("adviceId")
const adviceDescriptionEl = document.getElementById("adviceDescription")
const actionButtonEl = document.getElementById("actionButton")
async function getAdvice() {
const response = await fetch('<https://api.adviceslip.com/advice>')
return response.json()
}
async function onGenerateAdvice() {
try {
const advice = await getAdvice()
adviceIdEl.innerText = `ADVICE #${advice.slip.id}`
adviceDescriptionEl.innerText = advice.slip.advice
} catch (error) {
adviceDescriptionEl.innerText = "Unable to fetch advice. Try again."
console.error(error)
}
}
actionButtonEl.addEventListener("click", onGenerateAdvice)
Valores que se repetem
Trecho de código:
const adviceIdEl = document.getElementById("adviceId")
const adviceDescriptionEl = document.getElementById("adviceDescription")
Mais tarde na lógica JS, essa busca por elementos HTML foram colocadas numa função. Caso eu não as tivesse atribuído a uma constante, essa busca, ao invés de ser chamada uma única vez no fluxo global, seria chamada a cada chamada da função.
Quando facilitar a leitura ou manutenção
Trecho de código:
const adviceIdEl = document.getElementById("adviceId")
// [...] MAIS TARDE
adviceIdEl.innerText = ...
É mais fácil ler adviceIdEl.innerText do que document.getElementById("adviceId").innerText. Não só isso, mas caso eu usasse esse elemento HTML em outros lugares do código e, por ventura, eu alterasse o nome do id, haveria apenas um ponto de alteração a ser feito. Isso facilita a manutenção e lapidação em projetos maiores.
console.error() no lugar de console.log()?console.error()border e outline:border faz parte da caixa do elemento, influenciando o tamanho total. Já outline não ocupa espaço, funcionando como um simples contorno externo.border serve para estilização visual permanente, já outline para feedback temporário (foco em campos de formulário, por exemplo).border pode ter estilos diferentes em cada lado, enquanto outline não.:focus e :focus-visible:A pseudo-classe :focus seleciona todos os elementos focados da página, sejam eles por clique com o mouse ou navegação via teclado. Já :focus-visible faz a seleção de elementos focados geralmente via navegação com teclado.
font-size: 62.5% está caindo em desuso? Qual alternativa moderna substituiu essa prática atualmente?A estratégia descrita está caindo em desuso pois prejudica o cálculo responsivo quando o usuário aumenta o Zoom. Você pode até pensar que, pelo site ter sido projetado para o tamanho de fonte-base 10px, nada mudaria ao aplicar o Zoom, mas isso está equivocado. Usuários com baixa visão podem definir nas configurações de acessibilidade um tamanho-base padrão, como 20px. Quando você força o tamanho base via font-size: 62.5%, poderá frustrar a decisão do usuário, pois, em alguns navegadores, ao aplicar o zoom, o navegador recalcula as medidas baseando-se no valor definido no HTML e não no root real.
A alternativa moderna e padrão nos dias de hoje é abdicar da conveniência para cálculos que font-size: 62.5% oferece e respeitar o tamanho padrão do root real no HTML, isto é, font-size: 100%.
clamp()Suponhamos que o título do cabeçalho de um site tenha sido projetado por um designer para ter as seguintes medidas:
→ Tamanho de fonte mínimo: 24px → Tamanho de fonte máximo: 43px → Breakpoint "mínimo": 600px → Breakpoint "máximo": 1400px
clamp() correspondente a essas exigências:Bloco de código:
font-size: clamp(1.5rem, 2.375vw + 0.609375rem, 2.6875rem)
Resolução 👀:
Não. De acordo com as exigências da WCAG 1.4.4, quando o usuário amplia a página, os elementos devem crescer até 200% de seu tamanho inicial. Ao utilizar clamp() + vw, ampliar a página com zoom de página (page zoom) pode reduzir o tamanho dos elementos, impedindo que eles dobrem de tamanho e violando uma das diretrizes de acessibilidade definidas pela WCAG 1.4.4.
cards.Para Elise Hein, a fluidez excessiva dos elementos de uma aplicação pode criar uma experiência desagradável e frustrante para os usuários. Segundo ela, existe uma motivação implícita para o redimensionamento de tela: o espaço, não o tamanho dos elementos. Quando um usuário redimensiona a tela, ela muitas vezes não quer alterar a escala dos elementos ou testar a responsividade da aplicação, mas sim visualizar o conteúdo de forma distinta. Se aumentar a janela, por exemplo, é possível que ele deseje ver mais conteúdo do site, não o mesmo conteúdo em escala ampliada.
Por fim, a autora vai ainda mais fundo ao questionar: será que a fluidez excessiva não reduz a pressão em designers e desenvolvedores web para adaptar o layout em diferentes tamanhos de tela e contextos de uso?