🎯 Objetivos de aprendizagem¶

Ao final desta aula você será capaz de:

• Descrever como esta trilha funciona: unidades, marcos do projeto, projeto fio-condutor e projeto autoral.
• Distinguir Internet de World Wide Web e situar os principais marcos da história da Web.
• Explicar o modelo cliente-servidor e o papel do front-end e do back-end.
• Descrever, passo a passo, o que acontece entre digitar uma URL e ver a página renderizada.
• Decompor uma URL em suas seis partes e escrever caminhos relativos e absolutos corretos.
• Classificar arquiteturas web (camadas, estático × dinâmico, MPA × SPA) e apontar onde o front-end se encaixa.
• Configurar o ambiente de trabalho (VS Code, Live Server e DevTools) e criar o primeiro documento HTML.

📋 Pré-requisitos¶

Esta é a primeira aula: não há conteúdo anterior para retomar. Mas há o que trazer:

• [ ] Um notebook ou computador com Google Chrome ou Firefox atualizado.
• [ ] Visual Studio Code instalado (https://code.visualstudio.com/). Se ainda não instalou, faremos juntos no Bloco 3.
• [ ] Extensões do VS Code Live Server e Prettier (instalação na §1.6 desta aula).
• [ ] Uma pasta dedicada no computador para guardar os arquivos do curso (o Git chega na Aula 15).
• [ ] Uma ideia, mesmo vaga, de tema para o seu projeto autoral (ver §1.4). Você decide hoje.

Nenhuma experiência prévia com programação é exigida. Se você nunca escreveu uma linha de código, está no lugar certo — a trilha começa do zero.

🗺️ Roteiro¶

1. Como funciona esta trilha¶

1.1 O que esta trilha cobre¶

Esta trilha cobre: arquiteturas computacionais para Web; criação de páginas web com HTML, CSS e JavaScript.

Objetivo geral: ao final desta trilha, você projeta e desenvolve o front-end de aplicações web funcionais, acessíveis e responsivas, dominando as três tecnologias fundamentais da plataforma (HTML, CSS e JavaScript) e entendendo a arquitetura em que elas operam.

A palavra-chave é front-end: tudo que roda no navegador do usuário. Você vai entender o sistema completo (servidor, banco de dados, API), mas vai construir a parte que o usuário vê e toca. O back-end é assunto do Nível 2.

1.2 Três unidades, três marcos do projeto¶

Os três marcos incidem sobre o mesmo site: o Marco 1 constrói a estrutura em HTML, o Marco 2 aplica o design com CSS, o Marco 3 acrescenta o comportamento com JavaScript. Por isso é importante escolher hoje um tema que você aguente desenvolver até o fim da trilha.

1.3 A sequência das aulas¶

O conteúdo abaixo é o mesmo em qualquer oferta: serve igualmente a quem estuda por conta própria, sem data alguma, e a quem cursa esta trilha em uma turma com professor e calendário próprios — nesse caso, é o professor quem define as datas.

Os blocos 📌 Vale gravar espalhados pelas aulas destacam os pontos que mais reaparecem mais adiante — vale mesmo memorizar.

Esta trilha soma aproximadamente 60 h de estudo: cerca de 45 h acompanhando as 15 aulas (teoria e prática guiada, em três blocos de 50 min cada) e 15 h nas atividades assíncronas — uma por aula, feita por conta própria depois do conteúdo principal.

⚠️ Atenção As atividades assíncronas não são extras opcionais. Elas compõem a prática real da trilha e alimentam o Marco do projeto da unidade correspondente. Pule uma e você sente falta dela mais adiante.

1.4 Projeto fio-condutor e projeto autoral¶

A regra pedagógica central do WebLab é simples:

1. O projeto fio-condutor é construído ao longo da trilha — o site de um evento acadêmico, a "Semana Acadêmica de Sistemas de Informação". São cinco páginas: início, programação, inscrição, palestrantes e contato. Na Unidade 1 elas nascem em HTML puro; na Unidade 2 ganham CSS; na Unidade 3 ganham JavaScript. Se você está em aula com um professor, é o projeto que ele constrói com a turma, passo a passo, e todo mundo digita junto; se está estudando sozinho, é o que você constrói acompanhando cada Mão na massa.
2. Cada pessoa desenvolve também um projeto autoral com a mesma arquitetura (cinco páginas, mesma sequência de tecnologias) e um domínio diferente. Os marcos do projeto acompanham o projeto autoral, não o site do evento.

Exemplos de temas que funcionam bem: catálogo de plantas do Pantanal, agenda de quadras esportivas, mural de estágios do curso, brechó de roupas, controle de pescarias no Teles Pires, cardápio de um restaurante, portfólio de um fotógrafo, site de uma ONG de proteção animal. O critério é: você consegue pensar em cinco páginas com conteúdo real para esse tema? Se sim, serve.

💡 Dica Escolha um tema que você goste e sobre o qual tenha conteúdo (textos, dados para tabelas, fotos). O erro mais comum é escolher algo genérico demais ("site de uma empresa") e ficar sem o que escrever na página. Tema concreto gera site melhor.

1.5 Como estudar com este material¶

Cada aula do WebLab tem quatro camadas de prática, sempre nesta ordem: 💻 Mão na massa (o passo a passo guiado, que você acompanha digitando junto — em aula ou sozinho), 🧪 Laboratório (exercícios em três níveis), 🏆 Desafios (extras, opcionais, com estrelas de dificuldade) e 🏠 Para praticar depois da aula (a tarefa de 1 h ligada ao seu projeto autoral).

Uma rotina que funciona:

1. Antes de estudar cada aula, leia os objetivos e passe os olhos no conteúdo. Você aproveita muito mais sabendo aonde ela vai chegar.
2. Ao acompanhar o conteúdo, digite o código junto. Copiar e colar não fixa nada; digitar e errar, sim.
3. Logo em seguida, faça o Laboratório Nível A. São perguntas curtas que consolidam o vocabulário.
4. Nos dias seguintes, faça o Nível B e a Atividade assíncrona. São eles que constroem habilidade de verdade.
5. Se sobrar tempo e vontade, encare o Nível C e os Desafios. São do tamanho de um item de portfólio — o tipo de coisa que impressiona em uma entrevista de emprego.

Programação não se aprende lendo. Se você fechar esta página achando que entendeu tudo e não tiver escrito código, não aprendeu. Abra o editor.

1.6 Ambiente de trabalho¶

Instalação, em ordem:

1. Baixe e instale o VS Code em https://code.visualstudio.com/. Aceite as opções padrão.
2. Abra o VS Code e pressione Ctrl+Shift+X para abrir a aba de extensões.
3. Procure Live Server (autor: Ritwick Dey) e clique em Install.
4. Procure Prettier – Code formatter e clique em Install.
5. Em File → Preferences → Settings, procure format on save e marque a opção. A partir de agora o código é formatado toda vez que você salva.
6. Instale o Chrome ou o Firefox, se ainda não tiver. Os dois têm DevTools equivalentes; os exemplos das aulas usam o Chrome.

Git e GitHub ficam para mais tarde: o capítulo 02 da trilha Deploy & Ferramentas ensina do zero, e a Aula 15 publica o site.

2. Internet não é a Web¶

São coisas diferentes, e confundi-las é o primeiro erro conceitual da área.

A Internet é a infraestrutura física e lógica: cabos, fibras, roteadores, satélites e um conjunto de protocolos (principalmente TCP/IP) que permitem que máquinas em qualquer lugar do planeta troquem pacotes de dados. A Internet existe desde os anos 1970 (ARPANET) e transporta muito mais do que páginas: e-mail (SMTP), transferência de arquivos (FTP), streaming, chamadas de voz (VoIP), jogos online, o próprio DNS.

A World Wide Web é uma aplicação que roda sobre a Internet. Foi proposta por Tim Berners-Lee no CERN em 1989 e é composta por três invenções combinadas:

💡 Dica Analogia: a Internet é o sistema rodoviário (asfalto, placas, regras de trânsito). A Web é o serviço de entregas que usa essas estradas. WhatsApp, e-mail e jogos online são outros serviços que usam as mesmas estradas sem serem a Web.

Repare que as três invenções são exatamente o que você vai estudar: URLs (hoje), HTTP (hoje e no Nível 2) e HTML (a partir da próxima aula). A Web é, no fundo, uma ideia simples: documentos com endereço, que apontam uns para os outros.

Linha do tempo essencial¶

🧠 Você sabia? O primeiro site do mundo continua no ar, no endereço original: http://info.cern.ch/hypertext/WWW/TheProject.html. É só HTML, sem uma linha de CSS ou JavaScript — e abre em qualquer navegador moderno em milissegundos. Essa compatibilidade com o passado é uma decisão de projeto da Web: um navegador de hoje precisa continuar exibindo uma página de 1991. Poucas plataformas de software conseguem dizer o mesmo.

3. O modelo cliente-servidor¶

Praticamente toda a Web funciona sobre um modelo de requisição e resposta entre dois papéis:

• Cliente: quem pede. Na Web, tipicamente o navegador (Chrome, Firefox, Safari, Edge). Também pode ser um aplicativo de celular, um script, outro servidor.
• Servidor: quem responde. Um computador executando um software servidor web (Apache, Nginx, Node.js) que fica permanentemente à espera de requisições.

     CLIENTE                                          SERVIDOR
   ┌───────────┐          1. Requisição HTTP        ┌───────────┐
   │ Navegador │    ────────────────────────────>   │ Servidor  │
   │           │          GET /index.html           │    Web    │
   │           │                                    │           │
   │           │    <────────────────────────────   │           │
   └───────────┘          2. Resposta HTTP          └───────────┘
                          200 OK + HTML

Três características definem esse modelo:

1. O cliente sempre inicia. O servidor nunca "manda" nada espontaneamente numa conexão HTTP tradicional — ele só responde ao que foi pedido.
2. HTTP é stateless (sem estado). Cada requisição é independente: o servidor não lembra, por si só, o que aconteceu na requisição anterior. Sessões, logins e carrinhos de compra são construídos por cima disso, com cookies e tokens.
3. Uma página não é um arquivo, são dezenas. Abrir uma página comum dispara de 30 a 200 requisições: o HTML, cada folha de estilo, cada script, cada imagem, cada fonte.

Front-end e back-end¶

⚠️ Atenção Consequência de segurança, importante desde já: todo código front-end é público. O usuário pode ler seu JavaScript, alterar valores e burlar validações. Validação no cliente é para conforto do usuário; validação no servidor é para segurança. Nunca confie apenas na validação client-side — você vai ver isso na prática na Aula 03 e voltaremos ao tema na Unidade 3.

Nesta trilha trabalhamos exclusivamente com front-end, mas com consciência do sistema completo.

4. O que acontece quando você digita uma URL¶

Este é um dos assuntos mais cobrados em entrevistas técnicas. Aprenda a sequência.

Passo 1 — Análise da URL. O navegador separa o endereço em partes (§5) e descobre qual protocolo usar e qual servidor contatar.

Passo 2 — Resolução DNS. O nome www.exemplo.com.br não serve para roteamento; a rede trabalha com endereços IP. O navegador consulta o DNS (Domain Name System), um serviço distribuído de diretórios, para traduzir o nome em um IP. Antes de sair para a rede, ele consulta caches, nesta ordem: 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 com o servidor, normalmente na porta 80 (HTTP) ou 443 (HTTPS), usando o three-way handshake (SYN → SYN-ACK → ACK).

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

Passo 5 — Requisição HTTP. O navegador envia um texto parecido com este:

GET /cursos/sistemas HTTP/1.1
Host: www.exemplo.com.br
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) 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) e onde (/cursos/sistemas). As demais são cabeçalhos (headers): metadados no formato Nome: valor. Repare que é texto puro, legível — HTTP foi projetado para ser simples.

Passo 6 — Processamento no servidor. O servidor identifica o recurso pedido. Se for um arquivo estático, apenas o lê do disco. Se for dinâmico, executa código (PHP, Node, Java), possivelmente consulta um banco de dados e gera o HTML na hora.

Passo 7 — Resposta HTTP. O servidor devolve outro texto, com uma linha de status, cabeçalhos e, depois de uma linha em branco, o conteúdo:

HTTP/1.1 200 OK
Date: Wed, 12 Aug 2030 22:14:05 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 8420
Cache-Control: max-age=3600

<!DOCTYPE html>
<html lang="pt-BR">
<head>
  <title>Sistemas de Informação</title>
</head>

Passo 8 — Renderização. O navegador processa a resposta (detalhado na §6) e dispara novas requisições para cada recurso referenciado no HTML: folhas de estilo, scripts, imagens, fontes. Cada uma repete os passos 5 a 7.

🔎 Por baixo do capô Por que tanto cache de DNS? Porque cada consulta que sai para a rede custa dezenas de milissegundos — e uma página faz dezenas de requisições, muitas para domínios diferentes. Sem cache, só a tradução de nomes já deixaria a Web visivelmente lenta. O mesmo raciocínio (guardar o que já foi obtido para não pedir de novo) aparece no cabeçalho Cache-Control da resposta acima, e é o tema do desafio C1 de hoje.

📌 Vale gravar A ordem das etapas (URL → DNS → TCP → TLS → requisição → processamento → resposta → renderização) e o que cada uma faz. Saber que o DNS traduz nome em IP e que HTTP é stateless são perguntas frequentes.

5. Anatomia de uma URL¶

https://www.exemplo.com.br:443/cursos/sistemas?campus=sinop&turno=noite#ementa
└─┬─┘   └──────┬─────┘└┬┘└──────┬───────┘└────────┬─────────────┘└──┬──┘
  1            2       3        4                 5                 6

O fragmento (#) vai ser seu aliado a partir da Aula 02: é ele que faz um link "pular" para uma seção da mesma página. A query string (?) vai aparecer na Aula 03, quando um formulário enviado com GET grava os campos digitados na própria URL.

Caminhos absolutos e relativos¶

Você vai usar isto em toda aula a partir de agora, em links, imagens, folhas de estilo e scripts:

O ponto de partida de um caminho relativo é sempre a pasta do arquivo onde o caminho está escrito, não a pasta do projeto. Se paginas/contato.html precisa da imagem img/logo.png que está na raiz, o caminho correto é ../img/logo.png: sobe um nível, entra em img.

⚠️ Atenção Erro clássico: usar C:\Users\Ivan\Documents\site\logo.png no src de uma imagem. Funciona na sua máquina e quebra em todas as outras. Caminhos de sistema de arquivos não existem na Web — o servidor só conhece a pasta do site.

6. Como o navegador renderiza uma página¶

O navegador não "mostra o HTML". Ele executa um pipeline:

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 chamada DOM (Document Object Model). Cada tag vira um nó da árvore.
2. Parsing do CSS → CSSOM. As regras de estilo viram outra árvore, o CSSOM.
3. Render Tree. DOM + CSSOM são combinados, descartando o que não é visível (por exemplo, o que tem display: none).
4. Layout (reflow). Cálculo da posição e do tamanho exatos de cada caixa na tela.
5. Paint. Preenchimento de pixels: cores, textos, bordas, sombras.
6. Composite. Montagem das camadas na tela.

Cada navegador tem um motor de renderização: Blink (Chrome, Edge, Opera), Gecko (Firefox), WebKit (Safari). Diferenças entre motores são a razão de existirem os padrões — e a razão de os sites às vezes ficarem diferentes em cada navegador.

🔎 Por baixo do capô Por que 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 colocar <script> antes de </body> ou usar o atributo defer. Você vai ver isso de perto na Aula 10, quando o JavaScript entrar em cena.

O DOM é uma das ideias mais importantes do semestre. Guarde desde já: o arquivo .html no disco é texto; o DOM é a árvore em memória que o navegador constrói a partir dele. O DevTools mostra o DOM, não o arquivo — e o JavaScript, na Unidade 3, vai manipular o DOM, não o arquivo.

7. Os três pilares do front-end¶

A separação entre eles é chamada de separação de responsabilidades (separation of concerns) e é um princípio de engenharia, não capricho: permite trocar o visual sem tocar no conteúdo, reaproveitar estilos entre páginas e manter o código legível por equipes diferentes.

Um mesmo HTML com três CSS distintos vira três sites visualmente diferentes. Esse é o ponto — e é exatamente o que vai acontecer com o site do evento: o HTML que você escreve na Unidade 1 não muda quando o CSS chega na Unidade 2.

Padrões e quem os define¶

Nenhuma empresa é dona da Web. Os navegadores implementam especificações públicas, escritas em processo aberto. É por isso que a documentação oficial (MDN, especificações do W3C e da WHATWG) vale mais do que qualquer tutorial — e é para ela que os links de "Para aprofundar" apontam.

8. Arquitetura em camadas¶

"Camada" (tier ou layer) é uma divisão lógica de responsabilidades. Quanto mais camadas, maior a separação — e maior a complexidade.

Uma camada (monolítica local)¶

Tudo em um único programa, em uma única máquina. Não é Web — é o modelo de um aplicativo desktop antigo, com interface, regras e dados no mesmo executável.

Duas camadas (cliente-servidor clássico)¶

[ Cliente com lógica ]   <──────>   [ Servidor de Banco de Dados ]

O cliente é "gordo" (fat client): contém a interface e as regras de negócio, e conversa diretamente com o banco. Problema: qualquer mudança de regra exige reinstalar o programa em todas as máquinas, e o banco fica exposto na rede.

Três camadas — o padrão da Web¶

┌──────────────────┐   HTTP   ┌──────────────────┐   SQL   ┌──────────────┐
│ APRESENTAÇÃO     │ <──────> │    APLICAÇÃO     │ <─────> │    DADOS     │
│ (navegador)      │          │ (servidor web +  │         │   (SGBD)     │
│ HTML/CSS/JS      │          │ regras negócio)  │         │ MySQL,       │
│                  │          │ Node, PHP, Java  │         │ PostgreSQL   │
└──────────────────┘          └──────────────────┘         └──────────────┘
     CLIENTE                        SERVIDOR                  SERVIDOR

Vantagens: cada camada pode ser escalada, atualizada e substituída de forma independente; o banco nunca fica exposto ao cliente; as regras existem em um único lugar.

Esta trilha inteira vive na camada de apresentação. O Nível 2 constrói a camada de aplicação (Node.js + Express) e o Nível 3 integra as três.

N camadas e microsserviços¶

Sistemas grandes fragmentam ainda mais: camada de cache (Redis), fila de mensagens (RabbitMQ, Kafka), balanceador de carga (Nginx), serviços independentes por domínio de negócio. Ganha-se escalabilidade e autonomia de equipes; paga-se com complexidade operacional e latência de rede. Nada disso é assunto deste nível, mas você vai reconhecer os nomes quando ler uma vaga de emprego.

9. Sites estáticos e dinâmicos¶

⚠️ Atenção Confusão frequente: "dinâmico", no sentido de arquitetura, significa HTML gerado no servidor. Uma página estática com muito JavaScript e animações continua sendo estática do ponto de vista arquitetural. O SIGAA é dinâmico. Um portfólio com carrossel animado é estático. O site do evento que vamos construir é estático — e vai ser publicado de graça, por isso mesmo.

10. MPA e SPA¶

MPA — Multi Page Application. Cada navegação carrega um novo documento HTML completo do servidor. É o modelo tradicional. Vantagens: simples, ótimo para buscadores (SEO), funciona sem JavaScript. Desvantagem: a tela "pisca" a cada clique.

SPA — Single Page Application. O servidor entrega um HTML e um pacote JavaScript. A partir daí, o JavaScript intercepta a navegação, busca apenas os dados (via API, em JSON) e reescreve o DOM. Vantagens: sensação de aplicativo, menos tráfego após a carga inicial. Desvantagens: carga inicial pesada, complexidade, SEO exige trabalho extra, quebra sem JavaScript. Frameworks típicos: React, Vue, Angular, Svelte.

MPA:   clique ──> servidor ──> HTML completo ──> recarrega a página
SPA:   clique ──> JS intercepta ──> API ──> JSON ──> JS reescreve o DOM

O site do evento é uma MPA: cinco arquivos .html, um por página. É o ponto de partida certo — SPAs são o assunto do Nível 2 (Unidade 2) e do Nível 3 inteiro.

11. APIs, JSON e REST¶

Uma API (Application Programming Interface) é um contrato pelo qual dois sistemas conversam. Na Web, o estilo dominante é o REST, que usa os próprios verbos do HTTP:

Perceba que essas quatro operações são exatamente o CRUD (Create, Read, Update, Delete). Neste nível você vai reconhecer o CRUD nas requisições que o navegador faz; a leitura de dados aparece nas consultas dinâmicas da Aula 14, e a escrita no servidor é assunto do Nível 2.

O formato de troca padrão é o JSON (JavaScript Object Notation) — texto, legível, com pares chave: valor:

{
  "id": 42,
  "nome": "Maria Silva",
  "curso": "Sistemas de Informação",
  "fase": 2,
  "ativo": true,
  "disciplinas": ["Desenvolvimento Web", "Banco de Dados"]
}

Principais códigos de status HTTP¶

💡 Dica Mnemônico: 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".

🔬 Investigue Abra um site que você usa bastante (rede social, portal de notícias, e-commerce), pressione F12, vá à aba Network e recarregue com Ctrl+F5. Observe: (1) quantas linhas apareceram — cada uma é uma requisição; (2) a coluna Type: document, stylesheet, script, png, font; (3) clique na primeira linha, abra Headers e procure Content-Type e Server na resposta; (4) na barra inferior, leia o total de requisições e o peso transferido. Você acabou de ver o "uma página são dezenas de arquivos" acontecendo — e o cabeçalho Server conta qual software respondeu.

12. Infraestrutura de entrega¶

• Servidor web: Apache, Nginx, IIS, Node.js. Recebe requisições e devolve recursos.
• CDN (Content Delivery Network): rede de servidores espalhados geograficamente que guardam cópias dos arquivos. Um usuário em Sinop recebe o arquivo de um nó em São Paulo, não da Califórnia. Reduz a latência drasticamente. Exemplos: Cloudflare, Akamai.
• Hospedagem estática: GitHub Pages, Netlify, Vercel, Cloudflare Pages — gratuitas e suficientes para tudo que faremos nesta trilha. O projeto do Marco 3 (Aula 15) é publicado em uma delas.
• DNS e domínio: registro de domínios .br via Registro.br. Um domínio próprio custa por volta de R$ 40 por ano; a trilha Deploy (capítulo 04) mostra como apontar um para o seu site.

💻 Mão na massa — Pasta do projeto, primeiro HTML e DevTools¶

Hoje nasce a pasta que você vai usar até o fim da trilha e o primeiro arquivo do site do evento.

Passo 1 — Estrutura de pastas¶

Crie, no seu computador (em Documentos, por exemplo), a seguinte estrutura. Por enquanto só as pastas e um arquivo:

introducao-web/
├── site-evento/          ← projeto fio-condutor (construído aula a aula)
│   ├── index.html
│   ├── css/
│   ├── img/
│   └── js/
├── meu-projeto/          ← projeto autoral (tema seu, mesma estrutura)
└── exercicios/
    ├── aula01/
    ├── aula02/
    └── aula03/

⚠️ Atenção Regra permanente: nomes de arquivos e pastas em minúsculas, sem espaços, sem acentos. Use hífen para separar palavras (sobre-nos.html, nunca Sobre Nós.html). Servidores Linux diferenciam maiúsculas de minúsculas — Index.html e index.html são arquivos distintos para eles, e o que funciona no Windows pode quebrar quando você publicar.

Abra o VS Code, vá em File → Open Folder e abra a pasta introducao-web. Sempre abra a pasta raiz, não um arquivo solto: o Live Server e os caminhos relativos dependem disso.

Passo 2 — O primeiro HTML¶

No painel esquerdo, clique com o botão direito em site-evento → New File → index.html. Digite (não cole):

site-evento/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>Semana Acadêmica de Sistemas de Informação</title>
</head>
<body>
  <h1>Semana Acadêmica de Sistemas de Informação</h1>
  <p>Três dias de palestras, minicursos e oficinas.</p>
  <p>Este site está sendo construído com o WebLab, na trilha <strong>Introdução ao Desenvolvimento Web</strong>.</p>
</body>
</html>

Cada linha será explicada na Aula 02. Por hoje, o essencial: <!DOCTYPE html> diz que é HTML5; <head> guarda informações sobre a página; <body> guarda o que aparece na tela; e <meta charset="UTF-8"> diz ao navegador como ler os acentos.

Passo 3 — Subir o servidor local¶

Clique com o botão direito no arquivo index.html → Open with Live Server (ou clique em Go Live no canto inferior direito). O navegador abre em um endereço parecido com:

http://127.0.0.1:5500/site-evento/index.html

Leia essa URL com a §5 na cabeça: esquema http, host 127.0.0.1, porta 5500, caminho /site-evento/index.html. Você acabou de subir um servidor web na sua máquina — 127.0.0.1 é o endereço que todo computador usa para se referir a si mesmo (também chamado de localhost). A partir de agora o navegador é o cliente e o Live Server é o servidor, exatamente como no diagrama da §3.

Altere o texto do <p>, salve com Ctrl+S e olhe o navegador: ele recarrega sozinho. É isso que o Live Server faz.

Passo 4 — Experimento obrigatório: o charset¶

Remova a linha <meta charset="UTF-8">, salve e olhe o navegador. Os acentos viram símbolos estranhos (ç, ã, é). Isso acontece porque o navegador passa a interpretar os bytes com outra tabela de caracteres. Recoloque a linha. Esse é o erro mais comum de iniciante e agora você sabe reconhecê-lo em dois segundos.

Passo 5 — Ferramentas do desenvolvedor (DevTools)¶

Pressione F12 (ou Ctrl+Shift+I). Você vai usar isto todos os dias do semestre.

Roteiro de exploração — faça agora, na sua página:

1. Elements: dê duplo clique no texto do <h1> e altere. Note que muda na tela mas não no arquivo — você está editando o DOM em memória, não o HTML. Recarregue e a alteração some.
2. Console: digite document.title e pressione Enter. Aparece o texto do seu <title>. Digite document.body.children.length — quantos filhos diretos o <body> tem?
3. Network: marque Disable cache, recarregue com Ctrl+F5 e observe o status 200 ao lado de index.html. Agora renomeie o arquivo para inicio.html e recarregue: status 404. Renomeie de volta.
4. Abra em outra aba um site que você visita com frequência e, na aba Network, conte quantas requisições a página faz e qual é o maior arquivo (clique no cabeçalho da coluna Size para ordenar).

Passo 6 — O projeto autoral começa hoje¶

Copie site-evento/index.html para meu-projeto/index.html e troque o <title>, o <h1> e os parágrafos pelo tema do seu projeto. Abra também com o Live Server. Está feito o primeiro commit mental: a partir de agora, tudo que o site do evento ganha nesta trilha, o seu projeto ganha também.

Como testar¶

• O Live Server abre http://127.0.0.1:5500/site-evento/index.html e a página mostra o título e os parágrafos com acentos corretos.
• Alterar e salvar o arquivo recarrega o navegador sozinho.
• Na aba Network, index.html aparece com status 200.
• No Console, document.title devolve "Semana Acadêmica de Sistemas de Informação".
• meu-projeto/index.html abre com o seu tema.

Resultado esperado: duas páginas simples no ar, servidas pelo Live Server; o DevTools aberto e explorado; a estrutura de pastas pronta para o semestre.

🧪 Laboratório¶

Nível A — Fixação¶

A1. Explique, com suas palavras e em no máximo 4 linhas, a diferença entre Internet e World Wide Web.

A2. Classifique cada item como Internet ou Web: (a) protocolo TCP/IP; (b) HTML; (c) e-mail via SMTP; (d) HTTP; (e) cabos de fibra óptica submarinos; (f) URL.

A3. Decomponha a URL abaixo, nomeando cada uma das seis partes:

https://loja.exemplo.com.br:8443/produtos/notebooks?marca=dell&ordem=preco#avaliacoes

A4. O que significa dizer que o HTTP é stateless? Cite uma consequência prática disso.

A5. Qual a porta padrão do HTTP? E do HTTPS? Por que elas normalmente não aparecem na URL?

A6. Coloque em ordem correta as etapas: (1) handshake TCP; (2) renderização; (3) resolução DNS; (4) resposta HTTP; (5) requisição HTTP; (6) análise da URL.

A7. Associe cada tecnologia ao seu papel: HTML / CSS / JavaScript ↔ comportamento / apresentação / estrutura.

A8. Um arquivo está em site/paginas/contato.html e precisa referenciar site/img/logo.png. Qual o caminho relativo correto?

A9. O que é o DOM? Ele existe no arquivo .html salvo em disco ou apenas em memória?

A10. Cite três organizações que mantêm padrões da Web e diga do que cada uma cuida.

A11. Por que #secao2 na URL não gera requisição ao servidor?

A12. Qual a diferença entre os status HTTP 200 e 404? Cite mais dois códigos e seus significados.

Nível B — Aplicação¶

B1. Usando a aba Network do DevTools, acesse três sites diferentes (um portal de notícias, um e-commerce e o site da sua universidade ou escola) e registre, para cada um: número de requisições, peso total transferido (KB ou MB), tempo de carregamento (Load, na barra inferior) e qual foi o maior recurso. Escreva um parágrafo comparando os resultados e levantando hipóteses sobre as diferenças.

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

B2. Crie exercicios/aula01/sobre-mim.html contendo: título da página no <title>, um <h1> com seu nome, um parágrafo de apresentação, um parágrafo com seus objetivos nesta trilha e um link para o site de uma universidade ou escola (a sua, se estiver cursando alguma) que abra em nova aba (pesquise o atributo target).

Resultado esperado: a página abre no Live Server com acentos corretos; o link abre o site escolhido em outra aba.

B3. Desenhe (no papel, no Draw.io ou no Excalidraw) um diagrama do ciclo requisição-resposta incluindo: usuário, navegador, DNS, Internet, servidor web e banco de dados. Indique com setas numeradas a ordem dos eventos.

Resultado esperado: um diagrama com pelo menos 8 setas numeradas, do "usuário digita a URL" ao "navegador renderiza".

B4. No Console do DevTools, execute os comandos abaixo em uma página qualquer e registre o resultado de cada um, explicando o que retornaram:

window.location.href
window.location.protocol
window.location.hostname
document.title
navigator.userAgent

Resultado esperado: cinco linhas de saída com a sua explicação; você deve conseguir relacionar protocol e hostname com as partes 1 e 2 da URL da §5.

B5. Pesquise e escreva um resumo de meia página sobre a diferença entre HTTP/1.1, HTTP/2 e HTTP/3, focando em: multiplexação, cabeçalhos e protocolo de transporte usado.

Resultado esperado: texto de 15 a 25 linhas, com pelo menos uma fonte citada (a MDN serve).

B6. Abra um site com HTTPS, clique no cadeado e examine o certificado. Registre: quem emitiu, para qual domínio é válido, data de validade e qual o algoritmo de chave. Explique para que serve cada informação.

Resultado esperado: quatro dados anotados e uma explicação de 2 a 3 linhas para cada um.

Nível C — Desafio¶

C1. Investigação de cache. Acesse um mesmo site duas vezes na aba Network: uma com Disable cache marcado e outra desmarcado. Compare o número de requisições e o peso transferido. Identifique quais recursos vieram do cache (procure por (disk cache), (memory cache) ou status 304). Produza um relatório de 1 página explicando o que é cache HTTP, o papel do cabeçalho Cache-Control e por que ele é essencial para a performance da Web.

🏆 Desafios¶

🐛 Erros comuns¶

🏠 Para praticar depois da aula (1 h)¶

Parte 1 — Leitura (20 min). SILVA, M. S. Criando sites com HTML, capítulo introdutório. MILETTO, E. M.; BERTAGNOLLI, S. C. Desenvolvimento de software II, capítulo sobre arquiteturas para a Web. Anote duas ideias de cada texto que não apareceram nesta aula.

Parte 2 — Produção (30 min). Produza:

1. O exercício B2 (sobre-mim.html) e o exercício B5 (resumo sobre HTTP/1.1, 2 e 3).
2. Uma captura de tela do VS Code com a pasta introducao-web aberta e outra do Live Server exibindo site-evento/index.html, com a URL 127.0.0.1:5500 visível.
3. O tema do seu projeto autoral, em 3 linhas: o que é, para quem é, e o nome das cinco páginas (a versão "início, programação, inscrição, palestrantes, contato" do seu domínio).

Parte 3 — Discussão (10 min). Em texto próprio — ou no fórum da turma, se você está cursando esta trilha em grupo —, escreva 10 a 15 linhas sobre por que a Web se tornou a plataforma dominante de aplicações — pense em distribuição (não precisa instalar nada), padrões abertos e compatibilidade entre dispositivos. Se puder, compare sua resposta com a de outra pessoa que esteja estudando o mesmo conteúdo.

Critério de pronto: os dois arquivos abrem sem erro de codificação; as duas capturas mostram o ambiente funcionando; o tema tem cinco páginas nomeadas.

Guarde: os arquivos .html e as capturas na pasta exercicios/aula01/ — a partir da Aula 15 tudo isso passa a viver em um repositório Git.

✅ Checkpoint do projeto¶

Ao fim desta aula, na sua máquina:

• [ ] Pasta introducao-web/ criada com site-evento/, meu-projeto/ e exercicios/.
• [ ] site-evento/index.html com a estrutura mínima (doctype, lang="pt-BR", charset, viewport, title, um <h1> e parágrafos).
• [ ] meu-projeto/index.html com o mesmo esqueleto e o seu tema.
• [ ] Live Server instalado e abrindo as páginas em http://127.0.0.1:5500/.
• [ ] Prettier instalado, com format on save ativado.
• [ ] DevTools explorado: você já editou o DOM na aba Elements, rodou document.title no Console e viu um 200 e um 404 na aba Network.
• [ ] Tema do projeto autoral escolhido e as cinco páginas nomeadas.

📚 Para aprofundar¶

• MDN — Aprenda desenvolvimento web (índice geral, em português): https://developer.mozilla.org/pt-BR/docs/Learn_web_development — comece por "Primeiros passos".
• 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 §3 e da §4 desta aula.
• MDN — Visão geral do HTTP: https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Overview — leia a parte sobre requisições e respostas.
• 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 §5.
• web.dev — Learn HTML (em inglês): https://web.dev/learn/html — o primeiro capítulo, "Overview of HTML", prepara a Aula 02.
• CERN — O primeiro site da Web: http://info.cern.ch/ — abra e veja a §2 ao vivo.
• SILVA, Maurício Samy. Criando sites com HTML: sites de alta qualidade com HTML e CSS. Novatec, 2008 — capítulo 1.
• TERUEL, Evandro C. HTML 5 — Guia Prático. Saraiva, 2014 — introdução (disponível na Minha Biblioteca).
• MILETTO, Evandro M.; BERTAGNOLLI, Silvia C. Desenvolvimento de software II. Bookman, 2014 — capítulo sobre arquiteturas para a Web.

Na próxima aula, o HTML entra de verdade: você vai entender cada linha do index.html que criou hoje, aprender os elementos de texto, listas, links e tabelas, e construir a página inicial, a programação e a página de palestrantes do site do evento com HTML semântico e validado no W3C.

🎯 Objetivos de aprendizagem¶

Ao final desta aula você será capaz de:

• Escrever a estrutura mínima de um documento HTML5 válido e explicar a função de cada linha do <head>.
• Aplicar os elementos de texto (títulos, parágrafos, ênfase, citações, quebras) respeitando a hierarquia e o significado de cada um.
• Construir listas ordenadas, não ordenadas, de definição e aninhadas.
• Criar links externos, internos, de âncora, de e-mail, de telefone e de download, com caminhos relativos corretos e atributos de segurança.
• Marcar tabelas de dados com caption, thead/tbody/tfoot, th scope e mesclagem de células.
• Usar HTML semântico (header, nav, main, section, article, aside, footer) em vez de div genérica.
• Validar páginas no validador do W3C e corrigir os erros apontados.

📋 Pré-requisitos¶

• [ ] Pasta introducao-web/ da Aula 01 com site-evento/index.html abrindo no Live Server.
• [ ] VS Code com Live Server e Prettier instalados e format on save ativado.
• [ ] Navegador com DevTools — você vai usar a aba Elements o tempo todo hoje.
• [ ] Tema do projeto autoral definido (entregue na atividade assíncrona da Aula 01).

Na aula passada você viu como a Web funciona por fora: cliente e servidor, URL, HTTP, o caminho de uma requisição até a renderização — e criou um index.html mínimo sem entender cada linha. Hoje você entende cada linha, aprende os elementos de texto, listas, links e tabelas, e constrói três das cinco páginas do site do evento com HTML semântico e validado.

🗺️ Roteiro¶

1. O que é HTML¶

HTML é uma linguagem de marcação, não de programação: ela não tem variáveis, condicionais ou laços. Sua função é descrever a estrutura e o significado do conteúdo por meio de marcas (tags). Você não diz ao navegador "desenhe um retângulo azul aqui"; você diz "isto é um título", "isto é um parágrafo", "isto é uma lista de três itens" — e o navegador (ou o leitor de tela, ou o buscador) decide o que fazer com essa informação.

Essa é a diferença entre HTML e um editor de texto: no Word você formata a aparência; no HTML você declara o que cada coisa é. A aparência é assunto do CSS, a partir da Aula 05.

Anatomia de um elemento¶

<a href="https://github.io" title="Site oficial">GitHub</a>
└┬┘└──────────┬───────────┘ └───────┬───────┘└──┬──┘└─┬─┘
 │            │                     │           │     │
nome      atributo 1            atributo 2   conteúdo tag
da tag                                                de fechamento
└───────────────── tag de abertura ─────────────┘

• Elemento = tag de abertura + conteúdo + tag de fechamento.
• Atributo = informação adicional, sempre na tag de abertura, no formato nome="valor". Use sempre aspas duplas.
• Elementos vazios não têm conteúdo nem fechamento: <br>, <hr>, <img>, <input>, <meta>, <link>.

Os nomes de tags e atributos não diferenciam maiúsculas de minúsculas, mas a convenção universal é tudo em minúsculas. Siga-a.

Aninhamento¶

Elementos podem conter outros, mas precisam ser fechados na ordem inversa da abertura — como parênteses em matemática:

<!-- CORRETO -->
<p>Texto com <strong>destaque <em>duplo</em></strong> aqui.</p>

<!-- ERRADO: fechamento cruzado -->
<p>Texto com <strong>destaque <em>duplo</strong></em> aqui.</p>

O aninhamento é o que transforma o HTML em uma árvore — a mesma árvore que você viu na Aula 01 com o nome de DOM. <p> é pai de <strong>, que é pai de <em>. Todo elemento tem exatamente um pai (exceto <html>, a raiz) e pode ter vários filhos.

🧠 Você sabia? O navegador nunca se recusa a exibir um HTML "errado". A especificação da WHATWG descreve, passo a passo, como o parser deve se recuperar de cada tipo de erro: uma tag cruzada é reorganizada, um </li> esquecido é inserido, um <p> aberto dentro de outro <p> fecha o anterior. É por isso que páginas quebradas "funcionam" — e por isso que o resultado às vezes não é o que você escreveu. Aliás, pela especificação, fechar <li>, <p>, <td> e <tr> é opcional; nesta trilha você fecha tudo, sempre, porque código previsível é mais fácil de ler, depurar e manter.

2. Estrutura mínima de um documento¶

exercicios/aula02/modelo.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="Descrição da página em até 160 caracteres.">
  <meta name="author" content="Seu Nome">
  <title>Título que aparece na aba do navegador</title>
  <link rel="stylesheet" href="css/estilo.css">
</head>
<body>
  <!-- Todo conteúdo visível fica aqui -->
  <script src="js/script.js"></script>
</body>
</html>

O <head> é invisível: nada dele aparece na tela. Ele carrega metadados — informações sobre a página para o navegador, os buscadores e as redes sociais. Tudo que o usuário vê fica dentro de <body>.

🔎 Por baixo do capô O quirks mode existe por causa da história: nos anos 1990, cada navegador interpretava CSS de um jeito, e milhões de páginas foram escritas em cima desses bugs. Quando os padrões foram corrigidos, os navegadores precisaram de um jeito de saber se a página era "antiga" (renderiza com os bugs) ou "moderna" (renderiza pelo padrão). O sinal é o <!DOCTYPE>. Sem ele, o navegador assume o pior — e o seu CSS da Unidade 2 vai se comportar de forma estranha sem motivo aparente.

3. Elementos de texto¶

Títulos¶

<h1>Título principal — apenas um por página</h1>
  <h2>Seção</h2>
    <h3>Subseção</h3>
      <h4>Sub-subseção</h4>

⚠️ Atenção Hierarquia de títulos não é escolha de tamanho de fonte — é estrutura de documento. Leitores de tela permitem navegar pulando de título em título, e o Google usa essa hierarquia para entender a página. Nunca pule níveis (h1 direto para h4) e nunca escolha <h3> só porque "ficou menor". Tamanho é assunto do CSS.

Pense nos títulos como o sumário de um livro: <h1> é o título do livro (um só), <h2> são os capítulos, <h3> as seções dentro de cada capítulo. Se você conseguir extrair só os títulos da página e eles formarem um sumário coerente, a hierarquia está certa.

Parágrafos e semântica inline¶

<p>Um parágrafo comum de texto.</p>

<p>
  Este é <strong>importante</strong> e este tem <em>ênfase</em>.
  Este é apenas <b>negrito visual</b> e este é <i>itálico visual</i>.
  <mark>Texto realçado</mark>, <small>letra miúda</small>,
  <del>removido</del> e <ins>inserido</ins>.
  Fórmula: H<sub>2</sub>O e potência: x<sup>2</sup>.
  Código: <code>let x = 10;</code>.
  Atalho: <kbd>Ctrl</kbd> + <kbd>S</kbd>.
</p>

Na prática: use strong e em; deixe b e i para casos específicos. Uma regra simples: se você leria a palavra em voz alta com outro tom, é em; se a informação é importante mesmo lida em tom neutro, é strong.

📌 Vale gravar A diferença entre <strong>/<b> e <em>/<i> é pergunta clássica. Resposta curta: os dois pares têm a mesma aparência padrão, mas só strong e em carregam significado — e significado é o que leitores de tela e buscadores usam.

Citações e quebras¶

<blockquote cite="https://www.w3.org/">
  <p>A força da Web está em sua universalidade.</p>
  <footer>— <cite>Tim Berners-Lee</cite></footer>
</blockquote>

<p>Endereço:<br>Av. dos Ingás, 3001<br>Sinop — MT</p>

<hr>

<pre>
Texto pré-formatado:
    preserva     espaços
    e quebras de linha.
</pre>

• <blockquote> é uma citação em bloco; o atributo cite guarda a URL da fonte (não aparece na tela). <cite> marca o título da obra ou autor citado.
• <q> é a versão inline: <p>Ele disse <q>volto já</q> e sumiu.</p> — o navegador coloca as aspas.
• <br> quebra a linha dentro de um bloco; <hr> é uma quebra temática (mudança de assunto), não uma "linha decorativa".
• <pre> preserva espaços e quebras exatamente como digitados — útil para código e diagramas.

⚠️ Atenção <br> serve para quebras dentro de um bloco de conteúdo (endereços, poemas, letras de música). Usar <br><br> para separar parágrafos é erro — use <p>. O espaçamento entre parágrafos é assunto do CSS.

4. Listas¶

Três tipos, cada um com um significado:

<!-- Lista não ordenada: a ordem dos itens não importa -->
<ul>
  <li>HTML</li>
  <li>CSS</li>
  <li>JavaScript</li>
</ul>

<!-- Lista ordenada: a ordem importa (passos, ranking) -->
<ol>
  <li>Analisar a URL</li>
  <li>Resolver o DNS</li>
  <li>Abrir conexão TCP</li>
</ol>

<!-- Com atributos: numeração romana, começando em 3, decrescente -->
<ol type="I" start="3" reversed>
  <li>Terceiro item</li>
  <li>Segundo item</li>
  <li>Primeiro item</li>
</ol>

<!-- Lista de definições: pares termo → descrição -->
<dl>
  <dt>HTML</dt>
  <dd>Linguagem de marcação que estrutura o conteúdo.</dd>
  <dt>CSS</dt>
  <dd>Linguagem de estilo que define a apresentação.</dd>
</dl>

<!-- Listas aninhadas: o <ul> filho vai DENTRO do <li> pai -->
<ul>
  <li>Front-end
    <ul>
      <li>HTML</li>
      <li>CSS</li>
    </ul>
  </li>
  <li>Back-end</li>
</ul>

A pergunta para escolher entre <ul> e <ol> é: se eu embaralhar os itens, a informação muda? Passos de uma receita, sim → <ol>. Ingredientes, não → <ul>. A lista de definições (<dl>) serve para glossários, metadados ("Autor: Fulano", "Duração: 2 h") e perguntas frequentes.

Um <ul> ou <ol> só pode ter <li> como filhos diretos. Qualquer outra coisa — um <h3>, um <p>, outra lista — vai dentro de um <li>. O validador do W3C avisa quando você erra isso.

5. Links (âncoras)¶

O link é a invenção que dá o "hipertexto" ao HTML. Todos os tipos usam o mesmo elemento, <a>, e mudam só o href:

<a href="https://www.wikipedia.org">Link externo</a>
<a href="contato.html">Link interno relativo</a>
<a href="/sobre.html">Link a partir da raiz</a>
<a href="#secao3">Âncora interna da própria página</a>
<a href="programacao.html#dia-2">Âncora em outra página</a>
<a href="documentos/edital.pdf" download>Baixar edital</a>
<a href="mailto:contato@exemplo.com.br">Enviar e-mail</a>
<a href="tel:+556635111000">Ligar</a>
<a href="https://exemplo.com" target="_blank" rel="noopener noreferrer">
  Abrir em nova aba
</a>

Os caminhos relativos seguem exatamente a tabela da §5 da Aula 01: contato.html é "na mesma pasta", ../index.html é "uma pasta acima", img/logo.png é "na subpasta img".

⚠️ Atenção Segurança: ao usar target="_blank", sempre inclua rel="noopener noreferrer". Sem isso, a página aberta ganha acesso parcial à sua janela original (window.opener) e pode redirecioná-la — um vetor de phishing conhecido como tabnabbing. Navegadores modernos já aplicam noopener por padrão, mas o atributo explícito garante o comportamento em todos.

Âncoras internas¶

Para a âncora funcionar, o destino precisa de um id — e id deve ser único na página:

<a href="#metodologia">Ir para Metodologia</a>

<h2 id="metodologia">Metodologia</h2>
<p>O evento combina palestras e oficinas práticas.</p>

Ao clicar, o navegador rola até o elemento e acrescenta #metodologia à URL — lembre-se da Aula 01: o fragmento nunca é enviado ao servidor. Um link href="#a02-topo" para um id="a02-topo" no cabeçalho dá o clássico "voltar ao topo".

Texto de link¶

Textos de link ruins: "clique aqui", "saiba mais", "link". Um usuário de leitor de tela pode navegar por uma lista só de links — "clique aqui" ali não significa nada. Buscadores também usam o texto do link para entender o destino. Use texto descritivo: "Baixe o edital em PDF", "Veja a programação completa".

6. Tabelas¶

Tabelas são para dados tabulares — informação que faz sentido em linhas e colunas, como notas, horários, preços. Jamais para layout: isso quebra em celular, confunde leitores de tela e é assunto do CSS (Aula 07).

<table>
  <caption>Notas da turma</caption>
  <thead>
    <tr>
      <th scope="col">Aluno</th>
      <th scope="col">A1</th>
      <th scope="col">A2</th>
      <th scope="col">A3</th>
      <th scope="col">Média</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Maria Silva</th>
      <td>8,0</td><td>7,5</td><td>9,0</td><td>8,2</td>
    </tr>
    <tr>
      <th scope="row">João Souza</th>
      <td>6,0</td><td>5,5</td><td>7,0</td><td>6,2</td>
    </tr>
  </tbody>
  <tfoot>
    <tr>
      <th scope="row">Média da turma</th>
      <td>7,0</td><td>6,5</td><td>8,0</td><td>7,2</td>
    </tr>
  </tfoot>
</table>

Mesclagem de células¶

<td colspan="3">Ocupa 3 colunas</td>
<td rowspan="2">Ocupa 2 linhas</td>

colspan estende a célula para a direita; rowspan, para baixo. Cuidado com a contagem: se uma linha tem colspan="3", as linhas seguintes precisam continuar somando o mesmo número de colunas, senão a tabela fica torta e o validador reclama.

Sem CSS, a tabela aparece sem bordas — parece "só texto alinhado". É normal. A Aula 06 coloca as bordas; hoje o que importa é a estrutura estar certa.

7. HTML semântico¶

Antes do HTML5, tudo era <div>. O resultado era a chamada div soup: código ilegível, inacessível e ruim para buscadores. O HTML5 trouxe elementos que dizem o que a região é:

<body>
  <header>
    <h1>Nome do site</h1>
    <nav>
      <ul>
        <li><a href="index.html">Início</a></li>
        <li><a href="sobre.html">Sobre</a></li>
        <li><a href="contato.html">Contato</a></li>
      </ul>
    </nav>
  </header>

  <main>
    <article>
      <header>
        <h2>Título do artigo</h2>
        <p>Publicado em <time datetime="2030-10-14">14 de outubro</time></p>
      </header>
      <section>
        <h3>Primeira seção</h3>
        <p>Texto da primeira seção do artigo.</p>
      </section>
      <footer>Autor: Maria Silva</footer>
    </article>

    <aside>
      <h3>Conteúdo relacionado</h3>
      <p>Links, publicidade, biografia do autor.</p>
    </aside>
  </main>

  <footer>
    <p>&copy; Nome do site — Todos os direitos reservados</p>
  </footer>
</body>

Repare que <header> e <footer> podem aparecer mais de uma vez: um para o site, outro dentro de cada <article>. Só <main> é único.

💡 Dica Teste da semântica: se você trocar todo o seu CSS por um arquivo vazio, a página ainda faz sentido lida de cima a baixo? Se sim, sua semântica está boa. É exatamente o que um leitor de tela e um buscador "veem".

Para decidir entre <section> e <article>: pergunte se o trecho faria sentido publicado sozinho, em outro site. Um palestrante com nome, bio e foto, sim → <article>. A seção "Sobre o evento" da página inicial só faz sentido dentro dela → <section>.

🔬 Investigue Crie exercicios/aula02/minimo.html contendo só a linha <p>Oi — sem doctype, sem <html>, sem <body>, sem fechar o <p>. Abra no Live Server e vá à aba Elements do DevTools. O navegador construiu <html>, <head>, <body> e fechou o <p> sozinho: você está vendo o DOM, não o arquivo. Agora acrescente uma <table> com um <tr> direto dentro (sem <tbody>) e olhe de novo: o <tbody> aparece no DOM sem você ter escrito. Quando o JavaScript da Unidade 3 percorrer a árvore, é essa árvore que ele vai encontrar.

Entidades HTML¶

Alguns caracteres têm significado especial no HTML e precisam ser escapados:

Com <meta charset="UTF-8">, acentos, © e — podem ser digitados diretamente. As entidades que você precisa usar são as três primeiras — sem elas, o navegador acha que < abre uma tag e & inicia uma entidade.

8. Validação no W3C¶

O validador (https://validator.w3.org/) é o corretor ortográfico do HTML. Ele compara o seu código com a especificação e lista cada erro com a linha exata. Três formas de usar:

1. Validate by URI — para sites já publicados.
2. Validate by File Upload — envie o arquivo .html.
3. Validate by Direct Input — cole o código. É a forma mais rápida durante a aula.

A meta é sempre a mesma mensagem: "Document checking completed. No errors or warnings to show."

Erros são listados na ordem em que ocorrem, e um erro costuma causar vários: uma tag não fechada no início gera dezenas de mensagens depois. Corrija o primeiro, revalide, repita.

💻 Mão na massa — Início, programação e palestrantes do site do evento¶

Hoje o index.html da Aula 01 vira uma página de verdade, e nascem programacao.html e palestrantes.html. As páginas inscricao.html e contato.html ganham só o esqueleto — elas são o assunto da Aula 03.

Passo 1 — O <head> completo da página inicial¶

Abra site-evento/index.html e substitua o <head>:

site-evento/index.html (trecho: <head>)

<!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="Semana Acadêmica de Sistemas de Informação: três dias de palestras, minicursos e oficinas para estudantes e profissionais de tecnologia.">
  <meta name="author" content="Semana Acadêmica de Sistemas de Informação">
  <title>Início — Semana Acadêmica de Sistemas de Informação</title>
</head>

O <title> segue o padrão "Página — Nome do site": é assim que ele aparece na aba e no histórico.

Passo 2 — Cabeçalho e navegação¶

O cabeçalho é idêntico nas cinco páginas — é o que faz o site parecer um site. Escreva uma vez, com capricho, e copie nas outras.

site-evento/index.html (trecho: início do <body>)

<body>
  <header id="topo">
    <h1>Semana Acadêmica de Sistemas de Informação</h1>
    <p>Três noites de outubro · Auditório Central</p>
    <nav>
      <ul>
        <li><a href="index.html">Início</a></li>
        <li><a href="programacao.html">Programação</a></li>
        <li><a href="inscricao.html">Inscrição</a></li>
        <li><a href="palestrantes.html">Palestrantes</a></li>
        <li><a href="contato.html">Contato</a></li>
      </ul>
    </nav>
  </header>

Os cinco href são caminhos relativos: todos os arquivos estão na mesma pasta. O id="a02-topo" vai servir para os links "voltar ao topo".

Passo 3 — Conteúdo principal em seções¶

site-evento/index.html (trecho: <main>)

  <main>
    <p>Nesta página:</p>
    <ul>
      <li><a href="#sobre">Sobre o evento</a></li>
      <li><a href="#como-participar">Como participar</a></li>
      <li><a href="#glossario">Glossário</a></li>
    </ul>

    <section id="sobre">
      <h2>Sobre o evento</h2>
      <p>
        A Semana Acadêmica de Sistemas de Informação reúne estudantes, professores e
        profissionais de tecnologia da região norte de Mato Grosso em três dias de
        <strong>palestras, minicursos e oficinas práticas</strong>. O evento é
        <em>gratuito</em> e aberto à comunidade.
      </p>
      <p>
        Nesta edição, o tema central é <q>Desenvolvimento web para problemas reais</q>:
        cada atividade parte de um caso concreto — do agronegócio à saúde pública —
        e mostra como HTML, CSS e JavaScript resolvem parte dele.
      </p>
      <p>Emitimos certificado de <strong>20 horas</strong> para quem participar de pelo menos 75% das atividades.</p>
      <p><a href="#topo">Voltar ao topo</a></p>
    </section>

    <section id="como-participar">
      <h2>Como participar</h2>
      <ol>
        <li>Leia a <a href="programacao.html">programação</a> e escolha as atividades.</li>
        <li>Preencha o <a href="inscricao.html">formulário de inscrição</a>.</li>
        <li>Confira o e-mail de confirmação (verifique a caixa de spam).</li>
        <li>No primeiro dia, faça o credenciamento no saguão do auditório a partir das 18h30.</li>
        <li>Participe, assine a lista de presença e receba o certificado por e-mail.</li>
      </ol>
      <p><a href="#topo">Voltar ao topo</a></p>
    </section>

    <section id="glossario">
      <h2>Glossário</h2>
      <dl>
        <dt>Palestra</dt>
        <dd>Apresentação expositiva de 50 minutos, com perguntas ao final.</dd>
        <dt>Minicurso</dt>
        <dd>Atividade prática de 3 horas, com computador, para até 30 participantes.</dd>
        <dt>Oficina</dt>
        <dd>Atividade curta (90 minutos) em que os participantes constroem algo juntos.</dd>
        <dt>Mesa-redonda</dt>
        <dd>Conversa entre três ou quatro convidados mediada por um professor do curso.</dd>
        <dt>Credenciamento</dt>
        <dd>Confirmação de presença e retirada do crachá no primeiro dia.</dd>
      </dl>
      <p><a href="#topo">Voltar ao topo</a></p>
    </section>

    <blockquote cite="https://www.w3.org/">
      <p>A força da Web está em sua universalidade. O acesso por todos, independentemente de deficiência, é um aspecto essencial.</p>
      <footer>— <cite>Tim Berners-Lee</cite>, criador da Web</footer>
    </blockquote>
  </main>

Cada <section> tem um <h2> — regra de ouro: seção sem título provavelmente deveria ser um <div>. Os id dos <section> alimentam a lista "Nesta página" e as âncoras funcionam sem uma linha de CSS ou JavaScript.

Passo 4 — Rodapé¶

site-evento/index.html (trecho: <footer> e fechamento)

  <footer>
    <p>Realização: Comissão Organizadora da Semana Acadêmica de Sistemas de Informação.</p>
    <p>
      <a href="mailto:contato@semanasi.com.br">contato@semanasi.com.br</a> ·
      <a href="tel:+556635111000">(66) 3511-1000</a>
    </p>
    <p>&copy; Semana Acadêmica de Sistemas de Informação. Todos os direitos reservados.</p>
  </footer>
</body>
</html>

Salve e olhe o Live Server: uma página sem estilo, mas com estrutura clara. Clique nos links "Nesta página" e "Voltar ao topo" e observe o # na URL.

Passo 5 — A página de programação¶

Crie site-evento/programacao.html. Copie o <head> (trocando o <title> e a description) e o <header> inteiro do index.html. O <main> é uma tabela:

site-evento/programacao.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="Programação completa da Semana Acadêmica de Sistemas de Informação: horários, atividades e locais dos três dias.">
  <meta name="author" content="Semana Acadêmica de Sistemas de Informação">
  <title>Programação — Semana Acadêmica de Sistemas de Informação</title>
</head>
<body>
  <header id="topo">
    <h1>Semana Acadêmica de Sistemas de Informação</h1>
    <p>Três noites de outubro · Auditório Central</p>
    <nav>
      <ul>
        <li><a href="index.html">Início</a></li>
        <li><a href="programacao.html">Programação</a></li>
        <li><a href="inscricao.html">Inscrição</a></li>
        <li><a href="palestrantes.html">Palestrantes</a></li>
        <li><a href="contato.html">Contato</a></li>
      </ul>
    </nav>
  </header>

  <main>
    <h2>Programação</h2>
    <p>Todas as atividades acontecem no período noturno. Minicursos exigem inscrição prévia e têm vagas limitadas.</p>

    <table>
      <caption>Programação dos três dias do evento</caption>
      <thead>
        <tr>
          <th scope="col">Horário</th>
          <th scope="col">Atividade</th>
          <th scope="col">Responsável</th>
          <th scope="col">Local</th>
        </tr>
      </thead>
      <tbody id="dia-1">
        <tr>
          <th colspan="4" scope="colgroup">Dia 1</th>
        </tr>
        <tr>
          <th scope="row"><time datetime="18:30">18h30</time></th>
          <td>Credenciamento</td>
          <td>Comissão organizadora</td>
          <td>Saguão</td>
        </tr>
        <tr>
          <th scope="row"><time datetime="19:00">19h00</time></th>
          <td>Abertura e palestra magna: o futuro do desenvolvimento web</td>
          <td>Eduarda Ribeiro</td>
          <td>Auditório Central</td>
        </tr>
        <tr>
          <th scope="row"><time datetime="20:00">20h00</time></th>
          <td>Minicurso: Git e GitHub do zero</td>
          <td>Diego Nascimento</td>
          <td>Laboratório 2</td>
        </tr>
        <tr>
          <th scope="row"><time datetime="21:00">21h00</time></th>
          <td>Dashboards que os produtores realmente usam</td>
          <td>Bruno Takahashi</td>
          <td>Auditório Central</td>
        </tr>
      </tbody>
      <tbody id="dia-2">
        <tr>
          <th colspan="4" scope="colgroup">Dia 2</th>
        </tr>
        <tr>
          <th scope="row"><time datetime="19:00">19h00</time></th>
          <td>Minicurso: acessibilidade na prática</td>
          <td>Diego Nascimento</td>
          <td>Laboratório 1</td>
        </tr>
        <tr>
          <th scope="row"><time datetime="19:00">19h00</time></th>
          <td>Minicurso: primeiros passos com redes neurais</td>
          <td>Ana Lúcia Ferreira</td>
          <td>Laboratório 3</td>
        </tr>
        <tr>
          <th scope="row"><time datetime="20:30">20h30</time></th>
          <td>Segurança em aplicações web: dez erros comuns</td>
          <td>Carla Mendes</td>
          <td>Auditório Central</td>
        </tr>
        <tr>
          <th scope="row"><time datetime="21:30">21h30</time></th>
          <td colspan="3">Confraternização com coffee break — saguão</td>
        </tr>
      </tbody>
      <tbody id="dia-3">
        <tr>
          <th colspan="4" scope="colgroup">Dia 3</th>
        </tr>
        <tr>
          <th scope="row"><time datetime="18:30">18h30</time></th>
          <td>Maratona de programação</td>
          <td>Eduarda Ribeiro</td>
          <td>Laboratórios 1 e 2</td>
        </tr>
        <tr>
          <th scope="row"><time datetime="19:00">19h00</time></th>
          <td>Minicurso: phishing e engenharia social</td>
          <td>Carla Mendes</td>
          <td>Laboratório 3</td>
        </tr>
        <tr>
          <th scope="row"><time datetime="22:00">22h00</time></th>
          <td>Encerramento e premiação</td>
          <td>Eduarda Ribeiro</td>
          <td>Auditório Central</td>
        </tr>
      </tbody>
      <tfoot>
        <tr>
          <td colspan="4">Programação sujeita a alterações. Consulte esta página na véspera de cada dia.</td>
        </tr>
      </tfoot>
    </table>

    <p><a href="#topo">Voltar ao topo</a></p>
  </main>

  <footer>
    <p>Realização: Comissão Organizadora da Semana Acadêmica de Sistemas de Informação.</p>
    <p>
      <a href="mailto:contato@semanasi.com.br">contato@semanasi.com.br</a> ·
      <a href="tel:+556635111000">(66) 3511-1000</a>
    </p>
    <p>&copy; Semana Acadêmica de Sistemas de Informação. Todos os direitos reservados.</p>
  </footer>
</body>
</html>

Três detalhes importantes nessa tabela:

• Um <tbody> por dia, cada um com id. Isso permite links diretos como programacao.html#dia-2 a partir de outras páginas.
• A linha de título de cada dia usa <th colspan="4">: uma célula ocupa as quatro colunas. Note que a linha da confraternização tem <th> + <td colspan="3"> — somando 4 de novo.
• O <tfoot> carrega a observação final. Sem CSS ele aparece no fim, onde deve.

Passo 6 — A página de palestrantes¶

site-evento/palestrantes.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="Conheça os palestrantes e ministrantes da Semana Acadêmica de Sistemas de Informação.">
  <meta name="author" content="Semana Acadêmica de Sistemas de Informação">
  <title>Palestrantes — Semana Acadêmica de Sistemas de Informação</title>
</head>
<body>
  <header id="topo">
    <h1>Semana Acadêmica de Sistemas de Informação</h1>
    <p>Três noites de outubro · Auditório Central</p>
    <nav>
      <ul>
        <li><a href="index.html">Início</a></li>
        <li><a href="programacao.html">Programação</a></li>
        <li><a href="inscricao.html">Inscrição</a></li>
        <li><a href="palestrantes.html">Palestrantes</a></li>
        <li><a href="contato.html">Contato</a></li>
      </ul>
    </nav>
  </header>

  <main>
    <h2>Palestrantes e ministrantes</h2>
    <p>Convidados desta edição, em ordem alfabética. Os demais entram na Aula 04, quando a página ganhar fotos.</p>

    <article id="ana-lucia-ferreira">
      <h3>Ana Lúcia Ferreira</h3>
      <p><strong>Professora e pesquisadora</strong> na área de inteligência artificial.</p>
      <p>Pesquisa redes neurais aplicadas à previsão de safra de soja e coordena um grupo de estudos em aprendizado de máquina.</p>
      <dl>
        <dt>Atividades</dt>
        <dd><a href="programacao.html#dia-2">Minicurso: primeiros passos com redes neurais</a> (dia 2)</dd>
        <dt>Contato</dt>
        <dd><a href="https://www.linkedin.com/" target="_blank" rel="noopener noreferrer">Perfil no LinkedIn</a></dd>
      </dl>
    </article>

    <article id="bruno-takahashi">
      <h3>Bruno Takahashi</h3>
      <p><strong>Cientista de dados</strong> na startup AgroData, especialista em visualização de dados.</p>
      <p>Constrói painéis que produtores rurais realmente usam no dia a dia e escreve sobre dados abertos e cidades inteligentes.</p>
      <dl>
        <dt>Atividades</dt>
        <dd><a href="programacao.html#dia-1">Dashboards que os produtores realmente usam</a> (dia 1)</dd>
        <dd><a href="programacao.html#dia-3">Dados abertos e cidades inteligentes</a> (dia 3)</dd>
        <dt>Contato</dt>
        <dd><a href="https://github.com/" target="_blank" rel="noopener noreferrer">Perfil no GitHub</a></dd>
      </dl>
    </article>

    <article id="carla-mendes">
      <h3>Carla Mendes</h3>
      <p><strong>Pesquisadora em segurança da informação</strong> na UFMT.</p>
      <p>Estuda a relação entre experiência de uso e ataques de engenharia social, e treina equipes de desenvolvimento em segurança.</p>
      <dl>
        <dt>Atividades</dt>
        <dd><a href="programacao.html#dia-2">Segurança em aplicações web: dez erros comuns</a> (dia 2)</dd>
        <dd><a href="programacao.html#dia-3">Minicurso: phishing e engenharia social</a> (dia 3)</dd>
        <dt>Contato</dt>
        <dd><a href="mailto:carla@exemplo.com">carla@exemplo.com</a></dd>
      </dl>
    </article>

    <p><a href="#topo">Voltar ao topo</a></p>
  </main>

  <footer>
    <p>Realização: Comissão Organizadora da Semana Acadêmica de Sistemas de Informação.</p>
    <p>
      <a href="mailto:contato@semanasi.com.br">contato@semanasi.com.br</a> ·
      <a href="tel:+556635111000">(66) 3511-1000</a>
    </p>
    <p>&copy; Semana Acadêmica de Sistemas de Informação. Todos os direitos reservados.</p>
  </footer>
</body>
</html>

Cada palestrante é um <article>: faria sentido sozinho em outro site. Os títulos são <h3> porque estão abaixo do <h2> "Palestrantes e ministrantes" — hierarquia respeitada. Os links para programacao.html#dia-2 combinam caminho relativo com fragmento.

Passo 7 — Esqueleto das páginas restantes¶

Para o menu não levar a um 404, crie inscricao.html e contato.html com o <head>, o <header> e o <footer> copiados, e um <main> mínimo:

site-evento/inscricao.html (trecho: <main>)

  <main>
    <h2>Inscrição</h2>
    <p>O formulário de inscrição será construído na próxima aula.</p>
  </main>

Faça o mesmo em contato.html, trocando o título para "Contato". Ajuste o <title> e a description de cada uma.

Passo 8 — Validar as cinco páginas¶

Abra https://validator.w3.org/#validate_by_input, cole o código de cada página e corrija até ver "No errors or warnings to show". Faça isso nas cinco. É a última etapa de toda aula da Unidade 1.

Como testar¶

• As cinco páginas abrem no Live Server e o menu leva de uma para outra sem 404.
• Em index.html, os links "Nesta página" rolam até a seção e a URL ganha #sobre, #como-participar, #glossario.
• Em palestrantes.html, clicar em "Minicurso: primeiros passos com redes neurais" abre programacao.html já posicionada no Dia 2.
• Na aba Elements, a tabela mostra três <tbody> e um <tfoot>; cada <tr> soma 4 colunas.
• O validador não acusa nenhum erro em nenhuma das cinco páginas.

Resultado esperado: um site de cinco páginas, sem estilo, navegável, com hierarquia de títulos correta, tabela de programação estruturada e zero erros no W3C. Ele parece "feio" — e vai continuar assim até a Aula 05. O que importa agora é a estrutura.

🧪 Laboratório¶

Nível A — Fixação¶

Os itens A1 a A6 revisam a arquitetura da Aula 01; os demais são sobre o HTML de hoje.

A1. Diferencie as camadas de apresentação, aplicação e dados, dizendo onde cada uma executa.

A2. Um blog cujo conteúdo vem de um banco de dados MySQL é estático ou dinâmico? Justifique.

A3. Explique a diferença fundamental entre MPA e SPA em uma frase para cada.

A4. Qual verbo HTTP você usaria para: (a) listar produtos; (b) cadastrar um cliente; (c) excluir um pedido; (d) atualizar o preço de um item?

A5. Classifique cada código como erro de cliente ou de servidor: 403, 500, 404, 502, 400, 503.

A6. O que acontece com uma página HTML que não declara <!DOCTYPE html>?

A7. Corrija os erros do trecho abaixo (há pelo menos quatro):

<p>Texto <strong>importante <em>e enfático</strong></em>.
<a href=programacao.html>Programação</a>
<ul>
  <li>Um
  <li>Dois
</ul>

A8. Qual a diferença semântica entre <strong> e <b>? E entre <em> e <i>?

A9. Escreva o HTML de uma lista não ordenada com 3 itens, sendo que o segundo contém uma sublista ordenada com 2 itens.

A10. Escreva um link que abra https://www.wikipedia.org em nova aba, com os atributos de segurança corretos.

A11. O que faz o atributo scope em um <th>?

A12. Escreva o HTML de uma célula que ocupe 3 colunas e outra que ocupe 2 linhas.

A13. Para cada situação, indique o elemento semântico mais adequado: (a) menu principal; (b) uma notícia completa; (c) barra lateral de links relacionados; (d) rodapé com copyright; (e) imagem com legenda; (f) conteúdo principal da página.

A14. Por que <main> deve aparecer apenas uma vez por página?

A15. Escreva as entidades HTML para: <, >, &, © e espaço não separável.

A16. O que é um elemento vazio? Cite quatro.

Nível B — Aplicação¶

B1. Crie exercicios/aula02/curriculo.html — um currículo pessoal completo usando apenas HTML semântico, sem nenhum CSS. Deve conter: dados pessoais no <header>; seções de formação, experiência, habilidades e projetos; listas apropriadas em cada uma (ordenada onde a cronologia importa); uma tabela de idiomas com nível; links para e-mail, telefone, LinkedIn e GitHub; <footer>.

Resultado esperado: validador do W3C com zero erros; a hierarquia h1 → h2 sem pulos; os links mailto: e tel: funcionando.

B2. Escreva o HTML (sem CSS) de uma página de notícia com: cabeçalho do site, navegação, artigo com título, subtítulo, data em <time>, autor, cinco parágrafos, uma citação em destaque, uma seção de "leia também" em <aside> e rodapé do artigo com as tags do assunto.

Resultado esperado: um <article> com <header> e <footer> próprios, além do <header> e <footer> do site; o <aside> fora do <article>; zero erros no validador.

B3. Reproduza em HTML a tabela com a sequência das 15 aulas desta trilha (está na Aula 01), usando <caption>, <thead>, <tbody> e <th scope> corretamente. Mescle células nas linhas que fecham unidade (06, 10, 15) para indicar "Marco do projeto".

Resultado esperado: uma tabela de 15 linhas de dados, três <th scope="row"> de marco mesclados com colspan, e cada linha somando o mesmo número de colunas.

B4. Pegue o trecho abaixo (div soup) e reescreva-o inteiramente com HTML5 semântico:

<div id="topo">
  <div class="titulo">Blog do Curso</div>
  <div class="menu"><div><a href="#">Home</a></div><div><a href="#">Posts</a></div></div>
</div>
<div id="conteudo">
  <div class="post">
    <div class="titulo-post">Como estudar programação</div>
    <div class="data">14 de outubro</div>
    <div class="texto">Estudar programação exige prática diária e projetos pequenos que cresçam aos poucos.</div>
  </div>
</div>
<div id="rodape">Copyright Semana Acadêmica de Sistemas de Informação</div>

Resultado esperado: zero <div> no resultado; <header>, <nav> com <ul>, <main>, <article> com <h2> e <time datetime>, <footer> com ©.

B5. Construa um índice navegável: uma página longa com 6 seções, cada uma com id, e um menu no topo com links de âncora para cada seção. Ao final de cada seção, inclua um link "voltar ao topo".

Resultado esperado: clicar em cada item do menu rola até a seção certa e a URL muda para #id-da-secao; "voltar ao topo" funciona em todas.

B6. Compare arquiteturas: escolha três sistemas que você usa (por exemplo SIGAA, Instagram e um blog pessoal) e produza uma tabela HTML classificando cada um quanto a: estático/dinâmico, MPA/SPA e quantas camadas você supõe existirem. Justifique cada classificação com uma evidência observável (comportamento ao navegar, aba Network).

Resultado esperado: uma <table> com <caption>, <thead> e três linhas de dados, seguida de um parágrafo de justificativa por sistema.

B7. Use o validador do W3C em três sites reais e registre quantos erros e avisos cada um apresenta. Escolha um erro de cada site, explique o que significa e como corrigir.

Resultado esperado: uma lista com site, número de erros, número de avisos, o texto literal de um erro e a correção proposta.

B8. Página institucional de um curso. Construa exercicios/aula02/curso.html, uma página sobre um curso técnico ou de graduação — o seu, se você estiver cursando um, ou o curso de Sistemas de Informação de uma universidade à sua escolha, como no exemplo a seguir —, contendo obrigatoriamente: estrutura completa do documento com todas as <meta> vistas; <header> com <h1> e <nav> com 4 links de âncora interna; <main> com três <section>, cada uma com <h2> e conteúdo; uma lista ordenada com as etapas do ciclo requisição-resposta (Aula 01); uma lista de definições com 5 termos técnicos da Aula 01; uma tabela com a grade de uma fase do curso (disciplina, carga horária, professor); um <blockquote> com citação e <cite>; <footer> com direitos autorais usando ©.

Resultado esperado: zero erros no validador; os 4 links de âncora funcionando; a tabela com <caption>, <thead> e <th scope>.

Nível C — Desafio¶

C1. Site institucional de 4 páginas. Construa, em exercicios/aula02/curso/, um site sobre um curso técnico ou de graduação — o seu, ou o curso de Sistemas de Informação de uma universidade pública à sua escolha (a grade curricular costuma estar disponível no site da instituição) — com quatro páginas interligadas: index.html (apresentação), grade.html (tabela com a grade curricular completa), corpo-docente.html (lista de professores com formação) e contato.html (endereço, telefone, e-mail e mapa em link). Requisitos: navegação idêntica em todas as páginas; caminhos relativos corretos; HTML5 semântico; zero erros no validador; nomes de arquivos em minúsculas sem acentos. Sem CSS ainda — este site será estilizado nas Aulas 05 e 06.

🏆 Desafios¶

<html>
<head>
  <title>Semana de SI</title>
  <meta charset="UTF-8">
</head>
<body>
  <h1>Semana Acadêmica</h1>
  <h1>Programação</h1>
  <h4>Dia 1</h4>
  <p>Palestra de abertura com <strong>convidada <em>especial</strong></em>.</p>
  <p>Para se inscrever, <a href="inscricao.html" target="_blank">clique aqui</a>.<br><br>
  As vagas são limitadas.</p>
  <ul>
    <li>Minicursos</li>
    <ul>
      <li>HTML e CSS</li>
    </ul>
    <li>Oficinas</li>
  </ul>
  <table>
    <tr><td>Horário</td><td>Atividade</td></tr>
    <tr><td>19h</td><td colspan="3">Abertura</td></tr>
  </table>
</body>
</html>

🐛 Erros comuns¶

🏠 Para praticar depois da aula (1 h)¶

Parte 1 — Leitura (20 min). SILVA, M. S. Criando sites com HTML, capítulos sobre estrutura do documento e elementos de texto. TERUEL, E. C. HTML5 — Guia Prático, capítulo introdutório. Anote um elemento HTML que apareceu na leitura e não nesta aula, e pesquise o que ele faz na MDN.

Parte 2 — Produção (30 min). Produza o exercício B1 (currículo em HTML semântico), em arquivo .html, acompanhado de captura de tela do validador W3C mostrando "Document checking completed. No errors or warnings to show."

No projeto autoral: replique no seu meu-projeto/ o que o site do evento ganhou hoje — index.html completo (cabeçalho, navegação com as cinco páginas, três seções com <h2>, uma lista ordenada, uma lista de definições, um <blockquote>, rodapé), mais uma página com uma tabela de dados do seu domínio e uma página com <article> por item (o equivalente aos palestrantes).

Parte 3 — Registro (10 min). Escreva, no seu repositório ou no fórum da turma (se houver), uma nota "Semântica importa": encontre um site real com problemas de semântica (uso excessivo de div, títulos fora de ordem, links "clique aqui") e descreva três problemas encontrados com a correção proposta para cada. Se puder, compare com o que outra pessoa encontrou.

Critério de pronto: o currículo e as três páginas do projeto autoral passam no validador com zero erros; a navegação do projeto autoral não leva a nenhum 404.

Guarde: curriculo.html, a captura do validador e a pasta meu-projeto/ — a partir da Aula 15 tudo isso vai para um repositório Git.

✅ Checkpoint do projeto¶

Ao fim desta aula, em site-evento/:

• [ ] index.html com <head> completo (charset, viewport, description, author, title) e <header> com <h1> e <nav> de cinco links.
• [ ] index.html com três <section> (#sobre, #como-participar, #glossario), uma <ol>, uma <dl>, um <blockquote> com <cite> e um <footer> com mailto:, tel: e ©.
• [ ] programacao.html com tabela completa: <caption>, <thead>, três <tbody> com id, <tfoot>, th scope e colspan.
• [ ] palestrantes.html com um <article> por palestrante, <h3> abaixo do <h2>, <dl> de atividades e links para programacao.html#dia-N.
• [ ] inscricao.html e contato.html com cabeçalho, navegação e rodapé idênticos e <main> mínimo.
• [ ] As cinco páginas com zero erros no validador do W3C.
• [ ] Em meu-projeto/: o mesmo avanço com o seu tema (feito na atividade assíncrona).

📚 Para aprofundar¶

• MDN — Estruturando conteúdo com HTML (curso, em português): https://developer.mozilla.org/pt-BR/docs/Learn_web_development/Core/Structuring_content — os módulos "Estrutura básica", "Títulos e parágrafos", "Links" e "Tabelas" cobrem exatamente esta aula.
• MDN — Referência de elementos HTML: https://developer.mozilla.org/pt-BR/docs/Web/HTML/Element — consulte quando tiver dúvida sobre qualquer tag.
• MDN — O elemento <table>: https://developer.mozilla.org/pt-BR/docs/Web/HTML/Element/table — leia a seção de acessibilidade.
• MDN — O elemento <a>: https://developer.mozilla.org/pt-BR/docs/Web/HTML/Element/a — todos os valores de rel e target.
• web.dev — Learn HTML (em inglês): https://web.dev/learn/html — os capítulos "Document structure", "Semantic HTML", "Headings and sections", "Links" e "Tables".
• Validador do W3C: https://validator.w3.org/ — use em toda página, sempre.
• WHATWG — HTML Living Standard (em inglês, referência): https://html.spec.whatwg.org/multipage/ — a seção "Optional tags" explica o "Você sabia?" da §1.
• SILVA, Maurício Samy. Criando sites com HTML: sites de alta qualidade com HTML e CSS. Novatec, 2008 — capítulos 2 a 5.
• TERUEL, Evandro C. HTML 5 — Guia Prático. Saraiva, 2014 — capítulos sobre estrutura e texto (Minha Biblioteca).
• MILETTO, Evandro M.; BERTAGNOLLI, Silvia C. Desenvolvimento de software II. Bookman, 2014 — capítulo sobre arquitetura de aplicações web (para os itens A1–A6).
• W3C — HTML 5.2 Recommendation: https://www.w3.org/TR/html52/ — seções de elementos de seccionamento e conteúdo de texto.

Na próxima aula, a página de inscrição deixa de ser um esqueleto: você vai aprender o elemento <form>, os tipos de <input>, rótulos, agrupamento, validação nativa e a diferença entre GET e POST — e vai ver, na aba Network, os dados do formulário viajando até o servidor.

🎯 Objetivos de aprendizagem¶

Ao final desta aula você será capaz de:

• Explicar o que acontece entre o clique em "Enviar" e a chegada dos dados ao servidor, identificando cada par nome=valor na aba Network do DevTools.
• Decidir entre GET e POST justificando a escolha pelo tipo de operação, pelo tamanho dos dados e pelos riscos de cada método.
• Montar um <form> completo com action, method e os campos adequados a cada dado coletado.
• Escolher o type de <input> certo para cada informação e explicar o ganho prático de cada escolha, principalmente no celular.
• Associar rótulos a campos com <label> (por for/id e na forma envolvente) e agrupar campos relacionados com <fieldset>/<legend>.
• Usar <select>, <optgroup>, <datalist> e <textarea>, sabendo quando cada um é a escolha certa.
• Aplicar a validação nativa do HTML (required, minlength, pattern, min, max, step) e explicar por que ela nunca substitui a validação no servidor.

📋 Pré-requisitos¶

• [ ] Pasta introducao-web/site-evento/ com as cinco páginas da Aula 02 (index.html, programacao.html, inscricao.html, palestrantes.html, contato.html), todas validadas no W3C.
• [ ] VS Code com Live Server e Prettier, e o navegador com DevTools (F12). Hoje você vai passar boa parte da aula na aba Network.
• [ ] Revisar da Aula 02: caminhos relativos, hierarquia de títulos, <nav> como lista e o hábito de validar cada página no W3C.
• [ ] Pasta meu-projeto/ com o tema autoral definido e as páginas equivalentes já criadas.

Na aula passada você aprendeu a marcar conteúdo: textos, listas, links e tabelas, e construiu três das cinco páginas do site do evento com HTML semântico e validado. As páginas inscricao.html e contato.html ficaram só com o esqueleto, esperando esta aula. Hoje elas ganham o elemento que transforma um site em sistema: o formulário — a porta por onde os dados das pessoas entram no seu programa.

🗺️ Roteiro¶

1. Por que formulários importam¶

1.1 A porta de entrada de todo sistema¶

Pense em qualquer sistema web que você usa: SIGAA, internet banking, loja on-line, rede social, portal da prefeitura. Todos têm uma coisa em comum — em algum momento alguém digitou alguma coisa. Login, matrícula, transferência, pedido, comentário, denúncia: tudo entra por um formulário.

Isso faz do formulário o elemento com maior consequência de todo o HTML. Uma tabela mal marcada deixa o site feio para um leitor de tela. Um formulário mal construído:

• Gera dado sujo. Um campo de telefone sem restrição recebe (66) 9 9999-9999, 66999999999, 9999-9999 e me liga no zap. Quem sofre é o banco de dados, o relatório e a pessoa que vai tentar ligar.
• Afasta usuários. Cada campo desnecessário, cada teclado errado no celular, cada erro sem explicação é um motivo para desistir. Formulário longo demais é a principal causa de carrinho abandonado no comércio eletrônico.
• Exclui pessoas. Um campo sem <label> é, para quem usa leitor de tela, apenas "campo de edição, em branco". Sem rótulo, não há como saber o que digitar.
• Cria retrabalho. Todo dado que não foi validado na entrada vira, depois, uma planilha de correção manual.

Nesta aula você constrói a estrutura. Na Aula 04 fecha o ciclo com campos avançados e upload de arquivos. Na Aula 06 estiliza o formulário com CSS. Na Aula 14 acrescenta validação em JavaScript, com expressões regulares e mensagens acessíveis. O formulário de inscrição do evento vai atravessar toda a trilha.

1.2 O que acontece quando você clica em "Enviar"¶

Você já viu na Aula 01 o caminho de uma requisição HTTP. O formulário usa exatamente esse caminho, com um detalhe novo: ele monta a requisição para você.

1. Você preenche os campos e clica no botão de envio.
2. O navegador percorre o formulário e monta uma lista de pares nome=valor,
   usando o atributo name de cada campo preenchido.
3. Se method="get": a lista vira a query string da URL (depois do ?).
   Se method="post": a lista vira o corpo (body) da requisição.
4. O navegador envia a requisição para o endereço do atributo action.
5. O servidor lê os pares, faz o que tem de fazer e devolve uma resposta.
6. O navegador exibe a resposta — normalmente uma página de confirmação.

Repare no passo 2: é o name que vira a chave. Não é o id, não é o texto do <label>, não é o placeholder. Um campo sem name simplesmente não existe do ponto de vista do servidor. Guarde isso; é o erro número um da lista de Erros comuns desta aula.

🧠 Você sabia? Formulários existem na Web desde 1993 — são mais antigos que o CSS, que o JavaScript e que a maioria das pessoas que os usam. Eles apareceram no HTML 2.0 e praticamente não mudaram de sintaxe desde então: um <form> escrito em 1995 ainda funciona hoje, em qualquer navegador. Essa estabilidade tem um nome na Web: compatibilidade retroativa. É por isso que uma página antiga não "para de funcionar" — a plataforma quase nunca remove nada, ela só acrescenta. O preço dessa escolha é conviver com atributos estranhos como enctype, cujo nome só faz sentido quando você conhece a história. O benefício é que o que você aprende hoje continua valendo daqui a dez anos.

2. O elemento <form>¶

Todo formulário começa e termina no elemento <form>. Ele não desenha nada na tela: é o envelope que agrupa os campos, define para onde os dados vão e como viajam.

exemplos/form-minimo.html (trecho)

<form action="/processa-cadastro" method="post">
  <label for="nome">Nome completo</label>
  <input type="text" id="nome" name="nome" required>

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

Três linhas de conteúdo, e já temos um sistema: um rótulo, um campo e um botão que dispara a requisição.

2.1 Atributos do <form>¶

Nesta trilha você ainda não tem um servidor para receber os dados — isso é assunto do Nível 2. Por enquanto, o action aponta para um endereço fictício (/inscrever), e o que interessa é observar a requisição sendo montada no DevTools. O servidor do Live Server vai responder 404 Not Found, e está tudo bem: os dados foram enviados, e é isso que vamos inspecionar.

2.2 GET × POST¶

Essa é a decisão mais importante do <form> — e a que mais confunde quem está começando.

A regra prática: GET para ler, POST para alterar.

Se a operação apenas consulta informação e poderia ser repetida cem vezes sem consequência, use GET. É por isso que a URL de uma busca é compartilhável: programacao.html?dia=2&trilha=web descreve exatamente o que você está vendo, e mandar esse link para outra pessoa mostra a ela a mesma tela. Essa propriedade — repetir sem mudar nada — chama-se idempotência.

Se a operação cria, altera ou apaga alguma coisa, use POST. Uma inscrição feita duas vezes por engano vira duas inscrições. Por isso o navegador avisa antes de reenviar um POST quando você aperta F5.

Como fica a URL de um GET. Um formulário com method="get", action="busca.html" e um campo name="q" preenchido com html leva o navegador para:

busca.html?q=html

Com mais campos, os pares são separados por &:

programacao.html?dia=2&trilha=web&ordem=horario

Caracteres especiais são codificados: um espaço vira + ou %20, o @ vira %40, o acento de programação vira programa%C3%A7%C3%A3o. Esse processo é a codificação de URL (percent-encoding), e o navegador faz tudo sozinho.

⚠️ Atenção Nunca envie senha por GET. Ela ficaria visível na barra de endereço, no histórico do navegador, no cache, nos registros (logs) do servidor e no cabeçalho Referer enviado a sites de terceiros. Já houve vazamento de milhões de senhas exatamente assim. Formulário de login é sempre method="post".

🔎 Por baixo do capô POST não é "seguro" no sentido de escondido: os dados vão no corpo da requisição, em texto puro, e qualquer pessoa com acesso à rede pode lê-los se a conexão for http://. O que protege de verdade é o HTTPS, que cifra a requisição inteira — URL, cabeçalhos e corpo. POST protege dos olhos de quem está do seu lado vendo a tela e do histórico do navegador; o HTTPS protege do resto do mundo. Você vai ver os detalhes do certificado e do cadeado na trilha Deploy; por ora, guarde a distinção entre não aparecer na URL e estar cifrado.

2.3 Vendo os dados viajarem¶

Este é o experimento central da aula. Faça uma vez acompanhando o texto e depois refaça sozinho, sem consultar.

🔬 Investigue Crie um arquivo exemplos/get-vs-post.html com dois formulários idênticos — um com method="get" e outro com method="post", ambos com action="recebe.html" e dois campos (name="usuario" e name="mensagem"). Abra com o Live Server, abra o DevTools na aba Network e marque "Preserve log". Preencha e envie o primeiro: na lista de requisições aparece recebe.html?usuario=maria&mensagem=oi — os dados estão na própria URL, e você os vê também na barra de endereço. Agora envie o segundo: a URL fica limpa; clique na requisição, vá em Payload (ou Requisição, no Firefox) e veja usuario: maria e mensagem: oi. Repita o POST e aperte F5: o navegador pergunta se você quer reenviar os dados. Agora apague o atributo name de um dos campos e envie de novo: o campo some da requisição, mesmo estando preenchido na tela. Esse é o bug mais silencioso dos formulários.

2.4 Um formulário sem servidor ainda ensina¶

Enquanto não existe um back-end, três truques deixam o experimento útil:

1. action vazio (action=""): o formulário envia para a própria página. Com method="get", os dados aparecem na URL e a página recarrega — ótimo para ver a query string sem erro 404.
2. action="recebe.html": crie uma página simples de "recebido com sucesso". Com GET, ela abre com os dados na URL.
3. Aba Network: funciona sempre, mesmo com resposta 404. A requisição saiu; é ela que interessa.

3. Campos de entrada: <input> e seus tipos¶

O <input> é o campo mais versátil do HTML. Ele não tem tag de fechamento (é um elemento vazio) e muda completamente de comportamento conforme o atributo type.

3.1 O catálogo de tipos¶

exemplos/tipos-de-input.html (trecho do <form>)

<input type="text"           name="nome"        id="nome">
<input type="email"          name="email"       id="email">
<input type="password"       name="senha"       id="senha">
<input type="number"         name="idade"       id="idade" min="16" max="120" step="1">
<input type="tel"            name="telefone"    id="telefone">
<input type="url"            name="site"        id="site">
<input type="date"           name="nascimento"  id="nascimento">
<input type="time"           name="horario"     id="horario">
<input type="datetime-local" name="agendamento" id="agendamento">
<input type="month"          name="competencia" id="competencia">
<input type="week"           name="semana"      id="semana">
<input type="search"         name="busca"       id="busca">
<input type="color"          name="cor"         id="cor" value="#0b3d5c">
<input type="range"          name="nota"        id="nota" min="0" max="10" step="0.5">
<input type="file"           name="anexo"       id="anexo" accept=".pdf,.docx">
<input type="checkbox"       name="termos"      id="termos">
<input type="radio"          name="turno"       id="manha" value="manha">
<input type="hidden"         name="origem"      value="site">

Nenhum desses tipos exige uma linha de JavaScript. O navegador entrega calendário, seletor de cor, controle deslizante e validação de formato de graça.

💡 Dica Escolher o type certo não é detalhe estético: no celular, é ele que decide qual teclado aparece. Um campo de telefone com type="text" obriga a pessoa a trocar de teclado antes de digitar — uma fricção pequena que, multiplicada por milhares de usuários, vira abandono. Teste o seu formulário no celular pelo IP do Live Server na mesma rede Wi-Fi: é o teste mais barato de usabilidade que existe.

⚠️ Atenção type="number" serve para quantidades, não para "sequências de dígitos". CPF, CEP, telefone, matrícula e número de cartão não são números: eles têm zeros à esquerda que importam, podem ter pontuação e nunca são somados. Em type="number", o navegador remove zeros à esquerda, mostra setas de incremento sem sentido e permite notação como 1e5. Para esses campos, use type="text" com pattern — e, a partir da Aula 04, com inputmode="numeric" para o teclado certo.

3.2 Atributos essenciais dos campos¶

<label for="nome">Nome completo (obrigatório)</label>
<input type="text" id="nome" name="nome" value="Maria"
       placeholder="Ex.: Maria da Silva"
       required minlength="3" maxlength="80"
       autocomplete="name" autofocus>

Quatro pares que costumam ser confundidos:

• id × name. O id é para a página (ligar o <label>, servir de âncora, ser encontrado pelo JavaScript na Aula 13) e precisa ser único no documento. O name é para o servidor e pode se repetir — é assim que um grupo de caixas de seleção manda vários valores com a mesma chave.
• placeholder × value. O placeholder é um texto cinza que some quando você digita; ele não é enviado. O value é conteúdo de verdade: aparece preenchido e é enviado se não for alterado.
• readonly × disabled. Os dois impedem edição. readonly envia o valor; disabled não envia e também tira o campo da navegação por Tab. Se você precisa que um valor calculado chegue ao servidor, use readonly (ou um hidden), nunca disabled.
• minlength × min. minlength conta caracteres (texto); min compara valores (números e datas). Trocar um pelo outro é um erro clássico: minlength="16" em um campo de idade exige um número de dezesseis dígitos.

🔎 Por baixo do capô O atributo autocomplete não é um simples liga/desliga. Ele tem um vocabulário padronizado de mais de cinquenta valores — name, given-name, family-name, email, tel, street-address, postal-code, cc-number, one-time-code — e é isso que permite ao navegador (e ao gerenciador de senhas do celular) preencher um cadastro inteiro em um toque. Preencher autocomplete corretamente é acessibilidade: consta na WCAG 2.1 como critério 1.3.5 ("identificar a finalidade da entrada"), justamente porque reduz a carga de digitação para pessoas com deficiência motora ou cognitiva. Um formulário com autocomplete="off" em tudo, "por segurança", só torna a vida mais difícil — e leva as pessoas a escolherem senhas piores.

4. <label> — obrigatório, não opcional¶

Todo campo precisa de um rótulo associado. Não é recomendação de estilo: é requisito de acessibilidade e de usabilidade — e o checklist de qualidade do Marco do projeto cobra isso.

4.1 As duas formas de associar¶

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

<!-- Forma 2: o <label> envolve o campo -->
<label>
  E-mail institucional
  <input type="email" name="email">
</label>

A forma 1 é a preferida porque separa rótulo e campo no HTML — o que dá liberdade total ao CSS para colocá-los lado a lado, um acima do outro ou em colunas, sem lutar contra a estrutura. Ela também é a única que funciona quando o rótulo está em outra célula de uma tabela ou em outro contêiner.

A forma 2 dispensa id e é útil em casos pequenos, especialmente caixas de seleção dentro de uma lista. Cuidado: se você usar as duas ao mesmo tempo (<label for="x"> envolvendo o campo de id="a03-x"), o for precisa apontar para esse mesmo campo, senão o validador acusa erro.

4.2 Por que o rótulo é obrigatório¶

1. Acessibilidade. Ao focar um campo, o leitor de tela anuncia o rótulo: "E-mail institucional, campo de edição". Sem <label>, a pessoa ouve apenas "campo de edição" e não tem como saber o que digitar.
2. Usabilidade para todo mundo. Clicar no rótulo foca o campo. Em uma caixa de seleção de 16 × 16 pixels, o rótulo multiplica por dez a área clicável — a diferença entre acertar e errar o toque no celular.
3. Clareza permanente. O rótulo continua visível depois que a pessoa digitou. O placeholder, não.

⚠️ Atenção placeholder não é <label>. Ele desaparece assim que a pessoa começa a digitar (e quem se distraiu no meio do preenchimento não sabe mais o que aquele campo pedia), costuma ter contraste baixo demais para a WCAG, não é lido de forma confiável por todas as tecnologias assistivas e, em campos preenchidos automaticamente, some sem nunca ter sido lido. Use placeholder só para exemplo de formato ("Ex.: 78550-000") — e sempre além do rótulo, nunca no lugar dele.

4.3 Marcando campos obrigatórios¶

Marcar obrigatoriedade só com um asterisco vermelho falha duas vezes: quem não enxerga a cor não percebe, e quem usa leitor de tela ouve "asterisco". Faça assim:

<label for="nome">Nome completo (obrigatório)</label>
<input type="text" id="nome" name="nome" required minlength="5" maxlength="100"
       autocomplete="name">

O texto "(obrigatório)" no rótulo é lido por todos. O atributo required faz o navegador barrar o envio e, de quebra, é anunciado pelos leitores de tela como "obrigatório". E, no rodapé do formulário, uma frase explicando a convenção resolve o resto: "Os campos marcados como obrigatórios precisam ser preenchidos".

5. Os outros campos¶

5.1 <textarea> — texto longo¶

<label for="mensagem">Mensagem</label>
<textarea id="mensagem" name="mensagem" rows="6" cols="40"
          maxlength="500" placeholder="Escreva sua mensagem"></textarea>

• rows e cols definem o tamanho inicial em linhas e colunas de caractere; o CSS pode sobrescrever (Aula 06).
• maxlength limita os caracteres, exatamente como no <input>.

⚠️ Atenção <textarea> não usa o atributo value: o conteúdo inicial vai entre as tags. E tudo que estiver ali dentro — inclusive espaços e quebras de linha de indentação — vira conteúdo do campo. Escreva sempre <textarea></textarea> colado quando o campo deve começar vazio. Um <textarea> "indentado bonitinho" nasce com espaços em branco dentro, e um required passa a aceitar um campo que parece vazio.

5.2 <select> — escolha em lista fechada¶

<label for="curso">Curso</label>
<select id="curso" name="curso" required>
  <option value="">Selecione o seu curso</option>
  <optgroup label="Computação">
    <option value="si">Sistemas de Informação</option>
    <option value="ads">Análise e Desenvolvimento de Sistemas</option>
  </optgroup>
  <optgroup label="Engenharias">
    <option value="civil" selected>Engenharia Civil</option>
    <option value="agro">Engenharia Agronômica</option>
  </optgroup>
  <optgroup label="Outros">
    <option value="outro">Outro curso</option>
  </optgroup>
</select>

Pontos que fazem diferença:

• O value é o que vai para o servidor; o texto entre as tags é o que a pessoa lê. Quando o value é omitido, o próprio texto é enviado.
• A primeira <option> com value="" é o truque que faz required funcionar em um <select>: enquanto ela estiver escolhida, o campo é considerado vazio. Sem ela, o primeiro item já conta como resposta válida — e você recebe "Sistemas de Informação" de quem nunca olhou a lista.
• <optgroup label="…"> agrupa opções. O label é obrigatório e é anunciado pelo leitor de tela.
• selected define a opção inicial. Use com parcimônia: uma resposta pré-marcada é uma resposta que muita gente vai deixar como está.

Seleção múltipla:

<label for="linguagens">Linguagens que você já usou</label>
<select id="linguagens" name="linguagens" multiple size="4">
  <option value="html">HTML</option>
  <option value="css">CSS</option>
  <option value="js">JavaScript</option>
  <option value="python">Python</option>
  <option value="java">Java</option>
</select>

multiple permite escolher vários (com Ctrl ou Shift) e size define quantas opções ficam visíveis. Na prática, um <select multiple> é pouco descoberto pelos usuários: em telas de toque, quase ninguém adivinha como selecionar mais de um. Prefira caixas de seleção quando as opções forem poucas.

5.3 Radio e checkbox¶

<fieldset>
  <legend>Turno de preferência</legend>

  <input type="radio" id="matutino" name="turno" value="matutino" checked>
  <label for="matutino">Matutino</label>

  <input type="radio" id="vespertino" name="turno" value="vespertino">
  <label for="vespertino">Vespertino</label>

  <input type="radio" id="noturno" name="turno" value="noturno">
  <label for="noturno">Noturno</label>
</fieldset>

<fieldset>
  <legend>Oficinas de interesse</legend>

  <input type="checkbox" id="of-git" name="oficinas" value="git">
  <label for="of-git">Git e GitHub do zero</label>

  <input type="checkbox" id="of-api" name="oficinas" value="api">
  <label for="of-api">Introdução a APIs REST</label>

  <input type="checkbox" id="of-acess" name="oficinas" value="acessibilidade">
  <label for="of-acess">Acessibilidade na prática</label>
</fieldset>

A regra decisiva: botões de rádio do mesmo grupo compartilham o mesmo name e têm value diferentes. É o name igual que faz um desmarcar o outro. Dar um name diferente para cada rádio é o erro mais comum da aula — e o sintoma é fácil de reconhecer: todos ficam marcáveis ao mesmo tempo.

Nas caixas de seleção, o name repetido tem outro efeito: o servidor recebe uma lista de valores sob a mesma chave (oficinas=git&oficinas=api).

💡 Dica Uma caixa de seleção não marcada não é enviada — o servidor não recebe termos=false, ele simplesmente não recebe termos. Se você precisa distinguir "respondeu não" de "não respondeu", use dois botões de rádio ("Sim" e "Não") em vez de uma caixa de seleção.

5.4 <datalist> — sugestão com digitação livre¶

<label for="instituicao">Instituição de ensino</label>
<input type="text" id="instituicao" name="instituicao" list="instituicoes"
       autocomplete="organization">
<datalist id="instituicoes">
  <option value="Universidade Estadual — Campus Sinop"></option>
  <option value="UFMT — Campus Sinop"></option>
  <option value="Instituto Federal — Campus Sorriso"></option>
  <option value="UNIC"></option>
  <option value="Outra instituição"></option>
</datalist>