Récupérer le contenu d'un input

Bonjour,

Voici le code :

1
2
3
4
5
6

<div class="active-pink-3 active-pink-4 mb-4">
    <input class="form-control" type="text" placeholder="Pseudo" aria-label="Search">
</div>
</div>

`

(J’utilise Bootstrap).

J’aimerais faire en sorte de récupérer le contenu que le client a tapé dans une variable mais je ne sais pas comment faire pour y parvenir.

J’ai fais des recherches mais je n’ai toujours pas trouvé comment faire :/. J’aimerais simplement savoir quelle est la méthode qu’il faut utiliser.

Merci de votre aide.

Salut !

Il faut utiliser du Javascript. Un petit exemple :

1
2
3
4
5
6
7
8
9

<div class="active-pink-3 active-pink-4 mb-4">
    <input class="form-control" type="text" placeholder="Pseudo" aria-label="Search" id="pseudo_recherche">
</div>

<script>
function afficheInputUtilisateur() {
     alert(document.getElementById('pseudo_recherche').value);
}
</script>

Après il faut appeler la fonction, tu peux le faire lorsque l’utilisateur clique sur un bouton en utilisant l’attribut "onClick" du bouton, par exemple.

Exemple de onClick ici : https://www.w3schools.com/Js/tryit.asp?filename=tryjs_doc_open

`

Ça dépend de ce que tu veux en faire.

@Antoxyde: je crois qu’il y a d’autres ressources qui dépassent largement w3schools d’un point de vue qualitatif.

Merci, c’est bon !

Voici le code :

HTML (partie où on écrit):

1
2
3

<div class="active-pink-3 active-pink-4 mb-4">
    <input class="form-control" type="text" placeholder="Pseudo" aria-label="Search" id="pseudo_recherche">
</div>

HTML (partie où on recherche en cliquant sur le boutton):

1

<button onclick="afficheInputUtilisateur()" type="button" class="btn btn-primary btn-sm" style="position: absolute; top: 25%; height: 100%; left: -4%;"><h6>RECHERCHER</h6></button>

JS:

1
2
3

function afficheInputUtilisateur() {
     alert(document.getElementById('pseudo_recherche').value)
}

Merci pour votre aide !

Bonne journée !

Aïe… Effectivement W3cSchool est très daté au niveau des ressources ; ton code HTML seul est plutôt bon, les classes ont l’air plutôt propres et le aria-label est une bonne pratique, toutefois…

Commençons par le placeholder ; Eric Bailey a écrit il y a peu un article sur le sujet, tendant à repousser les développeurs de l’utiliser. Je ne serais pas aussi catégorique que lui, mais je suis pour limiter son utilisations aux cas où (repris de son article) :

• la traduction est impossible, le mot est international ou le site n’est destiné qu’à une langue ;
• il ne porte pas d’information ;
• particulièrement, il convient de veiller à ce qu’il soit lisible même lorsque l’utilisateur à commencé à taper ;
• son style est lisible en haut-contraste, et compréhensible par les utilisateurs utilisant un lecteur d’écran ;
• est différemment contrasté par rapport au texte pour qu’il ne soit pas confondu avec et pour les malvoyants.

Tu ne réponds pas à ces critères ici, il serait donc bien mieux de faire quelque chose comme ceci :

1
2
3
4

<div class="active-pink-3 active-pink-4 mb-4">
    <label for="pseudo_recherche">Pseudo</label>
    <input class="form-control" type="text" aria-label="Search" id="pseudo_recherche">
</div>

Ensuite, il faut absolument arrêter de mettre du style dans le document HTML, c’est une pratique qui, comme IE6, aurait du disparaitre, mais continue de trainer à quelques endroits sur le Web. Il faut créer une feuille de style, la lier, puis y inclure quelques chose comme ça :

1
2
3
4
5
6
7

/* Il faut nommer ton bouton (ID ou class, class préférée) */
.monBouton {
    position: absolute;
    top: 25%;
    left: -4%;
    height: 100%;
}

Parlons ensuite rapidement de JavaScript : l’attribut onclick est une très mauvaise pratique, il faut séparer le script du contenu, tout comme tu sépares le style du contenu ; enlèves donc ton onclick, pour le remplacer par :

1
2
3

const monBouton = document.querySelector(".monBouton"); // Remplaces par ton id

monBouton.addEventListener("click", afficheInputUtilisateur);

dans ton JS.

Merci pour ces infos ! Je n’étais vraiment pas au courant de ça. J’ai edit mon code comme tu me l’as conseillé :).

Je n’ai simplement pas pourquoi le onClick() était une mauvaise pratique :/. Peux-tu m’en dire plus ?

Merci beaucoup !

Euh …

Pour ce qui est du placeholder. Je comprend pas la logique de Eric Bailey. Si je suis sa logique.

On ne devrait pas utiliser button comme cela :

1

<input type="button" value="Send">

Car l’attribut value risque de ne pas être traduit par certains traducteurs automatiques ? ¯_(ツ)_/¯

Le rôle d’un placeholder n’est certes pas de remplacer un label. Là on est d’accord. Mais invoquer un mauvais support des traducteurs automatique …

Le placeholder ne devrait pas être obligatoire pour comprendre le formulaire. C’est sensé être une aide à la saisie. On est sensé savoir quoi taper sans le placeholder, mais s’il y a un format particulier à respecter, alors le placeholder devrait nous donner un exemple simple de format.

En ce sens, il n’y a souvent même pas besoin de traduire. 31/12/1990 est assez claire (ou DD/MM/YYYY). Ou encore example@blue.com. Ici, on utilise bien des mots anglais mais on s’en fiche, c’est le format qui est important. La traduction est du bonus et n’est pas le rôle du développeur

Je reste, je plussoie à 100%. Notamment la séparation du JS et du HTML (ce qui passe par la non utilisation des handler event, on-)

Je suis prêt à l’entendre pour la traduction, c’est pourquoi je dis que c’est bon pour les expressions dont "la traduction est impossible, le mot est international ou le site n’est destiné qu’à une langue ;". J’ajouterais que, de mémoire, seuls certains attributs ne sont pas traduits par le navigateur, mais n’étant pas sûr de mon coup, on va dire que non. Ton exemple du Send est parfait : un non-anglophone arrive sur ton site, et il fait quoi ? Il faut penser à tout de le monde, si le site ne veut pas être restreint à un seul type de public.

Pour le deuxième argument, je suis par contre parfaitement contre, pour les raisons détaillées dans l’article, les placeholders sont généralement lus rapidement, et il est rare que l’utilisateur y fasse particulièrement attention et s’en souvienne donc lors de la fin de la saisie ; il m’arrive, particulièrement sur les sites anglo-saxons, de me demander s’il faut mettre l’année sur un deux ou quatre caractères, alors que j’ai déjà tapé jour et mois : il ne reste plus qu’à recommencer.

Je n’ai simplement pas pourquoi le onClick() était une mauvaise pratique :/. Peux-tu m’en dire plus ?

En fait, c’est pas tant le onClick qui est une mauvaise pratique, c’est plutôt le fait de le mettre dans la page HTML. Expliquer pourquoi est une très longue histoire, en fait celle de la création du Web, ou plutôt ses premiers développements. Pour résumer, c’est exactement la même raison que la mise en place du CSS :

• application du même script à plusieurs éléments ; je pense particulièrement aux menus, où il faudrait mettre un onClick par élément : c’est lourd et peu esthétique, alors qu’une sélection multiple suivie d’une boucle est à la fois plus simple à écrire et à maintenir (imagines devoir rajouter des éléments plus tard, ce sera possible sans modifier le JS) ;
• pas de duplications inutiles, et donc allègement de la page, qui sera plus simple à charger pour les navigateurs (plus rapide, surtout avec une faible BP) ;
• de même, pour les bas-débits, la page HTML charge avant les éléments externes, ils peuvent donc consulter le contenu (important) avoir d’avoir la mise en page et les effets (accessoires) ;
• enfin, pas de duplication entre les pages, il sera possible de mettre 500 pages HTML avec le même menu utilisant le même script, le développeur est donc soulagé si le script est amené à changer, et icelui sera mis en cache, permettant d’économiser, encore une fois, de la BP, particulièrement pour les abonnements téléphoniques.

Je pense avoir fait le tour, globalement, si d’autres voient encore des arguments pour (ou contre), n’hésitez pas à le poster ici.

Pour le deuxième argument, je suis par contre parfaitement contre, pour les raisons détaillées dans l’article, les placeholders sont généralement lus rapidement, et il est rare que l’utilisateur y fasse particulièrement attention et s’en souvienne donc lors de la fin de la saisie ; il m’arrive, particulièrement sur les sites anglo-saxons, de me demander s’il faut mettre l’année sur un deux ou quatre caractères, alors que j’ai déjà tapé jour et mois : il ne reste plus qu’à recommencer.

Pas faux. ’31/12/1990’ reste bien mieux que ’DD/MM/YYYY’ qui devrait être mis dans un label ailleurs.