Liens, images et formulaires

Objectifs

À la fin de cette leçon, vous saurez :

• créer des liens absolus, relatifs, ancres et mailto ;
• insérer des images accessibles qui ne cassent pas la mise en page ;
• construire un formulaire complet — labels appariés, champs nommés, validation native ;
• relier GET/POST du formulaire aux méthodes HTTP du chapitre 11.

🔗 Pour vous rafraîchir la mémoire : éléments sémantiques · anatomie d'une requête HTTP

Les liens : trois destinations

<a href="https://exemple.fr">Site externe</a>          <!-- absolu : hors du site -->
<a href="/cours/terminal">Lien interne</a>             <!-- absolu sur le même domaine -->
<a href="articles/page2.html">Page voisine</a>         <!-- relatif au fichier courant -->
<a href="#objectifs">Aller aux objectifs</a>           <!-- ancre DANS la page -->
<h2 id="objectifs">Objectifs</h2>

Destination	Comment	Exemple de résolution
externe	URL complète avec protocole	https://...
interne (racine)	commence par /	/cours/terminal = racine-du-site + cours/terminal
relative	sans / initial	résolue depuis le dossier du fichier HTML courant
ancre	# + id d'un élément	défilement direct vers l'élément

Le lien relatif fonctionne EXACTEMENT comme les chemins shell du chapitre 1 : images/photo.jpg cherche un sous-dossier, ../styles.css remonte au parent. Même arbre, mêmes règles — vous savez déjà le faire.

Deux attributs complémentaires :

<a href="https://exemple.fr" target="_blank" rel="noopener">Externe</a>

target="_blank" ouvre un nouvel onglet — à réserver aux liens QUI QUITTENT votre site. Et prenez l'habitude d'y associer rel="noopener" : il coupe l'accès de la page ouverte à VOTRE fenêtre (faille connue sous le nom de tabnabbing).

Les images : visibles par tous, stables dans la page

<img src="images/photo.jpg" alt="Paul devant son terminal" width="400" height="300">

• src : la source — chemin relatif ou URL complète ;
• alt : le texte alternatif, OBLIGATOIRE. Il est lu par les lecteurs d'écran, affiché si l'image ne charge pas, indexé par les moteurs. Rédigez-le comme une description utile (« Paul devant son terminal »), pas comme un nom de fichier (« photo1.jpg ») ; vide (alt="") uniquement pour les images purement décoratives ;
• width/height : dimensions annoncées d'avance. Leur rôle caché mais crucial : le navigateur RÉSERVE la place avant le chargement — sinon la page « saute » quand les images arrivent (le fameux layout shift qui pénalise aussi le SEO).

Le formulaire : collecter des données

Le formulaire est votre première machine à fabriquer des requêtes HTTP sans écrire une ligne de code réseau :

<form action="/inscription" method="post">
  <label for="nom">Nom</label>
  <input type="text" id="nom" name="nom" required>

  <label for="email">Email</label>
  <input type="email" id="email" name="email" required>

  <label for="niveau">Niveau</label>
  <select id="niveau" name="niveau">
    <option value="debutant">Débutant</option>
    <option value="intermediaire">Intermédiaire</option>
  </select>

  <button type="submit">S'inscrire</button>
</form>

Chaque pièce a un rôle précis — et deux d'entre elles sont des pièges classiques :

Pièce	Rôle	Piège associé
action	où envoyer les données	oublié → soumission vers la page elle-même
method	get (query params) ou post (corps)	choix par défaut = get, souvent inadapté
name	LA CLÉ envoyée au serveur	sans name, la valeur n'est PAS envoyée du tout
for/id appariés	label ↔ champ	sans appariement, cliquer le label ne focus rien ; lecteurs d'écran perdus
required, type="email"	validation NATIVE du navigateur	ne remplace jamais une validation serveur

Insistons sur name car l'erreur est invisible côté écran : le formulaire se soumet « bien », mais le serveur reçoit un paquet vide. Le couple envoyé est toujours name=valeur — sans nom, pas de couple.

Le type de l'input change tout : email valide le format ET affiche le clavier @ sur mobile ; number affiche le pavé numérique ; password masque la saisie ; date, checkbox, radio... Choisissez le type sémantique, vous obtenez gratuitement clavier adapté + validation intégrée.

L'expérience décisive : GET puis POST

Soumettez ce formulaire en method="get" et observez la barre d'adresse :

page.html?nom=Paul&email=paul%40exemple.fr&niveau=debutant

Reconnaissez-vous le tableau ? C'est exactement la structure query parameters du chapitre HTTP — le navigateur vient de FABRIQUER une requête GET pour vous : méthode implicite GET, données encodées dans l'URL (@ devient %40), séparées par &.

Passez en method="post" et resoumettez : plus RIEN dans l'URL. Les données sont parties dans le CORPS de la requête — invisible dans la barre d'adresse, visible dans l'onglet Réseau des DevTools.

Règle professionnelle héritée directement du cours HTTP : GET pour des lectures répétables (recherche, filtres), POST pour des actions qui modifient quelque chose (inscription, achat). Un formulaire de connexion en GET mettrait le mot de passe dans l'URL — visible dans les historiques, logs et proxys !

Exercice

1. Ajoutez une image locale (créez-en une quelconque) avec alt pertinent et dimensions fixes.
2. Construisez le formulaire ci-dessus en get ; soumettez et décryptez chaque paramètre de l'URL obtenue.
3. Passez en post ; ouvrez DevTools → Réseau → cliquez la requête : retrouvez vos données dans le corps (Payload).
4. Retirez le name d'un champ et resoumettez : que constate-t-on ? Expliquez.
5. Ajoutez une ancre interne : un lien « haut de page » qui remonte vers le header.

Résumé

• Liens : quatre destinations (absolu, racine, relatif, ancre) ; _blank accompagné de rel="noopener".
• Images : alt obligatoire et utile ; width/height réservent la place.
• Formulaire = action + method + champs NOMMÉS + labels appariés ; types natifs = validation gratuite.
• GET → query params visibles ; POST → corps invisible : la règle de choix vient du chapitre HTTP.

?nom=Paul&email=paul%40exemple.fr&niveau=debutant
  │        │                │
  clé      valeur encodée   (%40 = @)

<header id="haut">
...
<a href="#haut">↑ Haut de page</a>