$course$/QCM de NSI/Première/Événements et formulaires Événements DOM (clic, saisie, soumission), gestion des
événements en JavaScript, balises de formulaire HTML
(<form>, <input>, <button>, <select>), méthodes
HTTP GET et POST, validation côté client.

]]> Événements et formulaires — Q01 : Événement Qu'est-ce qu'un événement dans le contexte
d'une page web ?

]]> Les éléments de la page déclenchent des
événements (clic, saisie, soumission) ; les
gestionnaires associés les écoutent et y
réagissent.

]]> 1.0 0.0 0 true true abc Un fichier média

]]> Un fichier média (image,
son, vidéo) est une
ressource statique,
tandis qu'un évènement
est un signal dynamique
déclenché lors de
l'utilisation de la page.

]]> Une erreur de programmation

]]> Erreur : un bug n'est pas un événement DOM.

]]> Une modification CSS entièrement automatique

]]> Une modification CSS
relève de la mise en
forme. Un évènement,
en JavaScript, est un
signal émis par le
navigateur ou l'utilisateur,
auquel le code peut
réagir.

]]> Une action de l'utilisateur ou du navigateur

]]> Bonne réponse : les événements rendent la
page interactive. JavaScript permet
d'y réagir.

]]> Événements et formulaires — Q02 : Événement de clic Quel est le nom de l'événement déclenché quand
l'utilisateur clique sur un élément ?

]]> Événements souris : click, dblclick,
mousedown, mouseup, mousemove,
mouseenter, mouseleave. Idem au clavier :
keydown, keyup, keypress.

]]> 1.0 0.0 0 true true abc mouseDown

]]> C'est un autre événement (pression
du bouton, sans relâcher).

]]> click

]]> Bonne réponse : click est le nom
standard. Pour l'écouter :
el.addEventListener("click", ...).

]]> tap

]]> C'est un événement tactile, distinct.

]]> onclick

]]> C'est l'attribut/propriété d'écoute, pas
le nom de l'événement.

]]> Événements et formulaires — Q03 : Balise form Quelle balise HTML délimite un formulaire ?

]]> Le formulaire envoie ses données vers
action quand l'utilisateur soumet (par
clic sur <button type="submit"> ou en
validant via Entrée).

]]> 1.0 0.0 0 true true abc <send>

]]> Erreur : balise inexistante.

]]> <form>

]]> Bonne réponse : <form> regroupe les
champs et permet de les soumettre
ensemble. Attributs clés : action
(URL), method (GET/POST).

]]> <input>

]]> Erreur : <input> est un champ de
formulaire, pas un conteneur.

]]> <formulaire>

]]> Erreur : balise inexistante.

]]> Événements et formulaires — Q04 : Champ texte Quelle balise crée un champ de saisie texte ?

]]> Types courants d'<input> : text,
password, email, number, date,
checkbox, radio, submit, file.

]]> 1.0 0.0 0 true true abc <text size="20">

]]> Erreur : balise inexistante.

]]> <input type="text">

]]> Bonne réponse : <input> est polyvalente,
type détermine son apparence et son
comportement.

]]> <textbox name="champ">

]]> Erreur : balise inexistante.

]]> <entry>

]]> Erreur : balise inexistante.

]]> Événements et formulaires — Q05 : Bouton Comment créer un bouton « Envoyer » qui
soumet le formulaire ?

]]> Trois types de bouton : submit
(soumission, par défaut dans <form>),
reset (réinitialise les champs), button
(générique, à manipuler en JS).

]]> 1.0 0.0 0 true true abc <submit>Envoyer</submit>

]]> Erreur : balise inexistante ; submit
est une valeur de l'attribut type, pas
une balise.

]]> <a>Envoyer</a>

]]> Erreur : <a> est un lien, pas un
bouton de soumission.

]]> <button type="button">Envoyer</button>

]]> Erreur : type="button" crée un bouton
inerte qui ne soumet pas le
formulaire ; il faut type="submit".

]]> <button type="submit">Envoyer</button>

]]> Bonne réponse : <button> est plus
flexible (peut contenir du HTML, des
icônes). <input type="submit"> est
historique mais valide.

]]> Événements et formulaires — Q06 : Liste déroulante Quelle balise crée une liste déroulante ?

]]> Variantes : <datalist> (suggestions sur un
champ texte), multiple sur <select>
(sélection multiple).

]]> 1.0 0.0 0 true true abc <combo>

]]> Erreur : balise inexistante.

]]> <dropdown>

]]> Erreur : balise inexistante.

]]> <list>

]]> Erreur : balise inexistante.

]]> <select>

]]> Bonne réponse : <select> est le
conteneur, chaque choix étant une
<option value="...">texte</option>
placée à l'intérieur.

]]> Événements et formulaires — Q07 : Étiquette À quoi sert la balise <label> ?

]]> Bonne pratique d'accessibilité : tout champ doit
avoir un <label> associé. Sans label, les
lecteurs d'écran ne peuvent pas annoncer
correctement le champ.

]]> 1.0 0.0 0 true true abc À mettre du texte en gras

]]> Erreur : c'est <strong> ou <b>.

]]> À étiqueter une variable interne du code JavaScript

]]> Une variable JavaScript
n'a pas d'étiquette
accessible aux lecteurs
d'écran. La balise
<label> agit sur la
structure du formulaire
HTML, pas sur le code.

]]> Associer une étiquette à un champ de formulaire

]]> Bonne réponse : améliore l'accessibilité
et l'ergonomie. Lier via
<label for="nomChamp">...</label> et
<input id="nomChamp">.

]]> À créer un titre

]]> Erreur : ce serait <h1>...<h6>.

]]> Événements et formulaires — Q08 : Soumission Quel événement se déclenche quand un
formulaire est soumis ?

]]> Pour empêcher la soumission par défaut
(par exemple pour valider en JS) :
event.preventDefault() dans le
gestionnaire.

]]> 1.0 0.0 0 true true abc click

]]> Le clic sur le bouton déclenche click,
mais l'événement de soumission est
submit.

]]> send

]]> Erreur : événement inexistant.

]]> submit

]]> Bonne réponse : événement submit
déclenché sur le <form>. À écouter pour
intercepter la soumission, par exemple pour
vérifier les champs avant l'envoi.

]]> change

]]> C'est un autre événement (changement de
valeur d'un champ).

]]> Événements et formulaires — Q09 : GET ou POST ? Quelle méthode HTTP utilise-t-on pour
envoyer un mot de passe ?

]]> Règle pratique : GET pour récupérer des
données (recherche, lecture), POST pour
modifier l'état du serveur (création, envoi
de formulaire).

]]> 1.0 0.0 0 true true abc GET, à condition de masquer le champ avec type="password"

]]> Erreur : type="password" masque seulement les
caractères à l'écran. Avec GET, le mot de passe
partirait quand même dans l'URL, visible dans
l'historique.

]]> GET, parce que la requête est plus rapide à envoyer

]]> Erreur : GET met les données dans l'URL,
ce qui est visible et logué dans
l'historique. À éviter pour les données
sensibles.

]]> POST, les données voyageant dans le corps de la requête

]]> Bonne réponse : avec POST, rien ne
transite par l'URL. Pour les données
sensibles, utiliser POST + HTTPS.

]]> Aucune des deux, HTTP ne convenant pas aux données sensibles

]]> Pour transmettre un mot
de passe, on choisit
systématiquement la
méthode POST (avec HTTPS),
qui place les données dans
le corps de la requête
plutôt que dans l'URL.

]]> Événements et formulaires — Q10 : Formulaire complet Lequel de ces fragments est un formulaire valide demandant un nom et l'envoyant en
POST ?

]]> Attribut name essentiel : c'est sous
ce nom que la donnée arrive côté serveur.
Sans name, le champ n'est pas envoyé.

]]> 1.0 0.0 0 true true abc `html
<form action="/save" method="POST">
Nom : <input name="nom" type="text">
<input type="button" value="Envoyer">
</form>
`

]]> Erreur : type="button" crée un bouton
inerte qui ne déclenche pas la
soumission. Il faut type="submit" (ou
un <button> dont le type par défaut est
submit).

]]> `html
<form action="/save" method="POST">
<label for="nom">Nom :</label>
<input id="nom" name="nom" type="text">
<button type="submit">Envoyer</button>
</form>
`

]]> Bonne réponse : <form> avec action et
method, <label> lié à <input> par
for/id, name (essentiel pour
identifier la donnée envoyée), bouton
submit.

]]> `html
<form action="/save" method="POST">
<label for="nom">Nom :</label>
<input id="nom" type="text">
<button type="submit">Envoyer</button>
</form>
`

]]> Erreur : il manque l'attribut name sur
le champ. Sans name, la donnée saisie
n'est pas envoyée au serveur, même si
le formulaire se soumet sans erreur
apparente.

]]> `html
<form action="/save">
<label for="nom">Nom :</label>
<input id="nom" name="nom" type="text">
<button type="submit">Envoyer</button>
</form>
`

]]> Erreur : sans attribut method, le
formulaire est envoyé avec la méthode par
défaut, GET (données visibles dans
l'URL), et non en POST comme demandé.

]]> Événements et formulaires — Q11 : Gestionnaire d'événement Quel code attache la fonction handleClick au
clic sur le bouton btn ?

]]> Avantage d'addEventListener sur
btn.onclick = handleClick : on peut attacher
plusieurs gestionnaires au même événement.

]]> 1.0 0.0 0 true true abc btn.attachEvent("onclick", handleClick)

]]> Erreur : attachEvent est l'ancienne API
propriétaire d'Internet Explorer,
abandonnée ; le standard est
addEventListener.

]]> btn.onclick(handleClick)

]]> Erreur : onclick est une propriété,
pas une méthode. Il faut écrire
btn.onclick = handleClick.

]]> btn.click(handleClick)

]]> Erreur : btn.click() déclenche le
clic, ne l'écoute pas.

]]> btn.addEventListener("click", handleClick)

]]> Bonne réponse : forme moderne et
recommandée.

]]> Événements et formulaires — Q12 : Lire la valeur d'un champ Comment récupérer la valeur tapée dans
<input id="nom"> ?

]]> Pour modifier aussi : el.value =
"nouveau". Pour les cases à cocher et les
boutons radio : el.checked (booléen).

]]> 1.0 0.0 0 true true abc document.getElementById("nom").content

]]> Erreur : propriété inexistante.

]]> document.getElementById("nom").text

]]> Erreur : c'est value, pas text.

]]> document.getElementById("nom").value

]]> Bonne réponse : value est la propriété
standard pour les champs de formulaire
(<input>, <select>, <textarea>).

]]> document.getElementById("nom").innerHTML

]]> Erreur : innerHTML est pour le contenu
HTML d'éléments génériques, pas pour les
champs de formulaire.

]]> Événements et formulaires — Q13 : preventDefault À quoi sert event.preventDefault() dans un
gestionnaire ?

]]> Cas typique : valider un formulaire en JS
avant de le soumettre.
`js
form.addEventListener("submit", e => {
if (!valider()) e.preventDefault();
});
`

]]> 1.0 0.0 0 true true abc À empêcher tous les événements futurs sur la page

]]> Erreur : seul le comportement par défaut
de l'événement courant est annulé,
les événements suivants restent actifs.

]]> À fermer la page courante après l'événement

]]> La fermeture d'une page
se demande via window.close().
La méthode preventDefault
ne ferme rien : elle annule
uniquement l'action par
défaut associée à un
évènement.

]]> À effacer les messages affichés dans la console

]]> L'effacement de la
console se fait avec
console.clear(). La
méthode preventDefault
n'agit que sur l'évènement
en cours, pas sur les
outils du navigateur.

]]> Empêcher le comportement par défaut du navigateur

]]> Bonne réponse : très utile pour
intercepter une soumission ou un clic
sur un lien (<a>) afin de gérer
l'action en JavaScript.

]]> Événements et formulaires — Q14 : Validation HTML5 Comment indiquer qu'un champ est
obligatoire dans le HTML ?

]]> Autres attributs de validation HTML5 :
min, max, minlength, maxlength,
type="email", etc.

]]> 1.0 0.0 0 true true abc Avec l'attribut must-fill

]]> Erreur : attribut inexistant.

]]> Avec l'attribut required

]]> Bonne réponse : <input required> active
la validation native du navigateur, qui
empêche la soumission si le champ est
vide, avec un message standard
automatique.

]]> Avec mandatory="true"

]]> Erreur : attribut inexistant.

]]> Il faut une fonction JavaScript

]]> Possible mais HTML5 offre des
validations natives plus simples.

]]> Événements et formulaires — Q15 : Type d'input adapté Quel type d'<input> est le plus adapté
pour un champ « Âge » ?

]]> Choisir le bon type améliore l'ergonomie
(clavier mobile adapté), accessibilité et
validation. Ne pas négliger ces
« petits détails ».

]]> 1.0 0.0 0 true true abc type="age"

]]> Erreur : type inexistant.

]]> type="email"

]]> Erreur : pour un courriel.

]]> type="number"

]]> Bonne réponse : restreint à des nombres,
affiche des flèches haut/bas, ouvre un
clavier numérique sur mobile.

]]> type="text"

]]> Possible mais peu pratique. L'utilisateur
pourrait taper du texte.

]]> Événements et formulaires — Q16 : Cible de l'événement Dans un gestionnaire d'événement, comment
accéder à l'élément sur lequel l'événement
a eu lieu ?

]]> event.target désigne l'élément sur lequel
l'événement s'est produit : un même
gestionnaire peut ainsi servir à plusieurs
boutons et savoir lequel a été cliqué.

]]> 1.0 0.0 0 true true abc event.target

]]> Bonne réponse : référence l'élément
ayant déclenché l'événement. Permet de
partager un même gestionnaire entre
plusieurs éléments.

]]> event.dom

]]> Erreur : propriété inexistante.

]]> this.element

]]> Erreur : this.element n'existe pas.
L'élément sur lequel l'événement a eu
lieu s'obtient avec event.target.

]]> event.element

]]> Erreur : propriété inexistante.

]]> Événements et formulaires — Q17 : Attribut name Pourquoi l'attribut name est-il important
pour un <input> ?

]]> Distinction triple : id (unique, pour CSS
et JS), class (pour CSS et JS, partagé),
name (pour la soumission du formulaire).

]]> 1.0 0.0 0 true true abc Pour le nom affiché

]]> Erreur : c'est le rôle de <label>.

]]> Pour le validateur HTML automatique du navigateur

]]> Indirectement, mais le rôle principal est
autre.

]]> Il identifie la donnée envoyée au serveur

]]> Bonne réponse : sans name, le champ
n'est pas envoyé au serveur. Le
serveur reçoit nom=Alice&age=17 à
partir des name.

]]> Pour la couleur du champ

]]> Erreur : c'est CSS.

]]> Événements et formulaires — Q18 : Zone de texte Quelle balise crée une zone de texte multiligne ?

]]> Particularité : <textarea> n'est pas
auto-fermante, et son contenu initial
est entre les balises (pas un attribut
value).

]]> 1.0 0.0 0 true true abc <paragraph contenteditable>

]]> Possible mais usage avancé, pas un
formulaire classique.

]]> <input type="text" multiline>

]]> Erreur : multiline n'existe pas comme
attribut de <input>.

]]> <text>multiligne</text>

]]> Erreur : balise inexistante.

]]> <textarea>contenu initial</textarea>

]]> Bonne réponse : balise dédiée. Attributs
utiles : rows, cols, placeholder,
maxlength.

]]> Événements et formulaires — Q19 : Événement input vs change Quelle est la différence entre les événements
input et change sur un <input type="text"> ?

]]> Choix selon le besoin : aperçu en direct →
input ; validation à la fin → change ;
soumission complète → submit (sur le
formulaire).

]]> 1.0 0.0 0 true true abc change plante systématiquement toujours

]]> L'évènement change
fonctionne parfaitement
et n'a aucune raison
structurelle d'échouer.
Il sert simplement à
réagir lorsque la
nouvelle valeur est
confirmée par l'utilisateur.

]]> input à chaque touche, change à la fin

]]> Bonne réponse : input est plus
réactif (auto-complétion en temps réel),
change plus économe.

]]> input n'existe pas

]]> Erreur : événement standard.

]]> Aucune

]]> Erreur : différence de fréquence.

]]> Événements et formulaires — Q20 : Requête HTTP Quand on soumet un formulaire en POST vers
/save, que se passe-t-il côté navigateur ?

]]> Le serveur traite les données reçues
(calcul, enregistrement) et renvoie une
nouvelle page, que le navigateur affiche à
la place du formulaire.

]]> 1.0 0.0 0 true true abc Une requête POST part vers /save, puis la réponse s'affiche

]]> Bonne réponse : c'est le mécanisme
fondamental du formulaire. Le navigateur
envoie la requête, puis affiche la page
renvoyée par le serveur.

]]> Le formulaire reste affiché tel quel, sans requête réseau

]]> Pas par défaut : une requête part et la
page change pour afficher la réponse.

]]> Le navigateur ouvre carrément un autre site

]]> Le navigateur ne quitte
pas le domaine courant
de sa propre initiative.
Il envoie simplement
une requête vers l'URL
indiquée par l'attribut
action du formulaire.

]]> Rien, tant qu'un script JavaScript n'envoie pas les données

]]> Erreur : la soumission est native, aucun
JavaScript n'est nécessaire pour qu'un
formulaire envoie ses données.

]]> Événements et formulaires — Q21 : Validation client vs serveur Faut-il valider les données d'un formulaire
côté client (JavaScript), côté serveur
ou les deux ?

]]> Mantra de sécurité : « Never trust user
input. » La validation côté client améliore
l'expérience, mais la validation côté
serveur est non négociable.

]]> 1.0 0.0 0 true true abc Côté serveur uniquement

]]> Possible mais peu ergonomique :
l'utilisateur doit attendre la réponse
du serveur pour voir une erreur.

]]> Aucune des deux : faire confiance

]]> Erreur : recette pour les bugs et failles.

]]> Côté client uniquement, car plus rapide

]]> Erreur : la validation client peut être
contournée (l'utilisateur peut
désactiver JS, modifier le HTML,
envoyer une requête falsifiée). Pas de
sécurité.

]]> Les deux, pour l'ergonomie et la sécurité

]]> Bonne réponse : règle d'or. Toute
donnée venant du client est suspecte
jusqu'à validation par le serveur.

]]> Événements et formulaires — Q22 : Un paragraphe qui réagit au survol Une page contient <p id="zone">Survolez-moi</p> et le script :

`javascript
const zone = document.getElementById("zone");
zone.addEventListener("mouseover", () => {
zone.textContent = "Dedans";
});
zone.addEventListener("mouseout", () => {
zone.textContent = "Dehors";
});
`

L'utilisateur amène le pointeur sur le paragraphe, clique deux
fois dessus, puis éloigne le pointeur. Qu'affiche alors le
paragraphe ?

]]> Chaque événement a son gestionnaire : mouseover à l'arrivée
du pointeur sur l'élément, mouseout à son départ, click au
clic. Un clic ne déclenche donc ni mouseover ni mouseout.

]]> 1.0 0.0 0 true true abc DedansDehors

]]> Erreur : affecter textContent remplace tout le texte
du paragraphe, sans rien ajouter à la suite. Le dernier
gestionnaire exécuté ne laisse que Dehors.

]]> Dehors

]]> Bonne réponse : l'arrivée du pointeur déclenche
mouseover (texte Dedans), les clics ne déclenchent
aucun de ces deux gestionnaires, et le départ du
pointeur déclenche mouseout, qui écrit Dehors.

]]> Survolez-moi

]]> Erreur : le texte initial ne revient pas tout seul.
Chaque gestionnaire remplace le contenu du paragraphe,
et le dernier exécuté, celui de mouseout, écrit
Dehors.

]]> Dedans

]]> Erreur : les clics ne figent pas le texte. Quand le
pointeur quitte le paragraphe, l'événement mouseout
se produit et son gestionnaire écrit Dehors.

]]> Événements et formulaires — Q23 : Bug formulaire Mon formulaire en POST envoie au serveur, mais
le champ « nom » est vide côté serveur.
Quelle est la cause la plus probable ?

]]> Réflexe de débogage : ouvrir l'onglet
Network des outils développeur, regarder la
requête envoyée et son contenu (« Form
Data »).

]]> 1.0 0.0 0 true true abc Le serveur est en panne

]]> Possible mais cela donnerait une autre
erreur.

]]> Le bouton submit est cassé

]]> Possible mais peu probable si la requête
arrive au serveur.

]]> L'attribut name manque sur l'<input>

]]> Bonne réponse : c'est le piège classique.
<input id="nom"> ne suffit pas ; il
faut <input name="nom"> (l'id n'est
pas envoyé).

]]> Le navigateur n'autorise pas la méthode POST

]]> Erreur : POST est standard.

]]> Événements et formulaires — Q24 : Un mot de passe envoyé sans chiffrement Le formulaire de connexion d'un site commence par :

`html
<form action="http://exemple.fr/connexion" method="post">

L'adresse commence par http:// et non par https://`. Que
risque l'utilisateur qui envoie son mot de passe ?

]]> Deux choix distincts : GET ou POST décide où voyagent les
paramètres (URL ou corps de la requête) ; HTTP ou HTTPS
décide si la transmission est chiffrée. Un mot de passe
exige POST et HTTPS.

]]> 1.0 0.0 0 true true abc Le mot de passe apparaît dans l'URL et dans l'historique du navigateur

]]> Erreur : c'est le cas avec GET. Ici, method="post"
place les données dans le corps de la requête, qui
circule toutefois en clair.

]]> Aucun risque : la méthode POST chiffre les données envoyées

]]> Erreur : POST évite seulement que les données
apparaissent dans l'URL. Le chiffrement est assuré
par HTTPS, pas par le choix de la méthode.

]]> Le serveur refuse la requête, car POST exige une adresse https://

]]> Erreur : rien n'impose HTTPS pour une requête POST.
Le serveur reçoit bien le mot de passe, mais la
transmission n'est pas protégée.

]]> Le mot de passe circule en clair et peut être lu s'il est intercepté

]]> Bonne réponse : POST place les données dans le corps
de la requête, mais sans HTTPS ce corps n'est pas
chiffré. Quiconque intercepte la communication, par
exemple sur un Wi-Fi public, lit le mot de passe.

]]> Événements et formulaires — Q25 : Synthèse Parmi les affirmations suivantes, laquelle
est fausse ?

]]> Mnémonique sécurité : « Never trust user
input + always use HTTPS pour les données
sensibles ».

]]> 1.0 0.0 0 true true abc La méthode HTTP GET est préférable pour transmettre un mot de passe

]]> Faux (donc bonne réponse) : GET met les
données dans l'URL (visibles, loguées).
Pour un mot de passe, utiliser POST sur
HTTPS.

]]> L'attribut name d'un champ est essentiel pour la soumission au serveur

]]> Vrai : sans name, pas envoyé.

]]> Toute donnée client doit être revalidée côté serveur

]]> Vrai : règle d'or de sécurité.

]]> Un événement DOM peut être écouté avec addEventListener

]]> Cette affirmation est
exacte : addEventListener
est la méthode standard
pour attacher un
gestionnaire à un
évènement. Ce n'est
donc pas la mauvaise
affirmation recherchée.

]]> Événements et formulaires — Q26 : Type d'input pour une adresse e-mail Quel attribut type choisir pour un champ destiné à
la saisie d'une adresse électronique ?

]]> Choisir le bon type apporte un triple bénéfice :
validation native du navigateur, clavier adapté
sur mobile, et meilleure information aux
technologies d'assistance. Quelques types utiles :
email, tel, url, number, date, color,
password.

]]> 1.0 0.0 0 true true abc type="text"

]]> Erreur : un champ texte fonctionne, mais
n'apporte aucune validation automatique. On
perd les vérifications de format et le clavier
spécialisé sur mobile.

]]> type="email"

]]> Bonne réponse : ce type indique au navigateur
qu'il s'agit d'une adresse électronique. Cela
déclenche une validation de base (présence
d'un @), affiche un clavier adapté sur
mobile et améliore l'accessibilité.

]]> type="contact"

]]> Erreur : contact n'est pas un type d'input
valide. La liste exhaustive des types est
fixée par le standard HTML.

]]> type="address"

]]> Erreur : aucun type address n'est défini par
le standard HTML. Le type spécifique aux
adresses électroniques est email.

]]> Événements et formulaires — Q27 : Validation côté navigateur Quel attribut HTML5 rend un champ de formulaire
obligatoire, en empêchant la soumission tant
qu'il est vide ?

]]> Autres attributs de validation native :
minlength/maxlength (longueur de la chaîne),
min/max (valeur numérique ou date). La
validation côté navigateur n'exempte pas d'une
revalidation côté serveur.

]]> 1.0 0.0 0 true true abc mandatory

]]> Erreur : aucun attribut mandatory n'est
défini dans le standard HTML. C'est required
qui joue ce rôle.

]]> obligatoire

]]> Erreur : les attributs HTML sont en anglais.
Le bon attribut est required.

]]> empty=false

]]> Erreur : aucune syntaxe de ce type n'existe en
HTML. L'attribut required se passe de
valeur : sa simple présence suffit.

]]> required

]]> Bonne réponse : ajouter required à un champ
empêche le navigateur de soumettre le
formulaire tant qu'il est vide. Un message
d'erreur s'affiche automatiquement.

]]> Événements et formulaires — Q28 : Ce qu'est un cookie Qu'est-ce qu'un cookie ?

]]> Le protocole HTTP ne garde aucun souvenir d'une
requête à l'autre. Pour reconnaître un visiteur, le
serveur lui confie un cookie : le navigateur le
mémorise et le joint à toutes ses requêtes vers ce
site. Connexion maintenue, panier, langue choisie :
tout cela passe par des cookies.

]]> 1.0 0.0 0 true true abc Un petit texte déposé par le serveur, gardé par le navigateur et renvoyé à chaque requête vers le site

]]> C'est le mécanisme qui permet au serveur de
reconnaître un navigateur d'une requête à
l'autre.

]]> Un fichier conservé sur le serveur qui contient l'historique complet de chaque visiteur

]]> Le cookie est rangé chez le client, dans le
navigateur ; le serveur ne garde que ce que le
navigateur lui renvoie.

]]> Un programme que le serveur fait exécuter au navigateur à chaque visite pour reconnaître l'ordinateur

]]> Un cookie ne contient pas de code et ne s'exécute
pas ; c'est une donnée, stockée côté client.

]]> Une image gardée dans le cache du navigateur pour accélérer l'affichage des pages déjà vues

]]> Le cache stocke des ressources de pages ; un
cookie porte une information d'identification ou
de préférence, pas une image.

]]> Événements et formulaires — Q29 : Connecté le lendemain sans ressaisir le mot de passe Sur un site, vous cochez « rester connecté »,
fermez le navigateur et revenez le lendemain : vous
êtes toujours identifié. Où l'information a-t-elle
été conservée ?

]]> Le navigateur stocke le cookie sur le disque, avec
une date d'expiration. Tant qu'elle n'est pas
passée, chaque requête vers le site l'emporte, et le
serveur retrouve la session associée. Se déconnecter
revient à faire effacer ce cookie.

]]> 1.0 0.0 0 true true abc Dans un cookie gardé par le navigateur et renvoyé au serveur à la nouvelle visite

]]> Le serveur y a inscrit un jeton de session ; en
le recevant, il reconnaît votre compte.

]]> Dans une variable JavaScript de la page, qui survit à la fermeture du navigateur

]]> Les variables d'un script disparaissent dès que
la page est fermée.

]]> Nulle part : le serveur reconnaît votre ordinateur grâce à son adresse IP

]]> L'adresse IP change souvent et est partagée par
plusieurs appareils d'un même réseau : elle ne
peut pas identifier un compte.

]]> Dans le code HTML de la page, modifié par le serveur pour y inscrire votre nom

]]> Le HTML reçu est reconstruit à chaque requête ; il
ne persiste pas sur votre machine.

]]> Événements et formulaires — Q30 : Mémoriser une préférence : chez le client ou sur le serveur Un site propose un choix de langue. Deux solutions :
(A) enregistrer la langue dans un cookie ; (B)
l'enregistrer dans la base de données du serveur,
associée au compte de l'utilisateur. Laquelle
retrouve la langue choisie quand l'utilisateur se
connecte depuis un autre ordinateur ?

]]> Ce qui est mémorisé dans le client (cookie, stockage
du navigateur) reste sur cette machine. Ce qui est
mémorisé par le serveur suit le compte. Le choix
dépend de l'usage : un cookie suffit pour un
visiteur anonyme, la base du serveur s'impose pour
un utilisateur identifié.

]]> 1.0 0.0 0 true true abc Les deux, car le navigateur transmet ses cookies au nouvel ordinateur

]]> Rien ne transfère les cookies d'une machine à
l'autre ; chaque navigateur a les siens.

]]> Aucune des deux : une préférence ne se mémorise que pendant la visite

]]> Les deux solutions survivent à la fin de la
visite ; seule la seconde survit au changement de
machine.

]]> La solution B seule, car la préférence est stockée côté serveur

]]> Quelle que soit la machine, une fois connecté,
l'utilisateur retrouve ce que le serveur a
mémorisé pour son compte.

]]> La solution A seule, car le cookie accompagne l'utilisateur

]]> Le cookie reste dans le navigateur où il a été
déposé ; un autre ordinateur n'en a aucune copie.

]]> Événements et formulaires — Q31 : Le trajet d'un cookie entre deux requêtes Première requête vers boutique.fr : le serveur
répond avec l'en-tête Set-Cookie: panier=42.
Quelques secondes plus tard, le navigateur demande
une autre page du même site. Que contient cette
deuxième requête ?

]]> Deux en-têtes se répondent : Set-Cookie dans la
réponse du serveur dépose la valeur, Cookie dans
les requêtes suivantes du navigateur la renvoie. Le
serveur retrouve ainsi le panier numéro 42 sans
que l'utilisateur ait rien ressaisi.

]]> 1.0 0.0 0 true true abc Un en-tête Cookie: panier=42, ajouté automatiquement par le navigateur

]]> Le navigateur joint à chaque requête vers
boutique.fr les cookies que ce site lui a
confiés.

]]> Un en-tête Set-Cookie: panier=42, renvoyé tel quel au serveur

]]> Set-Cookie est un en-tête de réponse, du serveur
vers le navigateur ; dans l'autre sens, l'en-tête
s'appelle Cookie.

]]> Rien de particulier : c'est au serveur de redemander la valeur du panier

]]> Le serveur n'a aucun moyen de « redemander » :
HTTP est sans mémoire, c'est le client qui
renvoie l'information.

]]> Le cookie panier=42, envoyé aussi à tous les autres sites visités ensuite

]]> Un cookie n'est renvoyé qu'au site qui l'a
déposé ; les autres sites ne le voient pas.

]]> Événements et formulaires — Q32 : L'événement déclenché par l'envoi Quel événement se produit sur un élément form lorsque
l'utilisateur clique sur son bouton d'envoi ou appuie sur Entrée
dans un champ ?

]]> Écouter submit sur le formulaire couvre tous les moyens d'envoi,
bouton comme touche Entrée.

]]> 1.0 0.0 0 true true abc input

]]> Erreur : input est émis à chaque modification d'un champ.

]]> send

]]> Erreur : cet événement n'existe pas.

]]> submit

]]> Bonne réponse : submit est émis par le formulaire lui-même,
quel que soit le moyen de l'envoyer.

]]> click

]]> Erreur : click est émis par le bouton, pas par le formulaire,
et la touche Entrée ne le déclenche pas.

]]> Événements et formulaires — Q33 : Une valeur lue trop tôt Ce script affiche toujours une chaîne vide au clic. Pourquoi ?
`javascript
const nom = document.getElementById("nom").value;
document.getElementById("btn").addEventListener("click", function () {
alert("Bonjour " + nom);
});
`

]]> Une valeur de formulaire change avec l'utilisateur : elle se lit au
moment de l'événement, pas une fois pour toutes au chargement.

]]> 1.0 0.0 0 true true abc Le gestionnaire doit être attaché au champ et non au bouton

]]> Erreur : le bouton est une cible correcte ; le problème est le
moment de la lecture.

]]> alert ne peut pas afficher une variable, seulement un texte fixe

]]> Erreur : alert affiche n'importe quelle chaîne.

]]> Le champ nom n'a pas d'attribut name, donc pas de valeur

]]> Erreur : name sert à l'envoi, pas à la lecture de .value.

]]> La valeur est lue au chargement, avant la saisie

]]> Bonne réponse : nom reçoit la valeur du champ au moment où le
script s'exécute, c'est-à-dire vide. Lire .value à l'intérieur
de la fonction donne la saisie du moment.

]]> Événements et formulaires — Q34 : Savoir quelle touche a été pressée Dans un gestionnaire de l'événement keydown, comment savoir
quelle touche l'utilisateur a enfoncée ?

]]> Le paramètre event d'un gestionnaire décrit ce qui s'est passé :
touche pressée, position de la souris, élément visé.

]]> 1.0 0.0 0 true true abc En comparant le texte du champ avant et après la frappe

]]> Erreur : c'est possible mais peu fiable, et inutile puisque
l'événement donne la touche.

]]> En appelant keyboard.last()

]]> Erreur : cette fonction n'existe pas.

]]> En lisant event.key

]]> Bonne réponse : l'objet événement reçu en paramètre porte la
touche dans key, par exemple "Enter" ou "a".

]]> En lisant event.value

]]> Erreur : value est une propriété des champs de saisie, pas de
l'événement clavier.

]]> Événements et formulaires — Q35 : Texte indicatif ou valeur préremplie Quelle différence entre <input placeholder="Votre nom"> et
<input value="Votre nom"> ?

]]> Un placeholder aide l'utilisateur sans rien envoyer ; une value
est une donnée, parfois envoyée par erreur si on l'oublie.

]]> 1.0 0.0 0 true true abc Aucune, les deux attributs étant synonymes et envoyés tous deux

]]> Erreur : l'un guide, l'autre remplit ; seul value est transmis.

]]> Le premier concerne les champs texte, le second les boutons

]]> Erreur : les deux s'appliquent aux champs de saisie.

]]> Le premier affiche une indication grisée, le second préremplit le champ

]]> Bonne réponse : placeholder n'est pas une valeur, elle n'est
pas envoyée ; value est le contenu réel du champ, envoyé tel
quel si l'utilisateur ne le change pas.

]]> Le premier est obligatoire, le second facultatif pour le navigateur

]]> Erreur : les deux sont facultatifs ; l'obligation de saisie vient
de required.

]]> Événements et formulaires — Q36 : Un champ numérique borné Que garantit <input type="number" min="0" max="20" name="note">
lors de l'envoi du formulaire ?

]]> La validation côté client améliore l'expérience ; la validation côté
serveur garantit la sécurité. Les deux sont nécessaires.

]]> 1.0 0.0 0 true true abc Un blocage par le navigateur hors de [0, 20], le serveur devant revérifier

]]> Bonne réponse : la vérification du navigateur protège contre les
erreurs de saisie, pas contre une requête fabriquée à la main.
Le serveur reste responsable de la validation.

]]> Rien, ces attributs ne servant qu'à l'affichage du champ

]]> Erreur : le navigateur les utilise bien pour bloquer l'envoi
d'une valeur hors bornes.

]]> La valeur est automatiquement arrondie à l'entier le plus proche

]]> Erreur : min et max bornent, ils n'arrondissent pas ; step
règle les valeurs permises.

]]> Le serveur ne peut recevoir que des valeurs entre 0 et 20, garanties

]]> Erreur : une requête envoyée sans passer par le formulaire peut
contenir n'importe quoi.

]]>