Esta é a primeira aula do Nível 2. Ao final dela você terá um repositório Git publicado na internet, o ambiente de trabalho do semestre inteiro montado e uma ideia clara de onde o Nível 2 vai chegar: uma aplicação full-stack com API própria, login do Google e CRUD persistido.

🎯 Objetivos de aprendizagem¶

Ao final desta aula você será capaz de:

• Explicar como esta trilha funciona: três unidades, três marcos do projeto, projeto fio-condutor e projeto autoral.
• Descrever o modelo cliente-servidor e narrar, passo a passo, o que acontece entre digitar uma URL e ver a página na tela.
• Identificar os métodos e os códigos de status HTTP mais usados e decompor uma URL em suas partes.
• Distinguir front-end, back-end e banco de dados, e classificar uma aplicação como estática ou dinâmica.
• Montar e verificar o ambiente de desenvolvimento (VS Code, navegador com DevTools, Node.js 22 LTS e Git) pela linha de comando.
• Versionar um projeto com Git usando o ciclo init → status → add → commit → log e publicá-lo no GitHub.
• Colocar um site estático no ar com o GitHub Pages e explicar o que acontece a cada git push.

📋 Pré-requisitos¶

No Nível 1 você aprendeu a escrever HTML semântico, estilizar com CSS (layout, responsividade, animações) e programar o comportamento das páginas com JavaScript (variáveis, funções, eventos, validação de formulários). Hoje o Nível 2 pega esse repertório e o coloca dentro de um processo profissional: ambiente configurado, código versionado, projeto publicado. Nas próximas 16 aulas esse mesmo projeto vai crescer até virar uma aplicação com servidor próprio.

Checklist para começar:

• [ ] Um notebook (ou uma máquina do laboratório) com Google Chrome ou Firefox atualizado.
• [ ] Permissão para instalar programas na máquina — ou, no laboratório, saber que as instalações se perdem no reboot (a §7.5 resolve isso).
• [ ] Uma conta de e-mail que você realmente acessa (vai virar sua conta do GitHub).
• [ ] Uma ideia, mesmo vaga, de tema para o seu projeto autoral (§1.5). Você decide hoje ou até a próxima aula.

Você não precisa saber Git, terminal ou Node.js. Tudo isso começa do zero hoje.

🗺️ Roteiro¶

1. Como esta trilha funciona¶

1.1 O que esta trilha cobre¶

O que esta trilha cobre (a mesma ementa da disciplina em que esta trilha nasceu, Desenvolvimento Web): arquitetura de uma aplicação web; tecnologias de back-end; tecnologias de front-end; bancos de dados para web.

Objetivo geral: ao concluir esta trilha você projeta, implementa e publica uma aplicação web completa — interface acessível e responsiva, comportamento dinâmico em JavaScript, API própria em Node.js/Express, autenticação com conta Google e operações de CRUD com persistência.

A palavra que resume o Nível 2 é profundidade. No Nível 1 você aprendeu as três linguagens da plataforma. Aqui você aprende a arquitetura em que elas vivem: como um site é servido, como duas máquinas conversam por HTTP, como o código sai da sua pasta e vai parar em um endereço público, e como o servidor deixa de ser um mistério e passa a ser código seu.

1.2 Três unidades, três camadas¶

Esta trilha adota aprendizagem baseada em projeto: um único aplicativo, construído de forma incremental, ganhando uma camada por unidade.

Repare que as unidades são cumulativas: o HTML da Unidade 1 continua lá na Unidade 3, servido pelo seu próprio servidor. Nada é jogado fora.

1.3 A sequência das aulas¶

O conteúdo abaixo é o mesmo em qualquer turma ou semestre, e serve igualmente a quem estuda por conta própria, sem vínculo com nenhuma turma.

⚠️ Atenção Se você depende da rede do laboratório para subir seu trabalho, não deixe para o último minuto: ela tende a cair justamente quando mais gente está enviando ao mesmo tempo. Rode git push assim que terminar cada parte, não só no fim da aula.

1.4 Os três marcos do projeto¶

Os três marcos são individuais, práticos e recaem sobre o mesmo projeto autoral. Cada um vive no mesmo repositório público do GitHub — não .zip, não pasta no Drive, não print de tela. O repositório é o produto, e o histórico de commits faz parte dele.

Esta trilha soma cerca de 60 h de estudo: aproximadamente 45 h acompanhando as 16 aulas — a construção guiada do projeto fio-condutor — e 15 h de prática independente ligada ao projeto autoral, em atividades de cerca de 1 h por aula.

⚠️ Atenção A prática independente não é bônus: ela prepara direto o marco da unidade. Quem pula a atividade de uma aula chega na seguinte sem o pré-requisito, porque cada aula assume que a anterior foi concluída.

1.5 O projeto fio-condutor e o projeto autoral¶

A regra pedagógica do WebLab tem duas metades:

1. O projeto fio-condutor é o Café Cerrado, construído passo a passo ao longo das aulas. É uma cafeteria fictícia de Sinop/MT, que torra grãos do cerrado mato-grossense. Na Unidade 1 ela é um site estático publicado no GitHub Pages; na Unidade 2 ganha cardápio dinâmico, busca, filtros e navegação SPA; na Unidade 3 ganha uma API em Express, login com conta Google e um CRUD de produtos com persistência. Digite o código você mesmo — não copie e cole.
2. Em paralelo, você desenvolve um projeto autoral com a mesma arquitetura e um domínio diferente. Os marcos são sobre o projeto autoral.

Exemplos de temas que funcionam: catálogo de plantas do Pantanal, agenda de quadras esportivas, mural de estágios do curso, brechó, controle de pescarias no Teles Pires, loja de peças de bicicleta, biblioteca de uma escola, feira de produtores locais.

O critério para saber se um tema serve é objetivo: ele tem uma lista de coisas? Produtos, plantas, quadras, vagas, peças, livros. O semestre inteiro gira em torno de uma coleção de itens que é exibida, filtrada, criada, editada e apagada. Se o seu tema não tem uma lista clara, troque agora — e não na Unidade 3.

💡 Dica Escolha um domínio sobre o qual você tenha conteúdo real: nomes, preços, descrições, fotos. O erro clássico é escolher "site de uma empresa" e travar na hora de escrever a terceira frase. Tema concreto gera projeto melhor — e mais fácil de defender quando alguém perguntar como funciona.

1.6 As quatro camadas de prática de cada aula¶

Cada aula do WebLab tem, sempre nesta ordem:

1. 💻 Mão na massa — passo a passo guiado no Café Cerrado. Todo mundo faz junto, digitando (não colando).
2. 🧪 Laboratório — exercícios práticos em três níveis: A (fixação), B (aplicação) e C (desafio para quem termina antes).
3. 🏆 Desafios — extras opcionais, com estrelas de dificuldade: ⭐ (1–2 h), ⭐⭐ (uma tarde), ⭐⭐⭐ (um fim de semana). Não são obrigatórios, mas aprofundam a aula e ficam bem no portfólio.
4. 🏠 Atividade assíncrona (1 h) — a tarefa da semana, ligada ao projeto autoral.

Uma rotina que funciona: leia os objetivos antes da aula; digite o código durante a aula; faça o Laboratório A no mesmo dia; faça o Nível B e a atividade assíncrona ao longo da semana; encare o Nível C e os Desafios se sobrar fôlego.

1.7 Uma palavra sobre o formato das entregas¶

Toda entrega desta trilha é um link de repositório público no GitHub. Isso não é burocracia: é a forma como software é entregue no mercado. Um repositório bem cuidado — com README.md que explica o projeto, commits com mensagens legíveis e o site publicado — é a peça de portfólio mais barata que existe. Você vai terminar esta trilha com duas: o Café Cerrado e o seu projeto autoral.

2. Arquitetura de uma aplicação web¶

2.1 O modelo cliente-servidor¶

A Web inteira funciona sobre um modelo de duas partes e uma regra:

• Cliente: quem pede. Normalmente o navegador, mas também pode ser um aplicativo de celular, um script no terminal (curl), outro servidor ou — cada vez mais — um agente de IA.
• Servidor: quem responde. Um programa que fica permanentemente escutando em uma porta, esperando requisições.
• A regra: o cliente sempre inicia. Em HTTP clássico o servidor nunca manda nada de forma espontânea; ele só responde ao que foi pedido.

     CLIENTE                                            SERVIDOR
   ┌───────────┐          1. requisição HTTP          ┌───────────────┐
   │ Navegador │  ──────────────────────────────────> │  Servidor web │
   │  (você)   │          GET /index.html             │  (Node, nginx,│
   │           │                                      │   Apache…)    │
   │           │  <────────────────────────────────── │               │
   └───────────┘          2. resposta HTTP            └───────────────┘
                          200 OK + HTML

Na Unidade 3 você vai escrever o retângulo da direita. Até lá, ele é um serviço que outra pessoa mantém — o GitHub Pages, a partir de hoje.

2.2 O que acontece quando você digita um endereço¶

Esta sequência é uma das perguntas mais frequentes em entrevista técnica. Aprenda a narrá-la.

Passo 1 — Análise da URL. O navegador separa o endereço em partes (§3.4) e descobre qual protocolo usar e com quem falar.

Passo 2 — Resolução DNS. O nome cafecerrado.com.br não serve para roteamento; a rede trabalha com endereços IP. O navegador consulta o DNS (Domain Name System) para traduzir o nome em um IP, passando antes por caches: cache do navegador → cache do sistema operacional → arquivo hosts → servidor DNS do provedor.

Passo 3 — Conexão TCP. Com o IP em mãos, o navegador abre uma conexão TCP, normalmente na porta 80 (HTTP) ou 443 (HTTPS).

Passo 4 — Handshake TLS (só em HTTPS). Cliente e servidor negociam a criptografia, o servidor apresenta seu certificado digital e ambos combinam uma chave de sessão. É o que produz o cadeado na barra de endereço.

Passo 5 — Requisição HTTP. O navegador envia um texto (§3.1).

Passo 6 — Processamento no servidor. Se o recurso for um arquivo estático, o servidor apenas o lê do disco. Se for dinâmico, executa código, possivelmente consulta um banco e monta a resposta na hora.

Passo 7 — Resposta HTTP. Uma linha de status, cabeçalhos, uma linha em branco e o conteúdo.

Passo 8 — Renderização e sub-requisições. O navegador interpreta o HTML e dispara novas requisições para cada recurso referenciado: folhas de estilo, scripts, imagens, fontes. Cada uma repete os passos 5 a 7.

📌 Vale gravar A ordem das oito etapas e o papel de cada uma. Os pontos mais cobrados: DNS traduz nome em IP (não "acha o site"); TLS é o que torna o HTTP seguro (HTTPS = HTTP + TLS); e uma única página dispara dezenas de requisições, não uma.

2.3 Uma página não é um arquivo¶

Abrir uma página comum dispara de 30 a 200 requisições. Isso muda a forma de pensar em desempenho: não adianta otimizar o HTML se a página baixa 4 MB de imagens e cinco fontes. Você vai medir isso na §7.6 e voltar ao tema na Aula 06, quando o Lighthouse entrar em cena.

3. HTTP: o idioma entre cliente e servidor¶

HTTP (HyperText Transfer Protocol) é um protocolo de texto. Isso é uma decisão de projeto: qualquer pessoa consegue ler uma requisição sem ferramenta especial. Veja.

3.1 Anatomia de uma requisição e de uma resposta¶

Uma requisição:

GET /cardapio.html HTTP/1.1
Host: cafecerrado.exemplo.br
User-Agent: Mozilla/5.0 (X11; Linux x86_64) Chrome/139.0
Accept: text/html,application/xhtml+xml
Accept-Language: pt-BR,pt;q=0.9
Connection: keep-alive

A primeira linha diz o que se quer (GET), onde (/cardapio.html) e em qual versão do protocolo. As demais são cabeçalhos (headers): metadados no formato Nome: valor.

A resposta correspondente:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 3184
Cache-Control: max-age=600
Server: GitHub.com

<!DOCTYPE html>
<html lang="pt-BR">
<head>
  <title>Cardápio — Café Cerrado</title>
</head>

Três partes: linha de status (200 OK), cabeçalhos, e — depois de uma linha em branco — o corpo. Essa linha em branco é o que separa metadados de conteúdo. Guarde: na Unidade 3, quando você escrever res.status(201).json(produto) no Express, é exatamente esse texto que sai pela rede.

3.2 Métodos¶

Essas quatro operações são exatamente o CRUD (Create, Read, Update, Delete) que você vai implementar nas Aulas 13, 15 e 16. Repare que o método já diz a intenção: o caminho /api/produtos é o mesmo, o que muda é o verbo.

⚠️ Atenção GET deve ser seguro: não pode alterar estado no servidor. Uma rota GET /apagar-produto/3 funciona tecnicamente e é um erro de projeto grave — buscadores, pré-carregadores do navegador e agentes de IA seguem links GET sozinhos, e apagariam seus produtos sem que ninguém clicasse em nada.

3.3 Códigos de status¶

Os que você mais vai usar (e devolver) ao longo desta trilha:

💡 Dica Mnemônico que resolve 90% das dúvidas: 4xx é culpa de quem pediu; 5xx é culpa de quem respondeu. Um 404 diz "você pediu algo que não existe". Um 500 diz "eu quebrei ao tentar responder".

3.4 Anatomia de uma URL¶

https://cafecerrado.exemplo.br:443/cardapio/cafes?categoria=espresso&ordem=preco#promocoes
└─┬─┘   └──────────┬───────────┘└┬┘└───────┬────┘└──────────────┬───────────────┘└───┬───┘
  1                2              3        4                    5                    6

Dois desses elementos viram protagonistas mais adiante: a query string é como a busca do cardápio vai conversar com a API (GET /api/produtos?q=cafe, Aula 13), e o fragmento é o que faz a navegação SPA funcionar sem recarregar a página (#/cardapio, Aula 10). Guarde os dois.

3.5 HTTP não tem memória¶

HTTP é stateless: cada requisição é independente e o servidor, por si só, não lembra o que aconteceu na anterior. Isso parece uma limitação e é, na verdade, o que permitiu a Web escalar — qualquer servidor de um conjunto pode atender qualquer requisição.

Login, carrinho e sessão são construídos por cima disso: o cliente reenvia, a cada requisição, uma credencial (um cookie ou um token no cabeçalho Authorization). É exatamente o que você vai implementar na Aula 14, quando o Café Cerrado passar a exigir login do Google para escrever dados.

🔬 Investigue Abra o site da sua universidade ou escola (ou outro site grande de sua preferência), pressione F12, vá à aba Network, marque Disable cache e recarregue com Ctrl+F5. Observe quatro coisas: (1) quantas linhas apareceram — cada uma é uma requisição completa dos passos 5 a 7 da §2.2; (2) a coluna Type (document, stylesheet, script, png, font); (3) clique na primeira linha, abra Headers e localize Content-Type, Server e o status; (4) na barra inferior, leia o total de requisições e o peso transferido. Anote os números: você vai comparar com os do seu próprio site no fim da aula.

4. Front-end, back-end e banco de dados¶

Uma aplicação web moderna se organiza em três camadas — que são, não por acaso, as três unidades desta trilha.

┌──────────────────┐  HTTP  ┌────────────────────┐  SQL/arquivo  ┌───────────────┐
│  APRESENTAÇÃO    │ <────> │     APLICAÇÃO      │ <───────────> │     DADOS     │
│  navegador       │        │  Node.js + Express │               │  JSON, MySQL  │
│  HTML/CSS/JS     │        │  regras de negócio │               │               │
└──────────────────┘        └────────────────────┘               └───────────────┘
     Unidades 1 e 2                 Unidade 3                       Unidade 3

Uma regra que vale para sempre: o navegador nunca fala com o banco de dados. Se ele falasse, qualquer usuário poderia ler e apagar tudo, porque todo código front-end é público — o usuário pode abrir o DevTools, ler seu JavaScript e alterar valores. Validação no cliente existe para conforto; validação no servidor existe para segurança. Você vai ver essa diferença doer na Aula 13.

4.1 Site estático × aplicação dinâmica¶

⚠️ Atenção "Dinâmico", em arquitetura, significa HTML montado no servidor. Uma página estática cheia de JavaScript, animações e busca continua sendo estática do ponto de vista arquitetural — é o caso do Café Cerrado até a Aula 10. É por isso que ele pode ficar hospedado de graça no GitHub Pages durante duas unidades inteiras.

5. Quem está do outro lado hoje¶

Durante trinta anos a resposta era óbvia: do outro lado da requisição havia uma pessoa olhando uma tela. Isso mudou.

Relatórios de tráfego da web (Imperva/Thales, Cloudflare Radar) mostram que mais da metade do tráfego web já é gerada por máquinas — a primeira vez em uma década em que os bots ultrapassaram os humanos. O crescimento vem principalmente de agentes de IA: em 2025 o tráfego de bots de IA cresceu quase 190%, enquanto o tráfego humano cresceu cerca de 3%. O volume de rastreamento para treinar modelos chegou a várias vezes o volume de rastreamento dos buscadores tradicionais.

E essas máquinas já são clientes que pagam:

• x402 (proposto pela Coinbase) ressuscitou o código de status HTTP 402 Payment Required, reservado desde os anos 90 e nunca usado de verdade. O agente faz uma requisição, recebe 402 com o preço, paga e refaz a requisição — sem checkout, sem cadastro, sem humano.
• Redes de pagamento para agentes (Mastercard Agent Pay, Visa Trusted Agent Protocol, AP2 do Google) dão identidade e meio de pagamento a programas.
• MCP (Model Context Protocol), aberto em 2024 e doado à Linux Foundation, padronizou a forma de conectar assistentes de IA a dados e ferramentas. Milhares de serviços já expõem "portas para agentes" em vez de telas para humanos.

🧠 Você sabia? O código 402 Payment Required está na especificação do HTTP desde 1997 marcado como "reservado para uso futuro". Ficou quase três décadas sem uso prático — um número guardado à espera de um caso que só apareceu quando as máquinas viraram compradoras. Vale como lembrete de que o HTTP que você está aprendendo é um protocolo vivo: os mesmos verbos e os mesmos códigos de 1997 continuam sustentando o que se inventa hoje.

Por que isso importa para o que você vai construir aqui? Porque muda o que é "a fachada" de um sistema. O agente não quer o botão azul: ele quer o dado, em JSON, por uma API previsível e documentada. A interface humana continua importando — mas ela passa a ser uma das saídas, não a única.

A boa notícia é que tudo que você vai aprender aqui serve aos dois públicos. HTML semântico (Aula 03) é o que permite a uma máquina entender a estrutura da página. HTTP bem usado (§3) é o que torna a API previsível. JSON (Aula 10) é o formato que os dois lados falam. Express e rotas REST (Unidade 3) são a porta de entrada. Ninguém precisa mudar de assunto: precisa aprender o assunto direito.

6. IA no desenvolvimento: ferramenta, não atalho¶

A pergunta não é "pode usar IA?". Pode. A pergunta é "como usar bem?".

A favor de usar. Assistentes de código escrevem o repetitivo — estrutura inicial, testes, documentação, refatorações mecânicas — e liberam você para o que decide o resultado: arquitetura, modelagem de dados, experiência do usuário. Pesquisas de mercado apontam que a grande maioria dos desenvolvedores já usa algum assistente ao menos uma vez por mês, e que quem usa diariamente entrega bem mais mudanças por semana. Ficar de fora não é pureza técnica; é desvantagem competitiva.

Contra usar sem critério. Um estudo controlado da METR (2025) mediu desenvolvedores experientes trabalhando em bases de código que dominavam: quando usaram IA, ficaram em média 19% mais lentos — e ainda assim acharam que tinham ficado mais rápidos. Ferramenta sem domínio do problema atrapalha e dá a sensação contrária.

Então por que estudar HTTP, DOM e Express a fundo, se a IA escreve isso? Pelo mesmo motivo pelo qual você estuda Arquitetura de Computadores sem programar em Assembly no dia a dia: para entender o que acontece por baixo quando quebra. A IA escreve o código; quem julga se ele está correto, seguro e bem arquitetado é você. E só revisa bem quem entende a base.

Use IA como apoio, não como atalho: peça para ela explicar, não para resolver o que você ainda não entende. O teste real é simples — se você não consegue explicar uma linha do seu código, ela ainda não é sua.

💡 Dica Um uso honesto e produtivo desde já: peça ao assistente para explicar um erro do terminal, não para "consertar o projeto". Cole a mensagem literal, pergunte o que ela significa e o que a causa. Você aprende a ler a mensagem — que é a habilidade que vai sobrar quando a ferramenta mudar de nome.

7. Ambiente de desenvolvimento¶

7.1 O que instalar nesta semana¶

Sobre o Node.js: baixe sempre a versão marcada como LTS (Long Term Support). LTS significa suporte prolongado e estabilidade — é a versão que se usa em produção. Nesta trilha usamos o Node.js 22 LTS.

7.2 Verificando as instalações pelo terminal¶

Instalar não basta: é preciso confirmar que o sistema encontra os programas. Abra um terminal (no VS Code, Ctrl+') e execute:

node -v
npm -v
git --version
code --version

Saída esperada (os números podem variar um pouco):

v22.13.0
10.9.2
git version 2.43.0
1.96.2

Se algum comando responder command not found (Linux/macOS) ou não é reconhecido como um comando interno ou externo (Windows), o programa foi instalado mas não está no PATH — normalmente basta fechar e abrir o terminal de novo, porque o PATH só é lido na abertura. Se persistir, reinstale marcando a opção "adicionar ao PATH".

🔎 Por baixo do capô PATH é uma variável de ambiente com uma lista de pastas. Quando você digita node, o sistema não procura no computador inteiro: ele percorre essa lista, na ordem, procurando um executável com esse nome. É por isso que a instalação precisa "adicionar ao PATH" e por que o terminal aberto antes da instalação não enxerga o programa novo — ele guardou a lista antiga.

7.3 Extensões do VS Code¶

Instale-as com Ctrl+Shift+X. Depois, em File → Preferences → Settings, procure format on save e marque a opção: seu código passa a ser formatado a cada Ctrl+S. Isso elimina uma categoria inteira de discussão inútil sobre indentação — inclusive com você mesmo daqui a três semanas.

7.4 Abra a pasta, não o arquivo¶

Regra permanente: no VS Code, use File → Open Folder e abra a pasta raiz do projeto. Nunca abra um .html solto. Live Server, caminhos relativos, terminal integrado e Git dependem de haver uma pasta raiz — e metade dos problemas de aula 1 vem de ignorar isso.

7.5 Trabalhando no laboratório¶

Nas máquinas do laboratório as instalações podem se perder entre uma aula e outra. Duas defesas:

1. Seu código vive no GitHub, não na máquina. Esse é o ponto principal da §8: qualquer computador com Git baixa seu projeto inteiro em um comando.
2. Configure o Git no início de cada aula, se necessário. São dois comandos (§8.3) e levam dez segundos.

7.6 DevTools: o raio-X do navegador¶

Pressione F12 (ou botão direito → Inspecionar). Você vai usar isto todos os dias do semestre.

8. Git: controle de versão desde o dia 1¶

8.1 O problema que o Git resolve¶

Você já viu (ou já criou) uma pasta assim:

projeto/
├── site.html
├── site_v2.html
├── site_v2_corrigido.html
├── site_final.html
├── site_final_MESMO.html
└── site_final_agora_vai.html

Isso é controle de versão manual — e ele falha em tudo o que importa: você não sabe o que mudou entre duas versões, nem por quê, nem quando, nem como voltar a um estado intermediário sem quebrar o resto.

O Git resolve isso registrando fotografias do projeto inteiro ao longo do tempo. Cada fotografia é um commit: o estado completo dos arquivos, mais autor, data e uma mensagem explicando a intenção. Com isso você consegue voltar no tempo, comparar duas versões linha a linha, descobrir quando um bug entrou e trabalhar com segurança porque nada se perde.

8.2 Os três estados de um arquivo¶

   working directory          staging area              repositório
   ┌────────────────┐  add   ┌───────────────┐  commit  ┌──────────────┐
   │  MODIFICADO    │ ─────> │   PREPARADO   │ ───────> │  VERSIONADO  │
   │ você editou    │        │ vai entrar no │          │  histórico   │
   │ o arquivo      │        │ próximo commit│          │  permanente  │
   └────────────────┘        └───────────────┘          └──────────────┘

A staging area (área de preparação) é o que confunde no começo e o que dá poder ao Git: ela deixa você escolher quais mudanças entram no próximo commit. Editou cinco arquivos mas só três formam uma mudança coerente? Prepare esses três, faça o commit, depois cuide do resto. Commits coerentes são o que torna o histórico legível.

8.3 Configuração inicial (uma única vez por máquina)¶

git config --global user.name "Seu Nome Completo"
git config --global user.email "seu-email@exemplo.com"
git config --global init.defaultBranch main
git config --global core.editor "code --wait"

Confira o que ficou gravado e de onde veio cada configuração:

git config --list --show-origin

⚠️ Atenção Use o mesmo e-mail da sua conta do GitHub. É por ele que o GitHub associa os commits ao seu perfil. Com um e-mail diferente, seus commits aparecem como se fossem de um desconhecido — e, em uma entrega avaliada, isso vira dúvida sobre autoria.

8.4 O ciclo básico¶

# 1. transformar a pasta atual em um repositório Git
git init

# 2. ver o que mudou e em que estado está
git status

# 3. preparar arquivos para o commit
git add index.html      # um arquivo específico
git add .               # tudo que mudou na pasta atual e subpastas

# 4. registrar a fotografia com uma mensagem descritiva
git commit -m "Cria a página inicial do Café Cerrado"

# 5. ver o histórico
git log --oneline

Dois comandos que não estavam no roteiro clássico e que você vai usar muito:

# ver exatamente o que mudou, linha a linha, antes de preparar
git diff

# descartar as alterações não preparadas de um arquivo
git restore index.html

git status é o comando mais importante da lista. Ele não só mostra o estado como sugere o comando seguinte. Quando estiver perdido, rode git status e leia com calma — a resposta costuma estar ali.

8.5 Mensagens de commit que servem para alguma coisa¶

Uma mensagem de commit responde à pergunta "o que este commit faz?". Escreva no imperativo, como se completasse a frase "Este commit…".

Commits pequenos e frequentes valem mais do que um commit gigante no fim da semana. Regra prática: um commit por ideia concluída. Terminou o cabeçalho? Commit. Terminou o rodapé? Commit.

🔎 Por baixo do capô Um commit não é "a diferença desde o anterior": é um instantâneo completo da árvore de arquivos, identificado por um hash (aquela sequência tipo a3f9c21) calculado a partir do conteúdo, do autor, da data, da mensagem e do commit anterior. Como o hash depende do commit anterior, alterar qualquer coisa no passado muda todos os hashes seguintes — é por isso que o histórico do Git é praticamente à prova de adulteração, e é por isso que git log conta uma história confiável.

8.6 O .gitignore¶

Nem tudo deve entrar no repositório: arquivos gerados, dependências baixadas, configurações da sua máquina e — nunca esqueça — segredos. O arquivo .gitignore, na raiz do projeto, lista o que o Git deve ignorar:

# Sistema operacional
.DS_Store
Thumbs.db

# Editor
.vscode/

# Node.js (a partir da Unidade 3)
node_modules/

# Segredos: chaves e senhas nunca entram no repositório
.env

Duas dessas linhas evitam desastres reais. node_modules/ costuma ter dezenas de milhares de arquivos e é reconstruído com um npm install — versionar isso é entupir o repositório à toa. E .env é onde, na Aula 14, ficará o seu Client ID do Google: um arquivo desses vazado em repositório público é o tipo de erro que rende notícia.

8.7 Repositório remoto: GitHub¶

O Git é a ferramenta; o GitHub é um serviço que hospeda repositórios Git na internet. Ele dá três coisas ao mesmo tempo: backup, portfólio público e o canal de entrega desta trilha.

# conectar o repositório local ao remoto criado no GitHub
git remote add origin https://github.com/SEU-USUARIO/cafe-cerrado.git
git branch -M main
git push -u origin main

# nos próximos envios, basta:
git push

O que cada linha faz:

• git remote add origin URL cadastra um apelido (origin) para o endereço do repositório remoto.
• git branch -M main renomeia a branch atual para main, que é o nome padrão no GitHub.
• git push -u origin main envia os commits e memoriza a associação; o -u é o que permite escrever só git push depois.

E, para trazer para a máquina um repositório que já existe (o caso de trocar de computador ou usar o laboratório):

git clone https://github.com/SEU-USUARIO/cafe-cerrado.git

💡 Dica O GitHub não aceita mais senha da conta na linha de comando. Ao pedir autenticação, use um Personal Access Token (em Settings → Developer settings → Personal access tokens) no lugar da senha, ou configure uma chave SSH. No Windows, o Git Credential Manager instalado junto com o Git abre uma janela de login do navegador e resolve isso sozinho.

8.8 GitHub Pages: seu primeiro deploy¶

Todo repositório público do GitHub pode virar um site estático publicado, de graça:

1. No repositório, acesse Settings → Pages.
2. Em Source, escolha Deploy from a branch, a branch main e a pasta raiz (/ (root)).
3. Salve. Em alguns minutos o site estará em https://SEU-USUARIO.github.io/cafe-cerrado/.

A partir daí, cada git push republica o site automaticamente. Esse é o seu primeiro fluxo de deploy: você edita, commita, envia, e o mundo vê. Guarde a sensação — na Unidade 3 o mesmo raciocínio vale para uma API, com algumas camadas a mais.

💻 Mão na massa — o repositório cafe-cerrado no ar¶

Objetivo do bloco: sair da aula com o Café Cerrado publicado em um endereço público, versionado, com dois commits e um README.md decente.

Passo 1 — Criar a pasta e abrir no VS Code¶

Crie, em um lugar que você encontre depois (por exemplo Documentos/dev-web/), a pasta cafe-cerrado. Abra o VS Code e use File → Open Folder apontando para ela.

dev-web/
├── cafe-cerrado/        ← projeto fio-condutor (construído ao longo das aulas)
└── meu-projeto/         ← projeto autoral (tema seu, mesma arquitetura)

⚠️ Atenção Nomes de arquivos e pastas em minúsculas, sem espaços, sem acentos, com hífen separando palavras: cafe-cerrado, nunca Café Cerrado. Servidores Linux — inclusive o do GitHub Pages — diferenciam maiúsculas de minúsculas, e o que funciona no seu Windows quebra ao publicar.

Passo 2 — A página inicial mínima¶

Crie o arquivo index.html na raiz da pasta. Digite (não cole):

cafe-cerrado/index.html

<!DOCTYPE html>
<html lang="pt-BR">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Café Cerrado — cafeteria em Sinop/MT</title>
</head>
<body>
  <h1>Café Cerrado</h1>
  <p>Cafeteria de grãos torrados do cerrado mato-grossense, em Sinop/MT.</p>
  <p>Site em construção no Nível 2 do WebLab (Desenvolvimento Web).</p>
</body>
</html>

O nome index.html não é decorativo: é a convenção que todo servidor web segue para decidir o que entregar quando alguém pede a pasta em vez de um arquivo. Pedir https://exemplo.br/ entrega https://exemplo.br/index.html.

Abra a página com o Live Server (botão Go Live, canto inferior direito) e confirme que os acentos aparecem corretos. Leia a URL que abriu — algo como http://127.0.0.1:5500/index.html — com a §3.4 na cabeça: esquema http, host 127.0.0.1, porta 5500, caminho /index.html. Você acabou de subir um servidor web na sua própria máquina.

Passo 3 — O README.md¶

O README.md é a primeira coisa que o GitHub mostra a quem abre o repositório — e a primeira coisa que qualquer pessoa lê para decidir se vale a pena continuar explorando o projeto. Crie-o na raiz:

cafe-cerrado/README.md

# Café Cerrado

Site da cafeteria fictícia **Café Cerrado** (Sinop/MT), construído aula a aula
no Nível 2 do WebLab (Desenvolvimento Web).

## O projeto

Uma cafeteria que torra grãos do cerrado mato-grossense. O site apresenta a
casa, o cardápio e um canal de contato. Ao longo do semestre ele evolui de
página estática para aplicação com API própria.

## Site publicado

https://SEU-USUARIO.github.io/cafe-cerrado/

## Tecnologias

HTML5 e CSS3. JavaScript entra na Unidade 2; Node.js e Express, na Unidade 3.

## Como executar localmente

1. Clone o repositório.
2. Abra a pasta no VS Code.
3. Clique em "Go Live" (extensão Live Server).

## Autoria

Seu Nome — Desenvolvimento Web.

Troque SEU-USUARIO e Seu Nome pelos seus. O .md é Markdown, a mesma linguagem em que estas aulas são escritas: # faz título, **texto** deixa em negrito, - faz lista.

Passo 4 — O .gitignore¶

cafe-cerrado/.gitignore

# Sistema operacional
.DS_Store
Thumbs.db

# Editor
.vscode/

# Node.js (a partir da Unidade 3)
node_modules/

# Segredos
.env

O arquivo começa com ponto, então alguns gerenciadores de arquivos o escondem. No VS Code ele aparece normalmente.

Passo 5 — Primeiro commit¶

No terminal integrado do VS Code (Ctrl+'), confirme que você está na pasta certa e execute:

git init
git status
git add .
git status
git commit -m "Cria a estrutura inicial do site do Cafe Cerrado"
git log --oneline

Rode git status duas vezes, como está acima, e compare as saídas. Na primeira, os arquivos aparecem em vermelho sob Untracked files; na segunda, em verde sob Changes to be committed. Você acabou de ver a staging area da §8.2 funcionando.

A saída de git log --oneline deve ser parecida com:

7c1f4ab (HEAD -> main) Cria a estrutura inicial do site do Cafe Cerrado

Esse 7c1f4ab é o início do hash do commit. É o endereço permanente desta fotografia.

Passo 6 — Criar o repositório no GitHub e enviar¶

1. Acesse https://github.com, faça login e clique em New repository.
2. Nome: cafe-cerrado. Visibilidade: Public.
3. Não marque "Add a README file", "Add .gitignore" nem "Choose a license" — você já criou o que precisa localmente, e marcar essas opções cria commits no remoto que vão conflitar com os seus.
4. Clique em Create repository e copie a URL exibida.

De volta ao terminal:

git remote add origin https://github.com/SEU-USUARIO/cafe-cerrado.git
git branch -M main
git push -u origin main

Atualize a página do GitHub: seus três arquivos estão lá, e o README.md aparece renderizado embaixo da lista.

Passo 7 — Ligar o GitHub Pages¶

1. No repositório, vá em Settings → Pages.
2. Em Source, selecione Deploy from a branch; em Branch, escolha main e a pasta / (root). Clique em Save.
3. Aguarde de um a três minutos e recarregue a página de Settings → Pages: aparece o endereço https://SEU-USUARIO.github.io/cafe-cerrado/.

Abra esse endereço no celular também. É a mesma página que estava na sua máquina, agora servida da internet para o mundo.

Passo 8 — O segundo commit: fechando o ciclo¶

Edite o README.md, colando a URL real do site publicado no lugar de SEU-USUARIO. Depois:

git status
git diff
git add README.md
git commit -m "Registra o endereco do site publicado no README"
git push

Espere um minuto e recarregue o site publicado. Ele mudou sozinho: você acabou de fazer um deploy sem clicar em nada além de git push.

Passo 9 — O projeto autoral começa hoje¶

Repita os passos 1 a 7 na pasta meu-projeto, com o seu tema: nome do projeto no <title> e no <h1>, um parágrafo dizendo o que é e para quem é, um README.md com o tema e as páginas que você pretende ter. Repositório público, GitHub Pages ligado.

A partir de hoje a regra é: o que o Café Cerrado ganha em aula, o seu projeto ganha em paralelo.

Como testar¶

• git log --oneline mostra dois commits, com mensagens legíveis no imperativo.
• git status responde nothing to commit, working tree clean.
• O repositório cafe-cerrado aparece público no seu perfil do GitHub, com index.html, README.md e .gitignore.
• https://SEU-USUARIO.github.io/cafe-cerrado/ abre a página com os acentos corretos, inclusive no celular.
• No DevTools do site publicado, aba Network, o index.html aparece com status 200 e o cabeçalho de resposta Server: GitHub.com.
• O mesmo checklist vale para o repositório do seu projeto autoral.

Resultado esperado: dois sites estáticos publicados na internet, versionados com Git, com histórico limpo e README.md que explica o projeto.

🧪 Laboratório¶

Nível A — Fixação¶

A1. Explique, em no máximo quatro linhas, a diferença entre cliente e servidor no modelo da §2.1, e diga quem inicia a conversa.

A2. Coloque em ordem as oito etapas da §2.2: (a) resposta HTTP; (b) resolução DNS; (c) renderização e sub-requisições; (d) conexão TCP; (e) requisição HTTP; (f) análise da URL; (g) handshake TLS; (h) processamento no servidor.

A3. Decomponha a URL abaixo, nomeando as seis partes da §3.4:

https://loja.cafecerrado.com.br:8443/produtos/moidos?origem=chapada&ordem=preco#avaliacoes

A4. Diga qual método HTTP e qual código de status você usaria em cada situação: (a) listar os produtos do cardápio; (b) cadastrar um produto novo com sucesso; (c) pedir um produto que não existe; (d) enviar um formulário com o campo preço em branco; (e) o servidor lançou uma exceção não tratada.

A5. O que significa dizer que o HTTP é stateless? Cite uma consequência prática disso para uma tela de login.

A6. Explique os três estados de um arquivo no Git e diga qual comando move o arquivo de um estado para o outro.

A7. Reescreva estas mensagens de commit no padrão da §8.5: alterações, aula 1, arrumei o css, commit final agora vai.

A8. Cite três tipos de arquivo que não devem entrar em um repositório e explique o porquê de cada um.

A9. Um site estático e uma aplicação dinâmica devolvem HTML para o navegador. Qual é, então, a diferença entre os dois? Classifique: SIGAA, cardápio do Café Cerrado na Unidade 1, portfólio pessoal, loja virtual.

A10. O que o comando git push -u origin main faz? Explique cada uma das quatro partes (push, -u, origin, main).

Nível B — Aplicação¶

B1. Use a aba Network do DevTools para comparar três sites: um portal de notícias, um e-commerce e o seu https://SEU-USUARIO.github.io/cafe-cerrado/. Para cada um, registre: número de requisições, peso total transferido, tempo até o Load e qual foi o maior recurso. Escreva um parágrafo levantando hipóteses para as diferenças.

Resultado esperado: uma tabela com três linhas e quatro medidas, mais um parágrafo de análise (por exemplo, "o portal fez 4× mais requisições por causa de anúncios e rastreadores").

B2. Plante e resolva um erro: no seu index.html publicado, apague a linha <meta charset="UTF-8">, faça commit e push. Espere o Pages republicar e abra o site. Descreva o que aconteceu com os acentos e explique por quê. Depois, desfaça — e faça o commit da correção com uma mensagem que descreva o conserto.

Resultado esperado: dois novos commits no histórico — o que quebra e o que conserta, ambos com mensagens claras — mais uma explicação de 3 a 5 linhas sobre o papel do charset na interpretação dos bytes.

B3. Escreva o histórico de commits de uma tarefa real. Adicione ao index.html do Café Cerrado, em quatro etapas independentes, cada uma com seu próprio commit: (1) um parágrafo com o endereço da cafeteria; (2) um parágrafo com o horário de funcionamento; (3) um link mailto: para contato; (4) o ano de fundação. Ao final, rode git log --oneline e confira se o histórico conta a história sozinho.

Resultado esperado: quatro commits, um por mudança, com mensagens no imperativo; git log --oneline legível por alguém que não viu o código.

B4. Investigue o certificado HTTPS do seu site publicado. Clique no cadeado do navegador e registre: quem emitiu o certificado, para qual domínio ele é válido, até quando vale. Explique em três linhas o que o Passo 4 da §2.2 tem a ver com esses dados.

Resultado esperado: três dados anotados e uma explicação ligando certificado, autoridade certificadora e a chave de sessão negociada no handshake TLS.

B5. Escreva um README.md decente para o seu projeto autoral, com: título, um parágrafo explicando o tema e o público, a lista de páginas previstas, as tecnologias, como executar localmente e o link do site publicado. Commit e push.

Resultado esperado: o README.md renderizado na página inicial do repositório, com pelo menos quatro seções e nenhum trecho copiado do modelo do Café Cerrado sem adaptação.

Nível C — Desafio¶

C1. Recuperação de desastre. Simule a perda da máquina: apague (de verdade, ou renomeie) a pasta local cafe-cerrado, clone o repositório do GitHub em outro diretório, confirme que os dois commits estão lá, faça uma alteração no README.md, commite e envie. Depois, responda por escrito: o que exatamente foi recuperado no git clone — só os arquivos atuais, ou o histórico inteiro? Comprove sua resposta com a saída de um comando.

C2. Meça o custo do HTTPS. No terminal, use curl para medir os tempos de uma requisição ao seu site publicado e a um site qualquer em HTTP simples, comparando o tempo de resolução DNS, de conexão TCP e de handshake TLS. Monte uma tabela com os três tempos para cada site e escreva um parágrafo sobre onde o tempo é gasto.

🏆 Desafios¶

🐛 Erros comuns¶

🏠 Para praticar depois da aula (1 h)¶

Parte 1 — Ambiente (20 min). Instale, na sua máquina pessoal, VS Code, Node.js 22 LTS e Git. Rode os quatro comandos de verificação da §7.2 e tire uma captura de tela do terminal com as quatro saídas visíveis.

Parte 2 — Projeto autoral (30 min). Crie o repositório público do seu projeto autoral no GitHub, seguindo os passos 1 a 7 do Mão na massa com o seu tema:

1. index.html com a estrutura mínima, <title>, <h1> e dois parágrafos apresentando o tema.
2. README.md no formato do exercício B5.
3. .gitignore.
4. Pelo menos dois commits com mensagens no imperativo.
5. GitHub Pages ligado e o site abrindo.

Parte 3 — Leitura dirigida (10 min). Se você tem acesso a uma biblioteca virtual pela sua instituição: QUEIRÓS & PORTELA, capítulo introdutório sobre a evolução e a arquitetura da Web; PUREWAL, capítulo 1, sobre o fluxo de trabalho do desenvolvedor (editor, terminal e Git). Anote duas ideias de cada texto que não apareceram nesta aula — elas voltam na discussão da próxima.

Critério de pronto: os dois links abrem (repositório público e site no ar); o git log mostra pelo menos dois commits com mensagens descritivas; a captura de tela mostra Node, npm, Git e VS Code respondendo com suas versões.

Guarde no seu repositório: o link do repositório do projeto autoral, o link do site publicado e a captura de tela do terminal. Sem .zip.

✅ Checkpoint do projeto¶

Ao fim desta aula você deve ter:

• [ ] VS Code, navegador, Node.js 22 LTS e Git instalados e verificados pelo terminal.
• [ ] Extensões Live Server e Prettier instaladas, com format on save ativado.
• [ ] git config --global user.name e user.email configurados com o e-mail da sua conta do GitHub.
• [ ] Pasta cafe-cerrado/ com index.html, README.md e .gitignore.
• [ ] Repositório cafe-cerrado público no GitHub, com pelo menos dois commits de mensagens legíveis.
• [ ] GitHub Pages ligado e https://SEU-USUARIO.github.io/cafe-cerrado/ abrindo no computador e no celular.
• [ ] Repositório do projeto autoral criado, publicado e com README.md explicando o tema.
• [ ] Tema do projeto autoral definido, com a "lista de coisas" identificada (§1.5).
• [ ] DevTools explorado: você já viu um 200 na aba Network e leu os cabeçalhos de uma resposta.

📚 Para aprofundar¶

• MDN — Visão geral do HTTP: https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Overview — leia a parte de requisições e respostas; é a §3 desta aula com mais detalhe.
• MDN — Métodos de requisição HTTP: https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Methods — foque em GET, POST, PUT e DELETE.
• MDN — Códigos de status HTTP: https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Status — referência para consultar, não para decorar.
• MDN — O que é uma URL: https://developer.mozilla.org/pt-BR/docs/Learn_web_development/Howto/Web_mechanics/What_is_a_URL — complementa a §3.4.
• MDN — Como a Web funciona: https://developer.mozilla.org/pt-BR/docs/Learn_web_development/Getting_started/Web_standards/How_the_web_works — a versão ilustrada da §2.2.
• CHACON, S.; STRAUB, B. Pro Git, 2ª ed., gratuito em português: https://git-scm.com/book/pt-br — capítulos 1 e 2 cobrem tudo da §8; o capítulo "Desfazendo Coisas" salva entregas.
• GitHub Docs — GitHub Pages: https://docs.github.com/pt/pages — configuração, domínio próprio e limites do plano gratuito.
• Node.js — Downloads e releases: https://nodejs.org/pt-br/download — confira o que significa a marca LTS.
• QUEIRÓS, Ricardo; PORTELA, Filipe. Introdução ao Desenvolvimento Moderno para a Web: do front-end ao back-end, uma visão global. FCA, 2018 — capítulo introdutório: evolução e arquitetura da Web.
• ALVES, William P. Projetos de Sistemas Web. Érica, 2015 — conceitos de cliente-servidor e planejamento de projetos web.
• PUREWAL, Semmy. Aprendendo a Desenvolver Aplicações Web. Novatec, 2014 — capítulo 1: o fluxo de trabalho do desenvolvedor.
• LOUDON, Kyle. Desenvolvimento de Grandes Aplicações Web. Novatec, 2019 — leitura de fôlego para quem quer ver onde a arquitetura desta aula escala.

Na próxima aula você entra no lado do cliente: o que o navegador faz com o código depois que a resposta HTTP chega, quem define os padrões da Web, como um site é servido de verdade e como organizar as pastas de um projeto. O index.html mínimo de hoje vira uma página com cabeçalho, navegação, conteúdo principal e rodapé, com uma folha de estilo própria — e cada git push continua publicando tudo sozinho.

Na Aula 01 você acompanhou a requisição saindo do navegador e a resposta voltando do servidor. Hoje a câmera vira para o outro lado: o que acontece depois que a resposta chega — como o navegador transforma texto em pixels, quem decide as regras dessa transformação e como organizar um projeto para que ele funcione tanto na sua máquina quanto em um servidor real.

🎯 Objetivos de aprendizagem¶

Ao final desta aula você será capaz de:

• Situar as fases da Web (estática, social, aplicações) e explicar o que mudou tecnicamente em cada uma.
• Nomear as organizações que mantêm os padrões da Web e explicar o que significa um living standard.
• Explicar como um servidor estático decide o que entregar: convenção index, tipos MIME e caminhos relativos.
• Descrever o pipeline de renderização do navegador (DOM, CSSOM, render tree, layout, paint) e o que bloqueia cada etapa.
• Distinguir o arquivo HTML do DOM e comprovar a diferença no DevTools.
• Escrever a anatomia completa de um documento HTML5 válido, com os landmarks header, nav, main e footer.
• Organizar um projeto front-end em css/, js/ e img/ e escrever uma folha de estilo base com variáveis CSS.

📋 Pré-requisitos¶

Na aula passada você montou o ambiente, aprendeu o ciclo do Git e publicou o Café Cerrado no GitHub Pages com um index.html de oito linhas. Hoje esse arquivo mínimo vira uma página de verdade — com cabeçalho, navegação, conteúdo principal e rodapé — e ganha a primeira folha de estilo do projeto. Cada git push continua republicando o site sozinho.

Checklist antes de começar:

• [ ] VS Code com Live Server e Prettier funcionando; node -v, git --version respondendo no terminal.
• [ ] Repositório cafe-cerrado no GitHub, com pelo menos dois commits e o GitHub Pages ligado.
• [ ] O site em https://SEU-USUARIO.github.io/cafe-cerrado/ abrindo.
• [ ] Repositório do projeto autoral criado, com o tema definido.
• [ ] Do Nível 1: seletores CSS, o modelo de caixa e o que faz um <div>. Se estiver enferrujado, revise antes da Aula 03.

🗺️ Roteiro¶

1. Como a Web chegou até aqui¶

A Web nasceu entre 1989 e 1991, no CERN, das mãos de Tim Berners-Lee, combinando três invenções que continuam sustentando tudo o que você faz hoje: o HTML (a linguagem dos documentos), o HTTP (o protocolo de transporte, que você viu na Aula 01) e a URL (o endereçamento universal). Três coisas simples, encaixadas — e é isso que sobreviveu a três décadas de mudança.

Do ponto de vista técnico, o que muda de uma fase para a outra é onde o HTML é montado e quem tem iniciativa:

• Na Web 1.0, o servidor entrega um arquivo pronto e a conversa acaba.
• Na Web 2.0, o JavaScript passa a fazer requisições em segundo plano e a alterar a página já carregada sem recarregá-la. É o que se chamou de AJAX, e é o assunto da Aula 10.
• Na Web moderna, o servidor muitas vezes entrega só um esqueleto e dados (JSON), e o navegador monta a interface. É a arquitetura SPA — que você vai construir na Unidade 2 e sofisticar no Nível 3.

O Café Cerrado vai atravessar as três fases ao longo do curso, nessa mesma ordem. Hoje ele está firmemente na primeira: arquivos estáticos entregues pelo GitHub Pages.

2. Quem define as regras: padrões abertos¶

A Web é a única plataforma de software relevante que não pertence a ninguém. Nenhuma empresa é dona do HTML. Isso é o que faz o seu site funcionar no Chrome, no Firefox, no Safari do iPhone de outra pessoa, em um leitor de tela e em um navegador que ainda vai ser lançado.

2.1 O que é um living standard¶

O HTML deixou de ter versões. Depois do HTML5, não veio um "HTML6": a especificação virou um documento vivo, atualizado continuamente conforme navegadores implementam e a comunidade valida. Na prática, isso significa três coisas para você:

1. Não existe "meu site é HTML 5.2". Existe HTML, e existe o que os navegadores implementam hoje.
2. A pergunta certa nunca é "isso é padrão?", e sim "isso já funciona nos navegadores que meu público usa?".
3. A documentação de referência precisa ser viva também. Por isso a MDN (https://developer.mozilla.org/pt-BR/) é a fonte desta trilha, e não um livro impresso.

🧠 Você sabia? No começo dos anos 2000 o W3C decidiu abandonar o HTML e apostar no XHTML 2.0, uma linguagem mais rígida e incompatível com o que já existia. Em 2004, gente da Opera, da Mozilla e da Apple discordou publicamente e fundou um grupo paralelo, o WHATWG, para continuar evoluindo o HTML de forma compatível com as páginas existentes. O grupo paralelo ganhou: o trabalho deles virou o HTML5, o XHTML 2.0 foi abandonado, e em 2019 o próprio W3C encerrou sua especificação de HTML e reconheceu o living standard da WHATWG como o documento oficial. A Web escolheu não quebrar o passado — e essa decisão é a razão de uma página de 1995 ainda abrir hoje.

2.2 Consequência prática: escreva para o padrão¶

Escrever "para o Chrome" é uma armadilha antiga e cara. O caminho seguro tem três passos, e você vai repeti-los o semestre inteiro:

1. Consulte a MDN antes de usar algo que você não domina. Cada página tem uma tabela de compatibilidade no final.
2. Valide a marcação no validador do W3C (https://validator.w3.org/). Ele aponta tags não fechadas, atributos inválidos e aninhamentos ilegais que o navegador silenciosamente "conserta" — de formas diferentes em cada navegador.
3. Teste em dois navegadores diferentes, sempre. Chrome e Firefox usam motores distintos (Blink e Gecko).

🔬 Investigue Abra a página da MDN sobre um recurso qualquer de CSS — por exemplo gap (https://developer.mozilla.org/pt-BR/docs/Web/CSS/gap) — e role até o fim. Você vai encontrar uma tabela de compatibilidade com navegadores, com versões e datas de suporte. Agora repita com um recurso recente que você nunca usou (procure :has() na MDN). Compare as duas tabelas e responda: qual dos dois você usaria hoje em um site que precisa funcionar no celular antigo de um cliente? Essa consulta de 30 segundos é o que separa uma decisão técnica de um chute.

3. Como um site é servido¶

Você publicou um site na Aula 01 sem entender exatamente o que o GitHub Pages faz. Vamos abrir essa caixa, porque na Unidade 3 quem vai fazer esse trabalho é o seu próprio código Express.

3.1 A convenção index¶

Um servidor estático faz uma coisa só: mapeia o caminho da URL para um arquivo dentro de uma pasta e devolve o conteúdo. Pedir /cardapio.html entrega o arquivo cardapio.html.

Quando a URL termina em uma pasta (/ ou /promocoes/), não há arquivo nomeado. Aí entra a convenção mais antiga da Web: o servidor procura um arquivo chamado index.html dentro dessa pasta e entrega esse. É por isso que o seu site abre em https://SEU-USUARIO.github.io/cafe-cerrado/ sem você escrever o nome do arquivo.

Se não houver index.html, o servidor faz uma de duas coisas, dependendo da configuração: lista o conteúdo da pasta (directory listing) ou responde 404. O GitHub Pages responde 404.

3.2 Tipos MIME: como o navegador sabe o que recebeu¶

O navegador não decide pela extensão do arquivo. Ele obedece ao cabeçalho Content-Type da resposta, que carrega um tipo MIME:

Isso explica um erro que você vai encontrar mais cedo ou mais tarde. Se o caminho da folha de estilo estiver errado, o servidor responde a página de erro 404 — que é HTML — e o navegador reclama:

Refused to apply style from 'http://127.0.0.1:5500/css/estilo.css' because its MIME
type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking
is enabled.

Traduzindo: "você me mandou HTML e disse que era CSS; não vou aplicar". A causa quase nunca é o MIME em si — é o caminho errado. Verifique na aba Network se o estilo.css voltou com status 200 ou 404.

3.3 Caminhos relativos e absolutos¶

Caminho é a causa da maioria dos "funciona na minha máquina".

O ponto de partida de um caminho relativo é sempre a pasta do arquivo onde o caminho está escrito. E há uma armadilha específica do GitHub Pages: o seu site não fica na raiz do domínio, e sim em https://SEU-USUARIO.github.io/cafe-cerrado/. Um caminho absoluto como /css/estilo.css aponta para https://SEU-USUARIO.github.io/css/estilo.css — fora do seu projeto. Resultado: funciona no Live Server e quebra no site publicado.

⚠️ Atenção Regra desta trilha: use sempre caminhos relativos (css/estilo.css, img/logo.png) enquanto o projeto for publicado em subpasta. E jamais use caminho de disco (C:\Users\...): isso não existe na Web — o servidor só conhece a pasta do site.

3.4 file:// não é a mesma coisa que http://¶

Dar duplo clique em um .html abre a página com o esquema file://, direto do disco, sem servidor nenhum. Parece funcionar — até parar de funcionar:

• Requisições fetch para arquivos locais são bloqueadas por política de segurança (você sentiria isso na Aula 10).
• Módulos ES (<script type="module">) não carregam.
• Caminhos que começam com / apontam para a raiz do disco.
• Nada do que você vê corresponde ao que o servidor real vai entregar.

Por isso a regra: sempre pelo Live Server, mesmo para uma página de uma linha. O botão Go Live sobe um servidor em http://127.0.0.1:5500 e você passa a testar no mesmo esquema em que o site vai viver.

🔎 Por baixo do capô 127.0.0.1 é o endereço de loopback: todo computador o usa para se referir a si mesmo (o apelido é localhost). Quando o Live Server escuta na porta 5500 e o navegador pede http://127.0.0.1:5500/index.html, os pacotes nem chegam à placa de rede — o sistema operacional os devolve internamente. É por isso que funciona sem internet e é instantâneo. E é exatamente o que vai acontecer na Aula 11, quando o servidor na porta 3000 for código seu.

4. O que o navegador faz com o código¶

Recebida a resposta, o navegador executa um pipeline. Entender essas etapas é o que permite explicar por que uma página "pisca", por que ela demora a aparecer e por que um script na posição errada trava tudo.

HTML  ──parsing──>  DOM   ┐
                          ├──> Render Tree ──> Layout ──> Paint ──> Composite
CSS   ──parsing──>  CSSOM ┘
                            ▲
JavaScript ─────────────────┘  (pode alterar DOM e CSSOM a qualquer momento)

1. Parsing do HTML → DOM. O navegador lê o HTML caractere a caractere e monta uma árvore de objetos: o DOM (Document Object Model). Cada tag vira um nó.
2. Parsing do CSS → CSSOM. As regras de estilo viram outra árvore, o CSSOM, com a cascata e a especificidade já resolvidas.
3. Render tree. DOM e CSSOM são combinados, descartando o que não é visível (por exemplo, o que tem display: none).
4. Layout (ou reflow). Cálculo da posição e do tamanho exatos de cada caixa, em pixels.
5. Paint. Preenchimento: cores, textos, bordas, sombras.
6. Composite. Montagem das camadas na tela.

4.1 O que bloqueia o quê¶

Duas regras de ouro, que explicam metade das dúvidas de desempenho:

• CSS bloqueia a renderização. O navegador não pinta nada enquanto não tiver o CSSOM, porque pintar antes causaria um "flash" de página sem estilo. É por isso que a folha de estilo vai no <head> e precisa ser pequena.
• JavaScript bloqueia o parsing. Quando o parser encontra um <script> sem atributos, ele para de montar o DOM, baixa e executa o script, e só então continua. Por isso a boa prática de usar o atributo defer (o script é baixado em paralelo e executado só depois que o DOM estiver pronto) ou de colocar o <script> antes de </body>.

A partir da Unidade 2 todo script do Café Cerrado será carregado com defer. Guarde o motivo agora; você vai medir o efeito no desafio ⭐⭐ desta aula.

4.2 O DOM não é o arquivo¶

Esta é a ideia mais importante da aula, e ela vai reaparecer em todas as aulas da Unidade 2:

• O arquivo .html no disco é texto. Ele nunca muda sozinho.
• O DOM é a árvore em memória que o navegador construiu a partir desse texto. Ele muda o tempo todo.

A aba Elements do DevTools mostra o DOM atual, não o arquivo. É por isso que você pode editar um texto ali, ver a página mudar e, ao recarregar, tudo voltar ao que era: você alterou a memória, não o disco.

🔬 Investigue Abra o seu site publicado e faça três coisas em sequência. (1) Digite view-source:https://SEU-USUARIO.github.io/cafe-cerrado/ na barra de endereço: isso mostra o arquivo, exatamente como veio do servidor. (2) Pressione F12 e vá em Elements: isso é o DOM. Compare — por enquanto são idênticos. (3) No Console, execute document.body.append("Isto não está no arquivo") e pressione Enter. Olhe de novo o Elements (mudou) e o view-source (não mudou). Você acabou de ver, com evidência, a diferença entre o arquivo e o DOM. Recarregue a página e o texto some.

5. O trio fundamental e a separação de responsabilidades¶

O princípio que organiza os três é a separação de responsabilidades: estrutura no .html, estilo no .css, comportamento no .js. Não é preciosismo — é o que permite trocar o visual inteiro sem tocar no conteúdo, reaproveitar uma folha de estilo em vinte páginas e ter duas pessoas trabalhando no mesmo projeto sem se atropelar.

Um exemplo mínimo, completo, com os três arquivos integrados:

exemplo/index.html

<!DOCTYPE html>
<html lang="pt-BR">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Separação de responsabilidades</title>
  <link rel="stylesheet" href="css/estilo.css">
  <script src="js/app.js" defer></script>
</head>
<body>
  <h1>Bem-vindo ao Café Cerrado</h1>
  <button id="botao-saudacao" type="button">Diga olá</button>
  <p id="saida"></p>
</body>
</html>

exemplo/css/estilo.css

h1 {
  color: #6f4e37;
  font-family: system-ui, sans-serif;
}

#botao-saudacao {
  padding: 0.5rem 1rem;
  border: none;
  border-radius: 8px;
  background-color: #6f4e37;
  color: #ffffff;
  cursor: pointer;
}

exemplo/js/app.js

const botao = document.getElementById("botao-saudacao");
const saida = document.getElementById("saida");

botao.addEventListener("click", () => {
  saida.textContent = "Olá! Este texto veio do JavaScript.";
});

Três arquivos, três papéis, uma página. Repare que o <script> está no <head> com defer: o navegador começa a baixar o arquivo cedo, mas só o executa depois que o HTML inteiro virou DOM. Sem o defer, um script no <head> rodaria antes de o <button> existir e document.getElementById devolveria null — e null.addEventListener estoura TypeError. (A outra saída é pôr o <script> sem atributos logo antes de </body>, quando o botão já existe; defer no <head> é a forma preferida porque o download acontece em paralelo com a análise do HTML.) Você vai reencontrar exatamente esse bug na Aula 07 — e agora já sabe o nome dele.

6. Anatomia de um documento HTML5¶

Todo documento desta trilha precisa ter, no mínimo:

Três observações que valem gravar — entram no Marco 1 do projeto:

• lang="pt-BR" não é decoração. É o que faz um leitor de tela pronunciar "pão" como português e não como inglês, e o que informa ao navegador qual dicionário usar na correção ortográfica de campos de formulário.
• Sem <meta name="viewport"> o celular mente. O navegador móvel finge ter 980 px de largura e encolhe a página inteira, deixando o texto ilegível. Essa única linha é o pré-requisito de todo layout responsivo (Aula 04).
• <title> é conteúdo, não enfeite. É o que aparece na aba, no histórico, nos favoritos e como primeiro link no resultado de busca. Escreva algo útil: Cardápio — Café Cerrado, não Documento.

6.1 Os landmarks estruturais¶

Dentro do <body>, quatro elementos definem as regiões da página. São chamados de landmarks porque leitores de tela permitem saltar diretamente entre eles:

O esqueleto típico:

<body>
  <header>
    <p>Nome do site</p>
    <nav aria-label="Navegação principal">
      <ul>
        <li><a href="index.html">Início</a></li>
        <li><a href="cardapio.html">Cardápio</a></li>
      </ul>
    </nav>
  </header>

  <main>
    <h1>Título da página</h1>
    <p>Conteúdo principal.</p>
  </main>

  <footer>
    <p>Rodapé com contato e créditos.</p>
  </footer>
</body>

Um <div> não diz nada sobre o próprio conteúdo; um <nav> declara "isto é a navegação do site". A Aula 03 aprofunda a semântica (section, article, aside, hierarquia de títulos) e a Aula 06 mostra o efeito disso em um leitor de tela. Por hoje, basta o esqueleto — mas ele já entra certo.

💡 Dica O aria-label no <nav> dá nome à região. Uma página com dois <nav> (principal e rodapé) sem rótulo produz, no leitor de tela, duas entradas idênticas chamadas "navegação". Com rótulo, viram "Navegação principal" e "Navegação do rodapé". Custo: um atributo.

7. CSS moderno de base: variáveis, reset e unidades¶

A folha de estilo do projeto começa hoje, e ela começa por três decisões que valem o semestre inteiro.

7.1 Variáveis CSS (custom properties)¶

Uma variável CSS é uma propriedade personalizada, declarada com dois hifens e lida com var():

:root {
  --cor-marca: #6f4e37;
  --espaco-2: 1rem;
}

h1 {
  color: var(--cor-marca);
  margin-bottom: var(--espaco-2);
}

:root é o seletor do elemento raiz (<html>), então tudo declarado ali fica disponível na página inteira. Três motivos para começar assim:

1. Um lugar só para mudar. Trocar a paleta do site inteiro vira uma edição de cinco linhas.
2. Elas são vivas. Diferente das variáveis de pré-processadores (Sass, Less), que somem na compilação, as variáveis CSS existem em tempo de execução: o navegador as resolve na hora, elas respeitam a cascata e o JavaScript pode alterá-las com document.documentElement.style.setProperty('--cor-marca', '#c2703d'). É assim que se faz um seletor de tema claro/escuro sem recarregar a página.
3. Elas documentam a intenção. var(--cor-marca) diz mais do que #6f4e37.

⚠️ Atenção Os dois hifens fazem parte do nome. --cor-marca declara; var(--cor-marca) lê. Escrever var(cor-marca) ou color: --cor-marca não dá erro visível: o navegador simplesmente ignora a declaração inválida e você fica olhando para uma cor que não mudou. Quando isso acontecer, abra o DevTools → Elements → aba Styles: a declaração inválida aparece riscada.

7.2 Um reset mínimo¶

Cada navegador aplica uma folha de estilo própria antes da sua. Um reset mínimo elimina as diferenças que mais incomodam:

*,
*::before,
*::after {
  box-sizing: border-box;
}

body {
  margin: 0;
}

img {
  max-width: 100%;
  height: auto;
  display: block;
}

box-sizing: border-box faz com que width inclua padding e borda — o comportamento que todo mundo espera e que o padrão original não tem. body { margin: 0 } remove a margem de 8 px que os navegadores aplicam por conta própria. E as três linhas de img impedem que uma foto grande estoure o layout no celular.

7.3 Unidades relativas¶

Use rem como padrão. O motivo é de acessibilidade: quem aumenta o tamanho de fonte nas configurações do navegador — e isso é comum — vê o layout inteiro acompanhar. Layout medido em px ignora essa preferência.

💻 Mão na massa — o Café Cerrado ganha estrutura¶

Hoje o index.html de oito linhas vira uma página com landmarks, o projeto ganha as pastas que vai usar até o fim do semestre e nasce a folha de estilo base.

Passo 1 — As pastas do projeto¶

Na raiz de cafe-cerrado, crie as pastas css/, js/ e img/. A estrutura fica assim:

cafe-cerrado/
├── index.html          # página inicial (a convenção da §3.1)
├── README.md
├── .gitignore
├── css/
│   └── estilo.css
├── js/
│   └── .gitkeep
└── img/
    └── .gitkeep

O .gitkeep é um arquivo vazio com um propósito curioso: o Git não versiona pastas, só arquivos. Uma pasta vazia simplesmente não existe para ele. Colocar um arquivo vazio dentro dela é a convenção usada para que a estrutura chegue ao repositório. js/ e img/ ganham conteúdo real nas próximas aulas.

Regras de nomenclatura, que valem para o semestre inteiro: minúsculas, sem espaços, sem acentos, hífen separando palavras (sobre-nos.html, nunca Sobre Nós.html). O servidor do GitHub Pages roda Linux e diferencia maiúsculas de minúsculas.

Passo 2 — A folha de estilo base¶

cafe-cerrado/css/estilo.css

/* Café Cerrado — folha de estilo base
   Variáveis do projeto, reset mínimo e estilos das regiões da página. */

/* ---------- 1. Variáveis do projeto ---------- */
:root {
  --cor-marca: #6f4e37;
  --cor-marca-escura: #4a3325;
  --cor-destaque: #c2703d;
  --cor-fundo: #fdfaf6;
  --cor-superficie: #ffffff;
  --cor-texto: #2b2118;
  --cor-texto-suave: #5c4b3c;
  --borda-suave: rgba(111, 78, 55, 0.15);

  --fonte-base: system-ui, -apple-system, "Segoe UI", Roboto, Arial, sans-serif;

  --espaco-1: 0.5rem;
  --espaco-2: 1rem;
  --espaco-3: 2rem;
  --espaco-4: 4rem;

  --largura-maxima: 60rem;
  --raio: 8px;
}

/* ---------- 2. Reset mínimo ---------- */
*,
*::before,
*::after {
  box-sizing: border-box;
}

body {
  margin: 0;
  font-family: var(--fonte-base);
  font-size: 1rem;
  line-height: 1.6;
  color: var(--cor-texto);
  background-color: var(--cor-fundo);
}

img {
  max-width: 100%;
  height: auto;
  display: block;
}

a {
  color: var(--cor-marca);
}

/* ---------- 3. Cabeçalho e navegação ---------- */
.cabecalho {
  display: flex;
  flex-wrap: wrap;
  gap: var(--espaco-2);
  align-items: center;
  justify-content: space-between;
  padding: var(--espaco-2) var(--espaco-3);
  background-color: var(--cor-marca);
  color: var(--cor-superficie);
}

.marca {
  margin: 0;
  font-size: 1.25rem;
  font-weight: 700;
  letter-spacing: 0.02em;
}

.navegacao ul {
  display: flex;
  gap: var(--espaco-2);
  margin: 0;
  padding: 0;
  list-style: none;
}

.navegacao a {
  color: var(--cor-superficie);
  text-decoration: none;
  padding: var(--espaco-1);
}

.navegacao a:hover,
.navegacao a:focus {
  text-decoration: underline;
}

/* ---------- 4. Conteúdo principal ---------- */
main {
  max-width: var(--largura-maxima);
  margin: 0 auto;
  padding: var(--espaco-3) var(--espaco-2);
}

.destaque {
  padding: var(--espaco-4) var(--espaco-3);
  border-radius: var(--raio);
  background-color: var(--cor-superficie);
  border: 1px solid var(--borda-suave);
  text-align: center;
}

.destaque h1 {
  margin-top: 0;
  color: var(--cor-marca-escura);
  font-size: 2.25rem;
}

.destaque p {
  color: var(--cor-texto-suave);
  max-width: 40rem;
  margin-left: auto;
  margin-right: auto;
}

.botao {
  display: inline-block;
  margin-top: var(--espaco-2);
  padding: var(--espaco-1) var(--espaco-3);
  border-radius: var(--raio);
  background-color: var(--cor-destaque);
  color: var(--cor-superficie);
  text-decoration: none;
  font-weight: 600;
}

.botao:hover,
.botao:focus {
  background-color: var(--cor-marca);
}

.sobre {
  margin-top: var(--espaco-4);
}

.sobre h2 {
  color: var(--cor-marca-escura);
}

/* ---------- 5. Rodapé ---------- */
.rodape {
  margin-top: var(--espaco-4);
  padding: var(--espaco-3) var(--espaco-2);
  background-color: var(--cor-marca-escura);
  color: var(--cor-superficie);
  text-align: center;
}

.rodape p {
  margin: var(--espaco-1) 0;
  font-size: 0.9rem;
}

Passo 3 — A página inicial com landmarks¶

Substitua o conteúdo de index.html por este. Digite, não cole — e repare em cada tag nova.

cafe-cerrado/index.html

<!DOCTYPE html>
<html lang="pt-BR">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta name="description" content="Café Cerrado: cafeteria de grãos torrados do cerrado mato-grossense, em Sinop/MT.">
  <title>Café Cerrado — cafeteria em Sinop/MT</title>
  <link rel="stylesheet" href="css/estilo.css">
</head>
<body>
  <header class="cabecalho">
    <p class="marca">Café Cerrado</p>

    <nav class="navegacao" aria-label="Navegação principal">
      <ul>
        <li><a href="index.html">Início</a></li>
        <li><a href="cardapio.html">Cardápio</a></li>
        <li><a href="contato.html">Contato</a></li>
      </ul>
    </nav>
  </header>

  <main>
    <section class="destaque">
      <h1>Café que nasce no cerrado</h1>
      <p>
        Torramos em Sinop grãos colhidos na Chapada dos Parecis e no médio-norte
        de Mato Grosso. Cada lote tem origem, data de torra e ficha de sabor.
      </p>
      <a class="botao" href="cardapio.html">Ver o cardápio</a>
    </section>

    <section class="sobre">
      <h2>A casa</h2>
      <p>
        Somos uma cafeteria de bairro com torrefação própria. Servimos espresso,
        métodos filtrados e uma pequena confeitaria feita no dia.
      </p>
      <p>
        Funcionamos de terça a sábado, das 8h às 19h, na Avenida dos
        Jacarandás, 1200, no Setor Comercial de Sinop.
      </p>
    </section>
  </main>

  <footer class="rodape">
    <p>Café Cerrado — Avenida dos Jacarandás, 1200, Sinop/MT</p>
    <p>Projeto do Nível 2 do WebLab — Desenvolvimento Web.</p>
  </footer>
</body>
</html>

Os links para cardapio.html e contato.html ainda apontam para páginas que não existem: clicar neles produz um 404. Isso é intencional — as duas páginas nascem na Aula 03, e ver o 404 acontecer é uma boa oportunidade para reler a §3.1.

Passo 4 — Ver funcionando e ler a rede¶

Abra com o Live Server (Go Live) e confira:

1. O cabeçalho marrom, com a navegação alinhada à direita.
2. O bloco de destaque centralizado, com o botão laranja.
3. O rodapé escuro no fim da página.

Agora abra o DevTools na aba Network e recarregue com Ctrl+F5. Você deve ver duas requisições: index.html e estilo.css. Clique em estilo.css e confirme, nos cabeçalhos de resposta, Content-Type: text/css — exatamente o que a §3.2 previu.

Passo 5 — Provar que o CSS bloqueia a renderização¶

Um experimento de 30 segundos que fixa a §4.1. No DevTools, aba Network, mude o seletor de velocidade de No throttling para Slow 4G e recarregue. Observe a ordem: o HTML chega, mas a página só aparece pintada quando o CSS termina de baixar.

Agora troque a linha do <link> de lugar: mova-a do <head> para logo antes de </body>, salve e recarregue com a mesma simulação de rede lenta. Você vai ver a página aparecer sem estilo por um instante e depois "pular" para o visual correto. Isso se chama FOUC (flash of unstyled content), e é a razão de a folha de estilo ficar no <head>. Desfaça a alteração e volte o <link> para o <head>.

Passo 6 — Validar a marcação¶

Acesse https://validator.w3.org/nu/, escolha a aba Validate by Direct Input, cole o conteúdo do seu index.html e clique em Check. A meta é: zero erros. Avisos (warnings) merecem leitura, mas nem todos exigem ação.

Se aparecer algo, o validador diz a linha e o motivo. Os erros mais comuns nesta etapa são tag não fechada, atributo escrito errado e <li> fora de <ul>.

Passo 7 — Commit e republicação¶

git status
git add .
git commit -m "Estrutura a pagina inicial com landmarks e folha de estilo base"
git push

Espere um a três minutos e recarregue https://SEU-USUARIO.github.io/cafe-cerrado/. O site publicado agora tem o mesmo visual da sua máquina.

⚠️ Atenção Se o site publicado aparecer sem estilo, o problema quase sempre é caminho: você escreveu /css/estilo.css (absoluto) em vez de css/estilo.css (relativo). Confirme na aba Network do site publicado: se estilo.css voltou 404, é isso. A §3.3 explica por quê.

Passo 8 — O projeto autoral acompanha¶

Repita os passos 1 a 7 no repositório do seu projeto autoral, com o seu tema: mesmas pastas, mesmos landmarks, sua paleta de variáveis, seu conteúdo. Não copie os textos do Café Cerrado — copie a estrutura.

Como testar¶

• A aba Network mostra index.html e estilo.css, ambos com status 200.
• estilo.css responde com Content-Type: text/css.
• O validador do W3C aponta zero erros.
• No DevTools → Elements → Styles, clicar em var(--cor-marca) mostra o valor #6f4e37 resolvido.
• Reduzir a janela para 400 px de largura não gera barra de rolagem horizontal.
• O site publicado no GitHub Pages tem o mesmo visual da máquina local.

Resultado esperado: o Café Cerrado com estrutura semântica, folha de estilo baseada em variáveis, pastas organizadas e tudo isso no ar, atualizado por um git push.

🧪 Laboratório¶

Nível A — Fixação¶

A1. Explique, em duas frases, a diferença entre o arquivo index.html e o DOM. Cite a aba do DevTools que mostra cada um.

A2. Um servidor recebe a requisição GET /promocoes/. Não existe arquivo com esse nome. O que ele procura, e o que responde se não encontrar?

A3. Ordene as etapas do pipeline de renderização: paint, parsing do HTML, layout, render tree, parsing do CSS, composite.

A4. O que acontece com a página se você remover a linha <meta name="viewport" content="width=device-width, initial-scale=1.0"> e abrir no celular? E se remover <meta charset="UTF-8">?

A5. Qual a diferença entre css/estilo.css e /css/estilo.css? Em qual dos dois cenários o segundo quebra?

A6. Complete o código para que a cor de fundo do botão venha de uma variável chamada --cor-destaque:

:root {
  --cor-destaque: #c2703d;
}

.botao {
  background-color: ;
}

A7. Diga o papel de cada landmark: <header>, <nav>, <main>, <footer>. Qual deles pode aparecer só uma vez por página?

A8. Por que um <script> sem atributos, colocado no <head>, atrasa a exibição da página? Cite dois jeitos de resolver.

A9. Cite as quatro organizações da §2 e o que cada uma padroniza.

A10. O navegador respondeu com este erro no Console. Diga a causa mais provável e como confirmar em dez segundos:

Refused to apply style from 'http://127.0.0.1:5500/css/estilo.css' because its MIME
type ('text/html') is not a supported stylesheet MIME type.

A11. Qual a diferença entre rem e em? Por que esta trilha prefere rem para espaçamentos?

A12. O Git não versiona pastas vazias. Qual é a convenção usada no Mão na massa para contornar isso, e por que ela funciona?

Nível B — Aplicação¶

B1. Crie a página sobre.html no Café Cerrado, reaproveitando o mesmo cabeçalho, a mesma navegação e o mesmo rodapé do index.html, com um <main> contendo um <h1> e três parágrafos sobre a história da cafeteria. Acrescente o link "Sobre" à navegação das duas páginas.

Resultado esperado: as duas páginas navegam entre si nos dois sentidos, com o mesmo visual, e o validador do W3C aponta zero erros em ambas.

B2. Troque a identidade visual do Café Cerrado alterando apenas o bloco :root do estilo.css: transforme a paleta marrom em uma paleta verde (ou a que você preferir), mantendo contraste legível entre texto e fundo. Nenhuma outra regra do arquivo pode ser modificada.

Resultado esperado: o site inteiro muda de cor com a edição de um único bloco; nenhuma cor literal (#rrggbb) aparece fora do :root.

B3. Meça o efeito do CSS bloqueante. Na aba Network, com Slow 4G ativado, registre o tempo até a página aparecer pintada em três cenários: (a) <link> no <head>, como está; (b) <link> antes de </body>; (c) <link> no <head> mas com o CSS colado dentro de uma tag <style> no próprio HTML. Escreva um parágrafo comparando os três.

Resultado esperado: três medidas anotadas com o critério de medição declarado, mais uma conclusão sobre qual cenário é melhor e por quê.

B4. Escreva uma variação do estilo.css que respeite o tema escuro do sistema operacional, sem duplicar nenhuma regra: dentro de @media (prefers-color-scheme: dark), redefina apenas as variáveis do :root.

Resultado esperado: alternar o tema do sistema entre claro e escuro muda o site inteiro; o bloco @media contém somente declarações de variáveis.

B5. Investigue a diferença entre file:// e http:// na prática. Abra o index.html das duas formas (duplo clique no arquivo e pelo Live Server) e compare, em uma tabela: o que aparece na barra de endereço, o que a aba Network mostra em cada caso, e o valor de window.location.protocol no Console.

Resultado esperado: uma tabela com três linhas de comparação e um parágrafo explicando por que esta trilha exige o uso do Live Server.

Nível C — Desafio¶

C1. Reproduza uma página real. Escolha a página inicial de uma cafeteria ou restaurante que você conheça, abra o DevTools e identifique: quais landmarks ela usa (ou deixa de usar), quantas requisições faz, qual o peso total e quantas fontes externas carrega. Depois reescreva o esqueleto dessa página — só a estrutura HTML com os landmarks corretos, sem copiar textos nem imagens — em um arquivo exercicios/aula02/estrutura-analisada.html, e escreva cinco linhas apontando o que você faria diferente.

C2. Sirva o seu site sem o Live Server. Usando o Node.js já instalado, suba um servidor estático na pasta do projeto (por exemplo com npx serve ou com o módulo http do Node) e acesse pelo endereço que ele indicar. Depois responda, com evidência da aba Network: qual Content-Type ele devolve para o HTML e para o CSS, o que acontece ao pedir um arquivo inexistente e o que acontece ao pedir a pasta raiz.

🏆 Desafios¶

🐛 Erros comuns¶

🏠 Para praticar depois da aula (1 h)¶

Parte 1 — Estrutura do projeto autoral (35 min). No repositório do seu projeto:

1. Crie as pastas css/, js/ e img/, com .gitkeep nas duas últimas.
2. Reescreva o index.html com a anatomia completa (doctype, lang, charset, viewport, description, title) e os quatro landmarks: header com nav, main com um <h1> e pelo menos duas <section>, e footer.
3. Crie css/estilo.css com, no mínimo, oito variáveis no :root, o reset da §7.2 e estilos para cabeçalho, conteúdo e rodapé. Nenhuma cor literal fora do :root.
4. Crie a segunda página sobre.html, com a mesma estrutura e navegação funcionando nos dois sentidos.
5. Valide as duas páginas em https://validator.w3.org/nu/ até zerar os erros.

Parte 2 — Publicação (15 min). Commit com mensagem descritiva, push e verificação do site publicado. Abra o site publicado no celular e confira que não há rolagem horizontal.

Parte 3 — Leitura dirigida (10 min). Se você tem acesso a uma biblioteca virtual pela sua instituição: QUEIRÓS & PORTELA, capítulos sobre a evolução da Web e a camada de estrutura (HTML); PUREWAL, capítulos 1 e 2, sobre fluxo de trabalho e primeiras páginas. Anote duas diferenças entre o que os livros descrevem e o que você fez hoje.

Critério de pronto: as duas páginas do projeto autoral abrem no site publicado, navegam entre si, passam no validador sem erros e usam variáveis CSS para todas as cores.

Guarde no seu repositório: commit + push, com o site publicado atualizado. Sem .zip.

✅ Checkpoint do projeto¶

Ao fim desta aula, o repositório cafe-cerrado e o do seu projeto autoral devem ter:

• [ ] Pastas css/, js/ e img/ versionadas (as duas últimas com .gitkeep).
• [ ] index.html com doctype, lang="pt-BR", charset, viewport, description, title e <link> para a folha de estilo.
• [ ] Os quatro landmarks no lugar: header (com nav rotulado), main único, footer.
• [ ] css/estilo.css com bloco :root de variáveis, reset mínimo e estilos das regiões.
• [ ] Nenhuma cor literal fora do :root.
• [ ] Zero erros no validador do W3C.
• [ ] Aba Network mostrando index.html e estilo.css com status 200 e tipos MIME corretos.
• [ ] Site publicado no GitHub Pages com o mesmo visual da máquina local, sem rolagem horizontal no celular.
• [ ] Commit com mensagem descritiva enviado com git push.

📚 Para aprofundar¶

• MDN — Introdução ao HTML: https://developer.mozilla.org/pt-BR/docs/Learn_web_development/Core/Structuring_content — leia "Começando com HTML" e "O que há na cabeça".
• MDN — Estruturando um documento: https://developer.mozilla.org/pt-BR/docs/Learn_web_development/Core/Structuring_content/Structuring_documents — a referência dos landmarks da §6.1.
• MDN — Usando propriedades personalizadas (variáveis CSS): https://developer.mozilla.org/pt-BR/docs/Web/CSS/Using_CSS_custom_properties — a fonte da §7.1.
• MDN — Tipos MIME comuns: https://developer.mozilla.org/pt-BR/docs/Web/HTTP/MIME_types/Common_types — a tabela completa da §3.2.
• MDN — prefers-color-scheme: https://developer.mozilla.org/pt-BR/docs/Web/CSS/@media/prefers-color-scheme — base para o desafio ⭐.
• web.dev — Critical rendering path: https://web.dev/learn/performance/understanding-the-critical-path — a §4 com muito mais detalhe (em inglês).
• WHATWG — HTML Living Standard: https://html.spec.whatwg.org/ — a especificação viva citada na §2.1; abra uma vez para saber que ela existe.
• Validador do W3C: https://validator.w3.org/nu/ — use antes de cada entrega, não depois.
• QUEIRÓS, Ricardo; PORTELA, Filipe. Introdução ao Desenvolvimento Moderno para a Web. FCA, 2018 — evolução da Web e camada de estrutura.
• PUREWAL, Semmy. Aprendendo a Desenvolver Aplicações Web. Novatec, 2014 — capítulos 1 e 2: fluxo de trabalho e primeiras páginas.
• ALVES, William P. Projetos de Sistemas Web. Érica, 2015 — organização de projetos e estrutura de sites.

Na próxima aula o HTML entra em profundidade: hierarquia de títulos, listas, tabelas, imagens com figure, links em todas as suas formas e formulários com validação nativa. O Café Cerrado ganha as duas páginas que hoje respondem 404 — cardapio.html, com os produtos organizados em tabelas e listas, e contato.html, com um formulário completo — e o menu passa a indicar em qual página você está.

🎯 Objetivos de aprendizagem¶

Ao final desta aula você será capaz de:

• Escolher a tag correta para cada trecho de conteúdo e justificar a escolha pelos três benefícios da semântica: acessibilidade, indexação e manutenção.
• Montar o esqueleto de uma página com os landmarks header, nav, main, section, article, aside e footer, e explicar o que cada um significa para um leitor de tela.
• Estruturar conteúdo com listas (ul, ol, dl), imagens com alt descritivo, figure/figcaption e tabelas de dados com caption, thead, tbody e th scope.
• Usar links em todas as suas formas — página interna, âncora, URL absoluta, mailto:, tel:, download — e escrever textos de link que fazem sentido fora do contexto.
• Construir um formulário completo com os tipos de campo do HTML5, label para cada controle, agrupamento com fieldset/legend e validação nativa (required, pattern, minlength, min/max).
• Explicar por que a validação do navegador nunca substitui a validação no servidor, e onde cada camada entra no Café Cerrado.
• Validar o HTML no W3C e corrigir os erros mais comuns lendo a mensagem do validador.

📋 Pré-requisitos¶

• [ ] Repositório cafe-cerrado clonado na máquina, com index.html, README.md, e as pastas css/, js/ e img/ criadas na Aula 02.
• [ ] css/estilo.css já ligado ao index.html por <link rel="stylesheet" href="css/estilo.css">.
• [ ] GitHub Pages ativo no repositório (Aula 01) e o endereço público anotado no README.md.
• [ ] VS Code com a extensão Live Server e um navegador com DevTools (Chrome ou Firefox).
• [ ] Git configurado com o seu nome e e-mail (git config --global user.name, git config --global user.email).

Na aula passada você viu o caminho completo de uma requisição — do Enter na barra de endereços até o paint na tela — escreveu a anatomia mínima de um documento HTML5 válido e organizou o repositório do Café Cerrado em css/, js/ e img/. O index.html funciona, mas ainda é um esqueleto de uma página só. Hoje ele vira um site: três páginas ligadas entre si, com estrutura semântica de verdade, um cardápio com listas e tabela e um formulário de contato que o navegador valida sozinho.

🗺️ Roteiro¶

1. Semântica: a tag certa não é detalhe¶

1.1 O problema que a div não resolve¶

Considere dois trechos que produzem exatamente a mesma imagem na tela:

<div class="topo">
  <div class="titulo">Café Cerrado</div>
  <div class="menu">
    <div><a href="index.html">Início</a></div>
    <div><a href="cardapio.html">Cardápio</a></div>
  </div>
</div>

<header>
  <h1>Café Cerrado</h1>
  <nav>
    <ul>
      <li><a href="index.html">Início</a></li>
      <li><a href="cardapio.html">Cardápio</a></li>
    </ul>
  </nav>
</header>

Para quem enxerga a página com CSS aplicado, os dois são idênticos. Para todo o resto do mundo, não: o primeiro é uma pilha de caixas anônimas; o segundo declara "isto é o cabeçalho", "isto é o título principal", "isto é a navegação", "isto é uma lista de dois itens".

Semântica é significado. Uma <div> não diz nada sobre o seu conteúdo — o nome vem de division, divisão. Um <nav> diz: este bloco é a navegação do site. Essa diferença rende três benefícios concretos:

1. Acessibilidade. Leitores de tela constroem, a partir do HTML, uma lista de regiões da página. Quem usa NVDA, VoiceOver ou TalkBack pressiona uma tecla e pula direto para a navegação, ou direto para o conteúdo principal. Com div, essa lista sai vazia e a pessoa precisa percorrer a página inteira, elemento por elemento.
2. Indexação. Buscadores usam a estrutura para decidir o que é conteúdo e o que é enfeite. Um <h1> dentro de <main> pesa mais do que um texto grande dentro de um <div> do rodapé.
3. Manutenção. O código se autodocumenta. Você abre um arquivo de 400 linhas escrito há seis meses e encontra o rodapé procurando por <footer> — não por class="bottom-area-2".

🧠 Você sabia? As tags semânticas do HTML5 não foram inventadas no vácuo. Em 2005 o Google analisou mais de um bilhão de páginas para descobrir quais nomes de classe as pessoas mais usavam em <div>. O ranking foi dominado por footer, menu, nav, header, content, main e sidebar — exatamente os nomes que viraram tags no HTML5. Em outras palavras: a especificação não impôs uma estrutura, ela oficializou a estrutura que a comunidade já usava na mão. Quando você escreve <footer> hoje, está usando um padrão que nasceu de um levantamento estatístico do que os desenvolvedores já faziam.

1.2 O inventário de tags estruturais¶

Três dúvidas aparecem sempre:

section ou article? O teste: o conteúdo faria sentido sozinho, publicado fora desta página (num feed RSS, num resultado de busca, num aplicativo agregador)? Se sim, é article. Um card de produto do cardápio é um article; a seção "Nossa história" da página inicial é uma section. Na dúvida entre os dois, prefira section — ela é o contêiner temático genérico.

section ou div? Toda section deveria ter um título (h2, h3) que a nomeia. Se você não consegue escrever um título para o bloco, provavelmente ele não é uma seção temática: é um agrupamento visual, e aí div é a tag honesta.

header só um por página? Não. <header> é o cabeçalho de qualquer coisa: da página, de um <article>, de uma <section>. O que é único por página é o <main>.

1.3 Landmarks: o mapa que o leitor de tela enxerga¶

Cinco tags viram automaticamente landmarks (marcos) na árvore de acessibilidade:

Repare no detalhe entre parênteses: <header> e <footer> só viram landmarks quando são filhos diretos do <body>. Um <header> dentro de um <article> é apenas o cabeçalho daquele artigo — o que é correto e desejado.

Quando a página tem mais de uma navegação, cada <nav> precisa de um rótulo, senão o usuário ouve "navegação", "navegação", "navegação" e não sabe qual é qual:

<nav aria-label="Principal">
  <ul>
    <li><a href="index.html">Início</a></li>
    <li><a href="cardapio.html">Cardápio</a></li>
  </ul>
</nav>

<nav aria-label="Rodapé">
  <ul>
    <li><a href="#politica">Política de privacidade</a></li>
  </ul>
</nav>

O aria-label é um dos poucos atributos ARIA que você vai usar hoje. A aula de Acessibilidade e ARIA aprofunda o assunto; por enquanto, guarde a regra: rotule toda navegação quando houver mais de uma.

🔬 Investigue Abra qualquer site grande (um portal de notícias, o site da sua universidade ou escola) e pressione F12. No Chrome, vá em Elements e, no painel da direita, abra a aba Accessibility; no Firefox, use a aba Acessibilidade e ative "Mostrar tabulações". Procure a árvore de acessibilidade e conte quantos landmarks a página tem. Depois abra o seu index.html do Café Cerrado e faça a mesma contagem. Anote a diferença — no fim desta aula, refaça o teste na sua página e compare com o número de agora.

1.4 Hierarquia de títulos: estrutura, não tamanho¶

<h1> a <h6> formam o sumário da página, como os capítulos e seções de um livro. Regras:

• Um único <h1> por página, dizendo do que a página trata.
• <h2> para as seções principais, <h3> para subseções — sem pular níveis (nunca h2 direto para h4).
• Tamanho de fonte é problema do CSS. Se um <h2> está grande demais, mude o CSS; não troque para <h4>.

Um <h1> mal escolhido custa caro: leitores de tela oferecem "listar todos os títulos" como forma rápida de entender a página. Se a lista sai como h1: Café Cerrado, h3: Cafés, h5: Espresso, o usuário conclui que faltam níveis — e não faltam, é só desleixo.

Sumário correto de cardapio.html:

h1  Cardápio
├── h2  Cafés
│   ├── h3  Espresso do Cerrado
│   ├── h3  Coado da Casa
│   └── h3  Cappuccino Sinop
├── h2  Bebidas geladas
│   ├── h3  Cold Brew da Chapada
│   └── h3  Frappê de Café
├── h2  Salgados
└── h2  Doces

📌 Vale gravar Duas confusões comuns: (a) "pode haver mais de um <h1> por página" — na prática deste material, não: um por página; (b) "<h1> é o texto maior da página" — falso, h1 é o título mais importante, e o tamanho é decisão do CSS.

1.5 Quando div e span ainda são a resposta certa¶

Semântica não é uma corrida para eliminar div. Ela continua sendo a ferramenta correta quando o agrupamento existe só para o layout: um contêiner que centraliza o conteúdo, uma linha do grid, um invólucro para aplicar um fundo. O mesmo vale para <span>, o contêiner genérico em linha.

<footer>
  <div class="container">
    <p>Café Cerrado — Avenida dos Jacarandás, 1200, Sinop, MT</p>
    <p>Preço a partir de <span class="destaque">R$ 6,00</span></p>
  </div>
</footer>

Aqui div.container existe para o CSS limitar a largura e centralizar; span.destaque existe para colorir um pedaço de texto. Nenhum dos dois carrega significado — e está certo assim. O erro é o inverso: usar div onde existe uma tag com significado.

2. Conteúdo: listas, imagens e tabelas¶

2.1 Listas: três tipos, três significados¶

<!-- Lista não ordenada: a ordem não importa -->
<ul>
  <li>Wi-Fi liberado</li>
  <li>Tomadas em todas as mesas</li>
  <li>Espaço para estudo</li>
</ul>

<!-- Lista ordenada: a ordem importa -->
<ol>
  <li>Escolha os grãos no balcão</li>
  <li>Peça a moagem na hora</li>
  <li>Retire o café no guichê</li>
</ol>

<!-- Lista de definições: pares termo/descrição -->
<dl>
  <dt>Torra clara</dt>
  <dd>Realça a acidez e as notas frutadas do grão.</dd>
  <dt>Torra média</dt>
  <dd>Equilibra doçura, corpo e acidez. É a nossa torra padrão.</dd>
  <dt>Torra escura</dt>
  <dd>Mais amarga e encorpada, com notas de chocolate amargo.</dd>
</dl>

A <dl> (description list) é subutilizada e resolve muito bem glossários, especificações e — no nosso caso — a descrição das torras. Cada <dt> é um termo; cada <dd>, a descrição correspondente. Um <dt> pode ter vários <dd> e vice-versa.

Listas também são a base semântica de menus: um menu é uma lista de links. O leitor de tela anuncia "lista com 4 itens" ao entrar no <nav> — o usuário sabe o tamanho da navegação antes de percorrê-la.

2.2 Imagens: alt é obrigatório, e não é opcional¶

<img src="img/fachada.jpg"
     alt="Fachada do Café Cerrado com toldo verde e mesas na calçada"
     width="1200" height="800">

Quatro atributos que valem nota:

• src — o caminho do arquivo, relativo à página (seção 3.1).
• alt — o texto alternativo. Descreve a imagem para quem não a vê: leitores de tela, buscadores e o próprio navegador quando o arquivo falha. É obrigatório.
• width/height — as dimensões reais do arquivo, em pixels e sem unidade. Não servem para redimensionar (isso é papel do CSS): servem para o navegador reservar o espaço antes de a imagem carregar, evitando que o texto "pule" na tela.
• loading="lazy" — opcional; adia o download de imagens que estão fora da tela. Use em galerias longas, nunca na imagem principal do topo.

Como escrever um bom alt: descreva o que a imagem comunica naquele contexto, em uma frase, sem começar com "imagem de" (o leitor de tela já anuncia que é uma imagem).

O alt="" merece explicação: um alt vazio diz ao leitor de tela "ignore esta imagem, ela não acrescenta informação". Já omitir o atributo faz o leitor anunciar o nome do arquivo — e ouvir "i-m-g-underline-2-0-2-4-underline-final-ponto-jpg" é pior do que ouvir nada.

⚠️ Atenção Se a imagem está dentro de um link e é o único conteúdo dele, o alt deixa de descrever a imagem e passa a descrever o destino do link. Um logo clicável tem alt="Café Cerrado — página inicial", não alt="Logo". Quem navega por leitor de tela ouve o alt como se fosse o texto do link.

2.3 figure e figcaption: imagem com legenda¶

<figure>
  <img src="img/grao-cerrado.jpg"
       alt="Grãos de café verdes sendo peneirados em uma bandeja de metal"
       width="1000" height="667">
  <figcaption>
    Grãos do Cerrado mato-grossense recém-beneficiados, antes da torra.
  </figcaption>
</figure>

<figure> agrupa um conteúdo autocontido (imagem, trecho de código, tabela, vídeo) com sua legenda, e o <figcaption> é a legenda — que deve ser o primeiro ou o último filho da <figure>.

A diferença entre alt e figcaption confunde: o alt descreve a imagem para quem não a vê; o figcaption comenta a imagem para todo mundo. Eles não devem repetir um ao outro. No exemplo acima, o alt diz o que aparece na foto; a legenda diz de onde vieram os grãos.

2.4 Tabelas de dados — nunca para layout¶

Tabela serve para dados tabulares: informação que faz sentido em linhas e colunas. Layout é problema de CSS (Flexbox e Grid, que você estudou no Nível 1). Uma tabela usada para layout destrói a leitura em leitor de tela, que anuncia "linha 3, coluna 2" para cada pedaço da página.

<table>
  <caption>Horário de atendimento do Café Cerrado</caption>
  <thead>
    <tr>
      <th scope="col">Dia</th>
      <th scope="col">Abertura</th>
      <th scope="col">Fechamento</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Segunda a sexta</th>
      <td>07h00</td>
      <td>20h00</td>
    </tr>
    <tr>
      <th scope="row">Sábado</th>
      <td>08h00</td>
      <td>18h00</td>
    </tr>
    <tr>
      <th scope="row">Domingo</th>
      <td colspan="2">Fechado</td>
    </tr>
  </tbody>
</table>

Os elementos que fazem a tabela ser acessível:

• <caption> — o título da tabela, primeiro filho de <table>. Anunciado pelo leitor de tela ao entrar na tabela.
• <thead> / <tbody> / <tfoot> — separam cabeçalho, corpo e rodapé. Permitem que o navegador repita o cabeçalho ao imprimir e que o CSS fixe o cabeçalho ao rolar.
• <th> com scope — scope="col" diz "sou o cabeçalho desta coluna"; scope="row", "sou o cabeçalho desta linha". É isso que faz o leitor de tela anunciar "Sábado, Abertura: 08h00" em vez de só "08h00".
• colspan / rowspan — mesclagem de células. Use com parcimônia: tabelas muito mescladas ficam impossíveis de navegar.

💡 Dica Tabelas largas estouram a tela do celular. A solução de uma linha: envolva a <table> em uma <div class="tabela-rolavel"> com overflow-x: auto no CSS. A tabela rola sozinha no eixo horizontal em vez de esticar a página inteira. Você vai usar exatamente isso no cardapio.html.

3. Links: a essência do hipertexto¶

3.1 Caminhos relativos e absolutos¶

Antes das formas de link, o assunto que mais gera erro 404 em trabalho de aluno: como escrever o caminho.

A armadilha clássica: caminhos que começam com / são absolutos em relação ao domínio, não ao seu projeto. Se você escreve /img/logo.svg e publica em https://seuusuario.github.io/cafe-cerrado/, o navegador procura em https://seuusuario.github.io/img/logo.svg — que não existe. Funciona no Live Server (onde o projeto é a raiz) e quebra no GitHub Pages. Regra do curso: use sempre caminhos relativos (img/logo.svg, css/estilo.css), sem a barra inicial.

Outra armadilha: Linux e macOS diferenciam maiúsculas de minúsculas; Windows não. img/Fachada.JPG funciona na sua máquina e quebra no GitHub Pages, que roda em Linux. Padronize: nomes de arquivo em minúsculas, sem espaços e sem acentos, com hífen no lugar do espaço (pao-de-queijo.jpg).

3.2 As sete formas de link¶

<!-- 1. Outra página do site (caminho relativo) -->
<a href="cardapio.html">Ver o cardápio completo</a>

<!-- 2. Âncora interna: rola até o elemento com esse id -->
<a href="#horarios">Horários de atendimento</a>

<!-- 3. Âncora em outra página -->
<a href="cardapio.html#doces">Doces do dia</a>

<!-- 4. Site externo (URL absoluta) -->
<a href="https://www.wikipedia.org">Wikipédia</a>

<!-- 5. Abrir em nova aba -->
<a href="https://www.wikipedia.org" target="_blank" rel="noopener">
  Wikipédia (abre em nova aba)
</a>

<!-- 6. E-mail e telefone -->
<a href="mailto:contato@cafecerrado.exemplo.br">contato@cafecerrado.exemplo.br</a>
<a href="tel:+556699999000">(66) 9 9999-9000</a>

<!-- 7. Download de arquivo -->
<a href="docs/cardapio.pdf" download>Baixar o cardápio em PDF</a>

Detalhes que importam:

• mailto: aceita assunto e corpo pré-preenchidos: mailto:contato@cafecerrado.exemplo.br?subject=Reserva%20de%20mesa. O %20 é o espaço codificado para URL.
• tel: deve trazer o número em formato internacional, sem espaços nem parênteses: tel:+556699999000. No celular, o link abre o discador; no desktop, costuma abrir o aplicativo de chamadas configurado.
• download sugere ao navegador baixar em vez de abrir. Com valor (download="cardapio-cafe-cerrado.pdf"), define o nome do arquivo salvo. Só funciona para arquivos do mesmo domínio.

3.3 target="_blank" e por que o rel é obrigatório¶

Abrir link em nova aba parece inofensivo, mas tem duas consequências:

Segurança. A página aberta recebe uma referência à página que a abriu (window.opener) e pode reescrever o endereço da aba original — técnica conhecida como tabnabbing. O rel="noopener" corta essa referência. Navegadores modernos já aplicam noopener por padrão em target="_blank", mas escrever explicitamente é a prática correta: o seu HTML não deveria depender do comportamento padrão de uma versão específica de navegador.

Acessibilidade. Abrir uma aba nova sem avisar quebra o botão "voltar", que é a forma como muita gente navega. Sinalize no texto do link, no title ou com um ícone que tenha texto alternativo.

<a href="https://developer.mozilla.org/pt-BR/" target="_blank" rel="noopener">
  MDN Web Docs (abre em nova aba)
</a>

🔎 Por baixo do capô rel="noreferrer" faz mais do que noopener: além de cortar o window.opener, ele impede que o navegador envie o cabeçalho HTTP Referer — o campo que informa ao site de destino de onde o visitante veio. Isso protege a privacidade, mas apaga a sua origem das estatísticas do site linkado. Para links externos comuns, noopener basta. Se a página tiver informação sensível na URL (um identificador de sessão, por exemplo), use noopener noreferrer.

3.4 Âncoras internas e o id¶

Uma âncora é um link para um id da própria página:

<nav aria-label="Nesta página">
  <ul>
    <li><a href="#cafes">Cafés</a></li>
    <li><a href="#geladas">Bebidas geladas</a></li>
    <li><a href="#salgados">Salgados</a></li>
  </ul>
</nav>

<section id="cafes">
  <h2>Cafés</h2>
</section>

Regras do id: único no documento inteiro, sem espaços, começando por letra. Um id duplicado é erro no validador do W3C e faz o navegador rolar sempre para a primeira ocorrência.

Duas melhorias de uma linha cada:

html {
  scroll-behavior: smooth;   /* rolagem suave até a âncora */
  scroll-padding-top: 5rem;  /* compensa a altura do cabeçalho fixo */
}

Sem scroll-padding-top, a âncora leva o título exatamente para o topo da janela — e o cabeçalho fixo cobre o título. Esse é um dos bugs mais frequentes e mais fáceis de corrigir.

3.5 O texto do link, aria-current e o estado da página atual¶

Leitores de tela oferecem "listar todos os links da página". Nessa lista, cada link aparece sozinho, fora do contexto do parágrafo. Uma página com dez "clique aqui" produz uma lista inútil.

E, no menu, marque a página atual semanticamente:

<nav aria-label="Principal">
  <ul>
    <li><a href="index.html">Início</a></li>
    <li><a href="cardapio.html" aria-current="page">Cardápio</a></li>
    <li><a href="contato.html">Contato</a></li>
  </ul>
</nav>

O atributo aria-current="page" faz o leitor de tela anunciar "Cardápio, página atual". Quem enxerga recebe a mesma informação por cor — e a cor sozinha nunca basta, porque cerca de 8% dos homens têm alguma forma de daltonismo. Bônus: o CSS pode usar o próprio atributo como seletor (nav a[aria-current="page"]), então o destaque visual sai de graça, sem classe extra.

4. Formulários: a porta de entrada de dados¶

Formulário é onde o site deixa de ser um panfleto. Toda a Unidade 3 desta trilha vive de dados que chegam por formulários: na Unidade 2 você vai validá-los com JavaScript e, na Unidade 3, recebê-los no Express. Estruturar o formulário direito agora é investimento nos três marcos do projeto.

4.1 Anatomia do <form>¶

<form action="contato.html" method="post">
  <label for="nome">Nome completo</label>
  <input type="text" id="nome" name="nome" required>

  <button type="submit">Enviar</button>
</form>

• action — para onde os dados vão. Em um site estático ainda não há servidor para recebê-los; na Unidade 3, isso vira /api/contatos.
• method — get coloca os dados na URL (?nome=Ana&assunto=reserva), o que serve para buscas e páginas compartilháveis; post envia no corpo da requisição, o que serve para cadastros, senhas e qualquer coisa que não deva ficar no histórico do navegador.
• name — o nome do dado enviado. Sem name, o campo simplesmente não é enviado. É o erro silencioso número um de formulário: tudo parece certo, e o servidor recebe menos campos do que a tela mostra.
• id — identifica o elemento no documento, para o <label> e para o JavaScript. id e name costumam ter o mesmo valor, mas são coisas diferentes: id é para o navegador, name é para o servidor.

📌 Vale gravar A diferença entre id e name em campos de formulário é pergunta recorrente. Resposta curta: id é único no documento e serve para label for, CSS e JavaScript; name é a chave com que o dado viaja para o servidor, pode se repetir (é assim que um grupo de radio funciona) e, se faltar, o campo não é enviado.

4.2 <label>: um para cada campo, sem exceção¶

<!-- Forma 1: label com for apontando para o id do campo -->
<label for="email">E-mail</label>
<input type="email" id="email" name="email">

<!-- Forma 2: label envolvendo o campo (dispensa for/id) -->
<label>
  E-mail
  <input type="email" name="email">
</label>

O <label> faz três coisas ao mesmo tempo:

1. O leitor de tela anuncia o rótulo quando o campo recebe foco. Sem ele, a pessoa ouve apenas "caixa de edição" e não sabe o que digitar.
2. Clicar no rótulo foca o campo — e, em checkbox/radio, marca a opção. Isso multiplica a área clicável, o que é decisivo no celular.
3. O rótulo permanece visível enquanto a pessoa digita, ao contrário do placeholder.

⚠️ Atenção placeholder não é rótulo. Ele desaparece assim que a pessoa digita a primeira letra, tem contraste baixo por padrão (falhando nos critérios de acessibilidade) e alguns leitores de tela o ignoram. Use placeholder só para mostrar o formato esperado — placeholder="78550-000" ao lado do rótulo "CEP" — nunca no lugar do <label>.

4.3 Os tipos de campo do HTML5¶

Exemplos completos dos que você vai usar hoje:

<label for="pessoas">Quantas pessoas</label>
<input type="number" id="pessoas" name="pessoas" min="1" max="40" step="1" value="2">

<label for="data">Data desejada</label>
<input type="date" id="data" name="data">

<label for="horario">Horário</label>
<input type="time" id="horario" name="horario" min="07:00" max="20:00" step="900">

<label for="foto">Foto do evento (opcional)</label>
<input type="file" id="foto" name="foto" accept="image/png, image/jpeg">

O step="900" no campo de hora significa 900 segundos, ou seja, intervalos de 15 minutos.

🧠 Você sabia? type="tel" não valida nada. Ele existe apenas para dizer ao celular "abra o teclado numérico". A razão é cultural: formatos de telefone variam demais entre países (o Brasil tem números de 10 e de 11 dígitos, com e sem o nono dígito), e a especificação decidiu que qualquer regra embutida excluiria alguém. type="email", por outro lado, valida — e valida de forma bem mais permissiva do que a maioria imagina: a@b passa, porque endereços de intranet sem ponto no domínio são válidos segundo a especificação. Se você precisa de uma regra mais estrita, ela é sua, via pattern — e depois no servidor.

4.4 Agrupando: fieldset, legend, select, textarea¶

<fieldset>
  <legend>Como prefere ser respondido?</legend>

  <label>
    <input type="radio" name="canal" value="email" checked>
    E-mail
  </label>

  <label>
    <input type="radio" name="canal" value="telefone">
    Telefone
  </label>

  <label>
    <input type="radio" name="canal" value="whatsapp">
    WhatsApp
  </label>
</fieldset>

<fieldset> agrupa campos relacionados e <legend> dá o título do grupo — que o leitor de tela anuncia junto com cada opção ("Como prefere ser respondido? E-mail, botão de opção 1 de 3"). Para grupos de radio e checkbox, o par fieldset/legend não é decoração: é o que dá sentido às opções.

Os três radio compartilham o mesmo name="canal" — é isso que os torna mutuamente exclusivos — e cada um tem um value diferente, que é o dado que chega ao servidor.

<label for="assunto">Assunto</label>
<select id="assunto" name="assunto" required>
  <option value="">Selecione um assunto</option>
  <optgroup label="Atendimento">
    <option value="reserva">Reserva de mesa</option>
    <option value="encomenda">Encomenda de bolos e tortas</option>
  </optgroup>
  <optgroup label="Institucional">
    <option value="evento">Evento ou parceria</option>
    <option value="trabalhe">Trabalhe conosco</option>
  </optgroup>
</select>

<label for="mensagem">Mensagem</label>
<textarea id="mensagem" name="mensagem" rows="5" maxlength="500"
          placeholder="Conte o que você precisa"></textarea>

Dois detalhes do <select>:

• A primeira <option> tem value="". Isso é o que faz o required funcionar: sem uma opção de valor vazio, o primeiro item já vem selecionado e a validação nunca reclama.
• <optgroup> agrupa opções sob um rótulo não selecionável. Em listas longas (estados, categorias), organiza muito.

O <textarea> não tem atributo value: o conteúdo inicial vai entre as tags. E cuidado — qualquer espaço ou quebra de linha entre <textarea> e </textarea> vira conteúdo do campo. Por isso escrevemos as duas tags coladas.

4.5 Validação nativa: o navegador trabalhando por você¶

O navegador valida antes de enviar, sem uma linha de JavaScript:

<label for="cep">CEP</label>
<input type="text" id="cep" name="cep"
       required
       pattern="[0-9]{5}-?[0-9]{3}"
       placeholder="78550-000"
       title="Digite um CEP no formato 78550-000"
       inputmode="numeric"
       autocomplete="postal-code">

Quatro observações sobre esse bloco:

• O pattern casa o valor inteiro — não precisa de ^ nem $, eles são implícitos. [0-9]{5}-?[0-9]{3} aceita 78550000 e 78550-000.
• O title vira a mensagem de erro exibida pelo navegador quando o pattern falha. Sem title, a pessoa lê apenas "Corresponda ao formato solicitado", que não ajuda ninguém.
• inputmode="numeric" abre o teclado numérico no celular sem mudar o type — o que seria errado aqui, porque type="number" remove zeros à esquerda e mostra setas de incremento.
• autocomplete="postal-code" deixa o navegador preencher o campo com o CEP já salvo pelo usuário.

O CSS reage aos estados de validação com pseudoclasses:

input:invalid,
select:invalid {
  border-color: #b42318;
}

input:user-invalid {
  outline: 2px solid #b42318;   /* só depois que a pessoa interagiu com o campo */
}

input:valid {
  border-color: #1a7f37;
}

input:required + .marca-obrigatorio::after {
  content: " *";
  color: #b42318;
}

:invalid casa desde o carregamento da página — todo campo required vazio já nasce inválido, e pintar tudo de vermelho antes de a pessoa digitar é hostil. :user-invalid resolve isso: só casa depois que a pessoa interagiu com o campo e saiu dele. Prefira :user-invalid sempre que puder.

🔬 Investigue Crie um arquivo teste-validacao.html com um único campo: <form><input type="email" required><button>Enviar</button></form>. Abra no navegador e clique em Enviar com o campo vazio — anote a mensagem exata que aparece. Agora digite ana@ e envie: outra mensagem. Digite a@b: passa, e é isso mesmo (seção 4.3). Por fim, abra o console (F12 → Console) e execute document.querySelector('input').validity — o navegador devolve um objeto ValidityState com um campo booleano para cada tipo de erro (valueMissing, typeMismatch, patternMismatch, tooShort). Esse objeto é exatamente o que você vai usar para escrever mensagens de erro personalizadas na Unidade 2.

Para testar o formulário sem que o navegador atrapalhe, existe o novalidate:

<form action="contato.html" method="post" novalidate>
</form>

Ele desliga a validação nativa do formulário inteiro. Use durante o desenvolvimento e para assumir o controle das mensagens com JavaScript — jamais como forma de "resolver" um campo que insiste em não validar.

4.6 As três camadas de validação¶

Este é o conceito mais importante da seção, e o que separa quem entende de segurança de quem não entende:

As duas primeiras rodam na máquina do usuário, e tudo que roda na máquina do usuário pode ser burlado: basta abrir o DevTools e remover o atributo required, ou enviar a requisição direto por curl sem passar pela página. A validação do cliente existe para melhorar a experiência de quem está agindo de boa-fé; a validação do servidor existe para proteger o sistema de quem não está.

Você vai ver isso literalmente acontecer: na Unidade 3, ao construir a API do Café Cerrado, o primeiro teste será enviar um POST /api/produtos com o corpo vazio, sem passar por formulário nenhum.

⚠️ Atenção Nunca confie em dados vindos do cliente. Nem no hidden, nem no select (o usuário pode trocar o value de uma <option> no DevTools), nem no maxlength. A regra vale para o resto da sua vida profissional.

5. Validando o HTML: o W3C como corretor automático¶

O validador oficial (https://validator.w3.org/nu/) lê o seu HTML e aponta erros de sintaxe, aninhamento inválido, atributos inexistentes e id duplicado. É gratuito, roda no navegador e aceita três entradas: URL pública, upload de arquivo ou texto colado.

Fluxo recomendado no Café Cerrado:

1. Escreva a página.
2. Cole o conteúdo em "Validate by direct input" (o site ainda não está publicado com as mudanças).
3. Corrija do primeiro erro para o último — erros de aninhamento costumam gerar cascatas, e resolver o primeiro apaga vários.
4. Só depois faça commit e push.

Aprenda a ler a mensagem. Ela sempre tem três partes: a linha, o que o validador esperava e o que encontrou.

Error: Element "figcaption" not allowed as child of element "div" in this context.
From line 42, column 5; to line 42, column 17

Tradução: figcaption só pode ser filho de figure. Você trocou a figure por uma div em algum momento.

Error: Duplicate ID "nome".

Tradução: dois elementos têm id="a03-nome". Provavelmente você copiou um bloco de campo e esqueceu de trocar o id — e, de quebra, o label for="nome" agora aponta para o campo errado.

Vale também rodar o Lighthouse (DevTools → aba Lighthouse → Accessibility). Ele não substitui o validador, mas encontra outra categoria de problemas: contraste, campos sem rótulo, links sem texto discernível. A aula de Acessibilidade e ARIA vai exigir nota ≥ 90 nesse relatório — começar a olhar para ele agora facilita a vida depois.

💻 Mão na massa — Três páginas do Café Cerrado¶

O Café Cerrado — o projeto-fio apresentado na Aula 01 e iniciado na Aula 02 — sai hoje de uma página só para três páginas ligadas entre si, com estrutura semântica completa.

Ao final você terá:

• index.html — hero, sobre, destaques e horários.
• cardapio.html — produtos em listas por categoria, tabela de torras e uma figure.
• contato.html — formulário completo com validação nativa.
• Um menu igual nas três páginas, com aria-current="page" no item certo.

⚠️ Cuidado O index.html de hoje substitui o da Aula 02, com nomes de classe novos. Antes de colar o código do Passo 1, abra css/estilo.css e apague as cinco regras da Aula 02 que ficaram sem dono: .cabecalho, .marca (a versão antiga, de uma linha só), .navegacao ul, .navegacao a (e o :hover/:focus dela), .destaque, .destaque h1, .destaque p, .sobre, .sobre h2, .botao (todas as declarações antigas dela) e .rodape/.rodape p. Ficam de pé, sem alteração: o bloco :root, o reset da §7.2, body, img, a e a regra de main. As classes novas — .topo, .topo__interno, .hero, .cartoes, .rodape__grade — entram no Passo 4. Duas regras com o mesmo nome no mesmo arquivo não dão erro: a última vence em silêncio, e você passa a tarde caçando um estilo que "não aplica".

Se você fez o laboratório B1 da Aula 02 e criou sobre.html, mantenha o item Sobre no menu das três páginas (um <li> a mais, sem aria-current) e repita nele o mesmo <header>/<footer>. O menu de três itens abaixo é o mínimo, não o teto.

Passo 1 — index.html completo¶

Escreva a página inicial inteira. O <header> e o <footer> deste arquivo são idênticos nas outras duas páginas — só muda em qual item do menu fica o aria-current="page".

cafe-cerrado/index.html

<!DOCTYPE html>
<html lang="pt-BR">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta name="description" content="Café Cerrado: torrefação artesanal de grãos do Cerrado mato-grossense em Sinop, MT. Cafés, bebidas geladas, salgados e doces.">
  <title>Café Cerrado — Torrefação artesanal em Sinop, MT</title>
  <link rel="stylesheet" href="css/estilo.css">
</head>
<body>
  <header class="topo">
    <div class="container topo__interno">
      <a class="marca" href="index.html">
        <span class="marca__nome">Café Cerrado</span>
        <span class="marca__slogan">Torrefação artesanal · Sinop, MT</span>
      </a>

      <nav aria-label="Principal">
        <ul class="menu">
          <li><a href="index.html" aria-current="page">Início</a></li>
          <li><a href="cardapio.html">Cardápio</a></li>
          <li><a href="contato.html">Contato</a></li>
        </ul>
      </nav>
    </div>
  </header>

  <main class="container">
    <section class="hero">
      <div class="hero__texto">
        <h1>Café do Cerrado, torrado em Sinop</h1>
        <p class="hero__chamada">
          Compramos grãos de produtores da região, torramos em pequenos lotes e
          moemos na hora do seu pedido. Sem pressa e sem atalho.
        </p>
        <p>
          <a class="botao" href="cardapio.html">Ver o cardápio completo</a>
          <a class="botao botao--vazado" href="contato.html">Reservar uma mesa</a>
        </p>
      </div>

      <img src="img/fachada.jpg"
           alt="Fachada do Café Cerrado com toldo verde e mesas na calçada"
           width="1200" height="800">
    </section>

    <section id="sobre">
      <h2>Nossa história</h2>
      <p>
        O Café Cerrado nasceu em uma garagem no Setor Comercial de Sinop, com um
        torrador de dois quilos e a teimosia de provar que o café produzido no
        Mato Grosso pode brigar com os grãos mais famosos do país.
      </p>
      <p>
        Hoje trabalhamos com quatro sítios parceiros no cerrado mato-grossense e
        torramos, em média, sessenta quilos por semana — tudo consumido aqui
        mesmo, no balcão ou nas mesas da calçada.
      </p>

      <h3>O que você encontra aqui</h3>
      <ul>
        <li>Wi-Fi liberado e tomada em todas as mesas</li>
        <li>Moagem na hora, com escolha da torra</li>
        <li>Grãos embalados para levar para casa</li>
        <li>Opções sem lactose e sem glúten identificadas no cardápio</li>
      </ul>
    </section>

    <section id="destaques">
      <h2>Destaques da semana</h2>

      <ul class="cartoes">
        <li>
          <article class="cartao">
            <h3>Cold Brew da Chapada</h3>
            <p class="cartao__preco">R$ 15,00</p>
            <p>Extração a frio por dezoito horas, servido com gelo e rodela de laranja.</p>
            <p><a href="cardapio.html#geladas">Ver nas bebidas geladas</a></p>
          </article>
        </li>

        <li>
          <article class="cartao">
            <h3>Pão de Queijo Mineiro</h3>
            <p class="cartao__preco">R$ 7,00</p>
            <p>Massa de polvilho azedo com queijo canastra, assado de hora em hora.</p>
            <p><a href="cardapio.html#salgados">Ver nos salgados</a></p>
          </article>
        </li>

        <li>
          <article class="cartao">
            <h3>Bolo de Milho Verde</h3>
            <p class="cartao__preco">R$ 9,50</p>
            <p>Receita da avó da Dona Marli, com milho comprado na feira do produtor.</p>
            <p><a href="cardapio.html#doces">Ver nos doces</a></p>
          </article>
        </li>
      </ul>
    </section>

    <section id="horarios">
      <h2>Horário de atendimento</h2>

      <div class="tabela-rolavel">
        <table>
          <caption>Horário de atendimento do Café Cerrado</caption>
          <thead>
            <tr>
              <th scope="col">Dia</th>
              <th scope="col">Abertura</th>
              <th scope="col">Fechamento</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <th scope="row">Segunda a sexta</th>
              <td>07h00</td>
              <td>20h00</td>
            </tr>
            <tr>
              <th scope="row">Sábado</th>
              <td>08h00</td>
              <td>18h00</td>
            </tr>
            <tr>
              <th scope="row">Domingo</th>
              <td colspan="2">Fechado</td>
            </tr>
          </tbody>
        </table>
      </div>

      <p>
        Precisa de um horário fora do expediente para um evento?
        <a href="contato.html">Fale com a gente pelo formulário de contato</a>.
      </p>
    </section>
  </main>

  <footer class="rodape">
    <div class="container rodape__grade">
      <section>
        <h2>Café Cerrado</h2>
        <p>Torrefação artesanal de grãos do Cerrado mato-grossense. Projeto fictício
           usado como estudo de caso do Nível 2 do WebLab (Desenvolvimento Web).</p>
      </section>

      <section>
        <h2>Onde estamos</h2>
        <address>
          Avenida dos Jacarandás, 1200 — Setor Comercial<br>
          Sinop — MT<br>
          <a href="tel:+556699999000">(66) 9 9999-9000</a><br>
          <a href="mailto:contato@cafecerrado.exemplo.br">contato@cafecerrado.exemplo.br</a>
        </address>
      </section>

      <nav aria-label="Rodapé">
        <h2>Navegação</h2>
        <ul>
          <li><a href="index.html">Início</a></li>
          <li><a href="cardapio.html">Cardápio</a></li>
          <li><a href="contato.html">Contato</a></li>
          <li><a href="index.html#horarios">Horários</a></li>
        </ul>
      </nav>
    </div>

    <p class="rodape__creditos">Café Cerrado · Sinop/MT · Projeto acadêmico</p>
  </footer>
</body>
</html>