From 39f2114f9797eb51994966c6bb8ff1814c9a4da8 Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 12:36:08 +0100 Subject: unslug fr: move --- .../cross_browser_testing/accessibility/index.html | 684 +++++++++++++++++++++ .../accessibilit\303\251/index.html" | 684 --------------------- .../cross_browser_testing/html_and_css/index.html | 509 +++++++++++++++ .../cross_browser_testing/html_et_css/index.html | 509 --------------- files/fr/learn/tools_and_testing/github/index.html | 94 +++ files/fr/learn/tools_and_testing/index.html | 42 ++ .../command_line/index.html | 487 +++++++++++++++ .../ligne_de_commande/index.html | 487 --------------- 8 files changed, 1816 insertions(+), 1680 deletions(-) create mode 100644 files/fr/learn/tools_and_testing/cross_browser_testing/accessibility/index.html delete mode 100644 "files/fr/learn/tools_and_testing/cross_browser_testing/accessibilit\303\251/index.html" create mode 100644 files/fr/learn/tools_and_testing/cross_browser_testing/html_and_css/index.html delete mode 100644 files/fr/learn/tools_and_testing/cross_browser_testing/html_et_css/index.html create mode 100644 files/fr/learn/tools_and_testing/github/index.html create mode 100644 files/fr/learn/tools_and_testing/index.html create mode 100644 files/fr/learn/tools_and_testing/understanding_client-side_tools/command_line/index.html delete mode 100644 files/fr/learn/tools_and_testing/understanding_client-side_tools/ligne_de_commande/index.html (limited to 'files/fr/learn/tools_and_testing') diff --git a/files/fr/learn/tools_and_testing/cross_browser_testing/accessibility/index.html b/files/fr/learn/tools_and_testing/cross_browser_testing/accessibility/index.html new file mode 100644 index 0000000000..0af81a09b0 --- /dev/null +++ b/files/fr/learn/tools_and_testing/cross_browser_testing/accessibility/index.html @@ -0,0 +1,684 @@ +--- +title: Gérer les problèmes courants d'accessibilité +slug: Learn/Tools_and_testing/Cross_browser_testing/Accessibilité +tags: + - Accessibilité + - Apprentissage + - Article + - CSS + - Clavier + - Débutant + - HTML + - JavaScript + - Outils + - navigateur croisé + - test +translation_of: Learn/Tools_and_testing/Cross_browser_testing/Accessibility +--- +
{{LearnSidebar}}
+ +
{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/JavaScript","Learn/Tools_and_testing/Cross_browser_testing/Feature_detection", "Learn/Tools_and_testing/Cross_browser_testing")}}
+ +

Tournons maintenant notre attention vers l'accessibilité, les informations sur les problèmes communs, comment faire des tests simples, et comment faire pour utiliser les outils d'audit/automatisation pour trouver les problèmes d'accessibilités.

+ + + + + + + + + + + + +
Prérequis : +

Connaissances avec le noyau des langages HTML, CSS et JavaScript ; une idée du haut niveau des principes du test en navigateur croisé.

+
Objectif : +

Être capable de diagnostiquer les problèmes courants d'Accessibilité, et utiliser les outils et techniques appropriés pour les résoudre.

+
+ +

Qu'est-ce que l'accessibilité ?

+ +

Quand on parle d'accessibilité dans le contexte de la technologie web, la plupart des gens pense directement au fait de s'assurer que les sites web/apps sont utilisables par les personnes avec des handicap, par exemple :

+ + + +

Toutefois, ce serait faux de réduire l'accessibilité uniquement aux handicaps. Le vrai but de l'accessibilité est de faire en sorte que vos sites web/applis soient utilisables par le plus grand nombre de personnes dans le plus grand nombre de contextes possibles, pas uniquement ces utilisateurs qui utilisant des ordinateurs de bureau puissants. Les exemples extrêmes pourraient inclure :

+ + + +

D'une certaine manière, la totalité de ce module concerne l'accessibilité — le test en navigateur croisé assure que vos sites peuvent être utilisé par le plus de personne possible. Qu'est-ce que l'accessibilité ? décrit plus largement et précisément l'accessibilité que cet article ne le fait.

+ +

Cela dit, cet article couvrira les problèmes en navigateur croisé et de test entourant les personnes avec des handicaps, et comment ils utilisent le Web. Nous avons déjà parlé des autres domaines comme le responsive design et la performance à d'autres endroits dans ce module.

+ +
+

Note : Comme beaucoup de choses dans le développement web, l'accessibilité ne concerne pas la totale réussite ou échec ; l'accessibilité à 100% est quasiment impossible à atteindre pour tous les contenus, spécialement quand les sites deviennent plus complexes. Il s'agit plutôt de faire un effort pour rendre votre contenu accessible au plus grand nombre de personnes possible, avec du code de prévention, et se tenir aux meilleures pratiques.

+
+ +

Problèmes d'accessibilité courants

+ +

Dans cette section nous détaillerons certains des problèmes principaux qui se manifestent autour de l'accessibilité, liée à des technologies spécifiques, avec les bonnes pratiques à adopter, et quelques tests rapides que vous pouvez faire pour voir si vos sites vont dans le bon sens.

+ +
+

Note : L'accessibilité est moralement la bonne chose à faire, est bonne pour les affaires (nombre élevé d'utilisateurs handicapés, utilisateurs sur des appareils mobiles, etc. représentent un segment du marché signifiant), mais c'est aussi illégal dans de nombreuses régions de la planète de ne pas rendre les propriétés du web accessibles aux personnes avec des handicaps. Pour plus d'informations, lisez Accessibility guidlines and the law.

+
+ +

HTML

+ +

La sémantique HTML (où les éléments sont utilisés à leur fin prévues) est accessible sans aucune modification — les contenus sont lisibles par les spectateurs voyants (à condition que vous n'ayez rien fait d'absurde comme rendre le texte bien trop petit ou ne l'ayez caché en utilisant du CSS), mais il sera aussi utilisable par des technologies d'assistance comme les lecteurs d'écran (applis qui lisent littéralement une page à leurs utilisateurs), et apporte également d'autres avantages.

+ +

La structure sémantique

+ +

Le quick win le plus important en sémantique HTML et d'utiliser une structure de rubriques et de paragraphes pour votre contenu ; parce que les utilisateurs de lecteurs d'écran ont tendance à utiliser les rubriques d'un document comme indications pour trouver le contenu qu'il recherche plus rapidement. Si votre contenu n'a pas de rubriques, tout ce qu'ils auraient c'est un énorme mur de texte sans aucune indication pour trouver quelque chose. Exemples de bon et de mauvais HTML :

+ +
<font size="7">My heading</font>
+<br><br>
+This is the first section of my document.
+<br><br>
+I'll add another paragraph here too.
+<br><br>
+<font size="5">My subheading</font>
+<br><br>
+This is the first subsection of my document. I'd love people to be able to find this content!
+<br><br>
+<font size="5">My 2nd subheading</font>
+<br><br>
+This is the second subsection of my content. I think is more interesting than the last one.
+ +
<h1>My heading</h1>
+
+<p>This is the first section of my document.</p>
+
+<p>I'll add another paragraph here too.</p>
+
+<h2>My subheading</h2>
+
+<p>This is the first subsection of my document. I'd love people to be able to find this content!</p>
+
+<h2>My 2nd subheading</h2>
+
+<p>This is the second subsection of my content. I think is more interesting than the last one.</p>
+ +

De plus, votre contenu doit avoir un sens logique dans son code source — vous pourrez toujours le placer où vous voulez en utilisant du CSS plus tard, mais vous devez avoir un bon code source avec lequel commencer.

+ +

Comme test, vous pouvez désactiver le CSS d'un site et voir à quel point il est compréhensible sans ce dernier. Vous pouvez le faire manuellement juste en retirant le CSS de votre code, mais la façon la plus simple reste d'utiliser les fonctionnalités du navigateur, par exemple :

+ + + +

Utiliser l'accessibilité native du clavier

+ +

Certaines fonctionnalités HTML peuvent être sélectionnées en utilisant uniquement le clavier — c'est le comportement par défaut, disponible depuis les prémices du web. Les éléments qui ont cette capacité sont les plus communs qui permettent à l'utilisateur d'interagir avec les pages web, à savoir les liens, {{htmlelement("button")}}s, et les éléments des formulaire comme {{htmlelement("input")}}.

+ +

Vous pouvez essayer ceci en utilisant notre exemple native-keyboard-accessibility.html (voir le code source) — ouvrez le dans un nouvel onglet, et essayez de presser la touche tab ; après quelques pressions, vous devriez voir la focalisation du tab commencer à se déplacer entre les différents éléments focalisables ; les éléments focalisés ont un style de mise en avant par défaut dans tous les navigateurs (cela diffère peu entre les différents navigateurs) donc vous pouvez dire quel éléments est focalisé.

+ +

+ +

Vous pouvez ensuite presser Entrée/Retour pour accéder à un lien focalisé ou presser un bouton (nous avons inclus un peu de JavaScript pour que les boutons renvoies un message d'alerte), ou commencer à taper pour entrer du texte dans un des input texte (d'autres éléments de formulaire ont différents contrôles, par exemple l'élément {{htmlelement("select")}} peut avoir ses options affichées et navigable en utilisant les touches haut et bas).

+ +

Notez que différents navigateurs peuvent avoir différentes options de contrôle par clavier disponibles. La plupart des navigateurs modernes respectent le modèle de tab écrit plus haut (vous pouvez aussi faire une Shift + Tab pour reculer entre les éléments focalisables), mais certains navigateurs ont leurs propres particularités :

+ + + +
+

Important : Vous devez jouer ce genre de test sur toutes les pages que vous écrivez — assurez-vous que la fonctionnalité peut être accessible par le clavier.

+
+ +

Cet exemple souligne l'importance de l'utilisation de la sémantique correcte d'élément pour le travail correct. C'est possible de styler n'importe quel élément pour qu'il ressemble à un lien ou un bouton avec le CSS, et de le faire se comporter comme un lien ou un bouton avec JavaScript, mais ils ne seront toujours pas des liens ou des boutons, et vous perdrez beaucoup de l'accessibilité que ces éléments vous fournissent pour rien. Donc ne le faîte pas si vous pouvez l'éviter.

+ +

Un autre conseil — comme vu dans notre exemple, vous pouvez contrôler comment vos éléments focalisables paraissent quand ils sont focalisés, en utilisant la pseudo-class :focus. C'est une bonne idée de doubler les styles focus et hover, comme ça vos utilisateurs auront un indice visuel qu'un contrôle fera quelque chose lorsqu'il sera activé, qu'ils utilisent la souris ou le clavier :

+ +
a:hover, input:hover, button:hover, select:hover,
+a:focus, input:focus, button:focus, select:focus {
+  font-weight: bold;
+}
+ +
+

Note : Si vous décidez de retirer le style focus par défaut en utilisant du CSS, assurez-vous de le remplacer par autre chose qui s'accorde au mieux avec votre design — c'est un outil d'accessibilité de grande valeur, qui ne doit pas être supprimé.

+
+ +

Intégrer l'accessibilité clavier

+ +

Parfois ça n'est pas possible d'éviter la perte de l'accessibilité clavier. Vous pouvez avoir hérité d'un site où la sémantique n'est pas parfaite (peut-être que vous vous êtes retrouvé avec un CMS horrible qui génère des boutons créés avec des <div>s), ou que vous utilisez un contrôle complexe qui n'a pas d'accessibilité clavier intégré, comme l'élément {{htmlelement("video")}} (étonnamment, Opera est le seul navigateur qui vous permet de tabuler dans l'élément <video> avec les contrôles par défaut du navigateur). Vous avez quelques options ici :

+ +
    +
  1. Créer des contrôles personnalisés en utilisant les éléments <button> (sur lequel nous pouvons tabuler par défaut !) et JavaScript pour les relier à leur fonction. Pour des bons exemples voir Creating a cross-browser video player.
  2. +
  3. Créer des raccourcis clavier en utilisant JavaScript, les fonctions sont activés quand vous appuyez sur une certaine touche du clavier. Voir Desktop mouse and keyboard controls pour des exemples en rapport avec le jeu qui peuvent être adaptés à d'autres fins.
  4. +
  5. Utilisez des approches intéressantes pour simuler le comportement d'un bouton. Prenez par exemple notre exemple fake-div-buttons.html (voir le code source). Nous donnons à nos faux boutons <div> la capacité d'être focalisé (y compris avec la tabulation) en donnant à chacun d'entre eux l'attribut tabindex="0" (voir l'article tabindex de WebAIM pour plus de détails utiles). Cela nous permet de tabuler sur les boutons, mais pas de les activer avec la toucher Entrée/Retour. Pour faire cela, nous devons ajouter ce petit bout de tromperie en JavaScript :
  6. +
  7. +
    document.onkeydown = function(e) {
    +  if(e.keyCode === 13) { // The Enter/Return key
    +    document.activeElement.onclick(e);
    +  }
    +};
    + Ici nous ajoutons un listener à l'objet document pour détecter quand une touche a été appuyée sur le clavier. Nous vérifions quelle touche a été pressée avec la propriété d'évènement d'objet keyCode ; si c'est le code de la touche qui retourne Entrée/Retour, on exécute la fonction stockée dans le onclick du bouton en utilisant document.activeElement.onclick()activeElement nous donne l'élément courant qui est focalisé sur la page.
  8. +
+ +
+

Note : Cette technique ne fonctionnera que si vous configurer vos propres gestionnaires d'évènement avec les propriétés de gestion d'évènement (par ex. onclick). addEventListener ne fonctionnera pas. C'est beaucoup de prises de tête pour construire la fonctionnalité de retour. Et il y a d'autres problèmes rattachés avec. Vaut mieux commencer par utiliser les bons éléments pour leurs buts initiaux.

+
+ +

Les textes alternatifs

+ +

Les textes alternatifs sont très importants pour l'accessibilité — si une personne a un trouble visuel ou auditif qui l'empêche de voir ou d'entendre un contenu, alors c'est un problème. Le texte alternatif le plus simple disponible est le modeste attribut alt, que nous devrions inclure dans toutes les images qui contiennent un contenu pertinent. Il peut contenir une description de l'image qui transmet clairement son sens et son contenu sur la page, pour être récupéré par un lecteur d'écran et lu à l'utilisateur.

+ +
+

Note : Pour plus d'informations, lisez Text alternatives.

+
+ +

L'oubli de texte alt peut être testé de bien des façons, par exemple en utilisant le {{anch("Auditing tools")}} d'accessibilité.

+ +

Le texte alt est légèrement plus complexe pour du contenu vidéo ou audio. Il y a une manière de gérer l'affichage du texte (par ex. les sous-titres) et de les afficher quand la vidéo est jouée, sous le forme de l'élément {{htmlelement("track")}}, et du format WebVTT (voir Ajouter des légendes et des sous-titres à des vidéos HTML5 pour un tutoriel détaillé). La compatibilité entre navigateur pour cette fonction est assez bonne, mais si vous voulez fournir des textes alternatifs pour de l'audio ou supporter les vieux navigateurs, une simple transcription du texte présenté quelque part sur la page ou sur une page séparée peut être une bonne idée.

+ +

Relations et contexte entre élément

+ +

Il y a certaines caractéristiques et pratiques optimales en HTML conçues pour apporter du contexte et des relations entre des éléments lorsqu'aucune n'aurait autrement existé. Les trois exemples les plus courants sont les liens, les libellés de formulaire et les tableau de données.

+ +

La solution pour les textes de type lien c'est que les personnes utilisant des lecteurs d'écran vont souvent utiliser une fonctionnalité commune avec laquelle ils vont récupérer une liste de tous les liens sur la page. Par exemple, une liste de lien libellés "cliquez ici", "cliquez ici", etc. est vraiment mauvaise pour l'accessibilité. Il est préférable pour les textes de type lien d'avoir du sens en contexte et hors contexte.

+ +

Le suivant sur notre liste, l'élément de formulaire {{htmlelement("label")}} est une des fonctionnalités centrales qui nous permet de rendre les formulaires accessibles. Le problème avec les formulaires c'est que vous avez besoin de libellés pour dire quelle donnée doit être entrée dans chaque champs du formulaire. Chaque libellé doit être inclus dans un {{htmlelement("label")}} pour le relier clairement à son champs partenaire (chaque valeur de l'attribut for de <label> doit aller avec la valeur de l'id de l'élément du formulaire), et cela aura du sens même si le code source n'est pas totalement logique (ce qui pour être tout à fait juste devrait être fait).

+ +
+

Note : Lisez Meaningful text labels, pour plus d'information à propos des textes de type lien et les libellés des formulaires.

+
+ +

Pour terminer, un mot rapide sur les tableaux de données. Un tableau de données basique peut être écrit avec des indications très simples (voir bad-table.html en direct, et la source), mais il y a des problèmes — il n'y a aucun moyen pour un utilisateur de lecteur d'écran d'associer des lignes ou des colonnes ensembles comme un groupe de données — pour faire cela vous devez connaître les lignes d'en-têtes, et si elles se dirigent en lignes, colonnes, etc. Cela ne peut être fait qu'en visuel pour un tel tableau.

+ +

Si vous regardez plutôt notre exemple punk-band-complete.html (direct, source), vous pouvez voir plusieurs aides à l'accessibilité en place, comme les entêtes de tableau ({{htmlelement("th")}} et les attributs scope), l'élément {{htmlelement("caption")}}, etc.

+ +
+

Note : Lisez Accessible data tables, pour plus d'information à propos des tableaux accessibles.

+
+ +

CSS

+ +

Le CSS tend à fournir beaucoup moins de caractéristiques fondamentales d'accessibilité que le HTML, mais il peut aussi faire beaucoup de dommage à l'accessibilité s'il est mal utilisé. Nous avons déjà mentionné quelques conseils sur l'accessibilité incluant le CSS :

+ + + +

Il y a quelques autres considérations que vous devriez prendre en compte.

+ +

Couleur et contraste

+ +

Lorsque vous choisissez une palette de couleurs pour votre site web, vous devez vous assurer que la couleur du texte (au premier plan) contraste bien avec la couleur d'arrière-plan. Votre design peut avoir l'air cool, mais ce n'est pas bon si les personnes avec un handicap visuel comme le daltonisme ne peuvent pas lire votre contenu. Utilisez un outil comme le Color Contrast Checker de WebAIM si votre palette contraste suffisamment.

+ +

Une autre astuce est de ne pas compter sur une couleur seule pour les indications/informations, comme ça ne sera pas bon pour ceux qui ne peuvent pas voir la couleur. Plutôt que de marquer en rouge les champs requis d'un formulaire, par exemple, marquez-les avec un astérisque et en rouge.

+ +
+

Note : un contraste élevé permettra également à toute personnes utilisant un smartphone ou une tablette avec un écran brillant de mieux lire les pages dans un environnement lumineux, comme avec la lumière du soleil.

+
+ +

Cacher du contenu

+ +

Il y a plusieurs cas où un design visuel requerra que tout le contenu ne soit pas montré d'un seul coup. Par exemple, dans notre Exemple de boîte d'info avec onglets (voir le code source) nous avons trois panneau d'information, mais nous les positionnons les uns sur les autres et fournissons des onglets qui peuvent être cliqués pour montrer chacun d'entre eux (c'est aussi accessible au clavier — vous pouvez utiliser alternativement Tab et Entrée/Retour pour les sélectionner).

+ +

+ +

Les utilisateurs de lecteur d'écran ne se soucient pas vraiment de cela — ils sont satisfaits tant que le contenu a du sens dans le code source, et qu'ils peuvent entièrement y accéder. Le positionnement absolute (comme utilisé dans cet exemple) est souvent vu comme l'un des meilleur mécanismes pour cacher du contenu pour des effets visuels, parce que ça n'empêche pas les lecteur d'écran d'y accéder.

+ +

D'un autre côté, vous ne devriez pas utiliser {{cssxref("visibility")}}:hidden ou {{cssxref("display")}}:none, parce qu'il cache le contenu aux lecteurs d'écran. A moins que, bien entendu, il y est une bonne raison qui justifie que ce contenu soit caché aux lecteurs d'écran.

+ +
+

Note : Invisible Content Just for Screen Reader Users vous décrira beaucoup de détails utilesà propos de ce sujet.

+
+ +

JavaScript

+ +

Le JavaScript a le même type de problèmes que le CSS concernant l'accessibilité — cela peut être désastreux pour l'accessibilité si mal utilisé, ou trop utilisé. Nous avions déjà abordé quelques problèmes d'accessibilité en rapport avec le JavaScript, principalement dans le champ de la sémantique HTML — vous devez toujours utiliser une sémantique HTML appropriée pour implémenter une fonctionnalité qu'importe où elle est disponible, par exemple utiliser des liens et des boutons de façon appropriée. N'utilisez pas les éléments <div> avec du code JavaScript pour simuler une fonctionnalité si c'est possible — c'est une source d'erreur, et ça fonctionne mieux d'utiliser les fonctionnalités disponibles qu'HTML vous fournit.

+ +

Fonctionnalité simple

+ +

Normalement, une fonctionnalité simple doit marcher uniquement avec le HTML en place — le JavaScript ne doit pas être utilisé que pour améliorer la fonctionnalité, par pour la construire en entier. Les bons usages de JavaScript incluent :

+ + + +
+

Note Accessible JavaScript de WebAIM fourni des renseignements approfondis à propos des considérations pour du JavaScript accessible.

+
+ +

Les implémentations JavaScript plus complexes peuvent mener à des problèmes avec l'accessibilité — vous devez faire ce que vous pouvez. par exemple, cela ne serait pas raisonnable d'attendre de vous que vous fassiez un jeu complexe 3D écrit avec WebGL accessible à 100% pour une personne aveugle, mais vous pouvez implémenter des contrôles clavier pour qu'il soit utilisable pour un utilisateur sans souris, et réaliser une palette de couleurs suffisamment contrastée pour être utilisable par les personnes avec des lacunes pour percevoir les couleurs.

+ +

Fonctionnalité complexe

+ +

L'un des domaines de problématique principal pour l'accessibilité c'est les applis complexes qui nécessitent des contrôles de formulaires compliqués (comme les sélecteurs de date) et le contenu dynamique qui se met souvent à jour et de façon incrémentale.

+ +

Les contrôles de formulaire compliqués non natifs sont problématiques parce qu'ils ont tendance à nécessiter beaucoup de <div>s imbriquées, et le navigateur ne sait pas quoi faire par défaut avec elles. Si vous les inventer vous-même, vous devez vous assurer qu'ils sont accessibles par le clavier ; si vous utilisez des structures externes, revoyez en profondeur les options disponibles pour voir à quel point elles sont accessibles avant de vous plonger dedans. Bootstrap à l'air d'être assez bon pour l'accessibilité, par exemple, bien que Making Bootstrap a Little More Accessible de Rhiana Heath aborde certain de ses problèmes (principalement en rapport avec le contraste des couleurs), et examine certaines solutions.

+ +

Le contenu dynamique régulièrement mis à jour peut-être un problème parce que les utilisateurs de lecteur d'écran peuvent le manquer, spécialement si les mises à jour sont inattendues. Si vous avez une appli en single-page avec un contenu principal dans un panneau qui est régulièrement mis à jour en utilisant XMLHttpRequest ou Fetch, un utilisateur utilisant un lecteur d'écran peut rater ces mises à jour.

+ +

WAI-ARIA

+ +

Avez-vous besoin d'utiliser une fonctionnalité complexe, ou à la place vous le faîte avec une bonne vieille sémantique HTML ? Si vous avez besoin de complexité, vous devriez songer à utiliser WAI-ARIA (Accessible Rich Internet Applications), une spécification qui fournit une sémantique (sous la forme des nouveaux attributs HTML) pour les objets comme les contrôles complexes de formulaire et les panneaux mis à jour qui peuvent être compris par la plupart des navigateurs et les lecteurs d'écran.

+ +

Pour traiter avec les widgets complexes de formulaire, vous devez utiliser les attributs ARIA comme roles pour déclarer quel rôle les différents éléments on dans un widget (par exemple, est-ce qu'ils sont un onglet, ou un panneau ?), aria-disabled pour dire si un contrôle est désactivé ou pas, etc.

+ +

Pour traiter avec les zones de contenu qui sont régulièrement mises à jour, vous pouvez utiliser l'attribut aria-live, qui identifie une zone mise à jour. Sa valeur indique avec quelle urgence le lecteur d'écran doit faire la lecture :

+ + + +

Voici un exemple :

+ +
<p><span id="LiveRegion1" aria-live="polite" aria-atomic="false"></span></p>
+ +

Vous pouvez voir un exemple en action sur l'exemple ARIA (Accessible Rich Internet Applications) Live Regions de Freedom Scientific — le paragraphe surligné doit mettre à jour son contenu toutes les 10 secondes, et un lecteur d'écran doit le lire à l'utilisateur. ARIA Live Regions - Atomic apporte un autre exemple utile.

+ +

Nous n'avons pas de place pour couvrir WAI-ARIA en détail ici, vous pouvez en apprendre beaucoup plus à ce propos sur WAI-ARIA basics.

+ +

Les outils d'accessibilité

+ +

Maintenant que nous avons couvers les considérations de l'accessibilité pour les différentes technologies web, incluant quelques techniques de test (comme la navigation au clavier et le vérificateur de contraste de couleur), tournons-nous maintenant vers d'autres outils que vous pouvez utiliser pour faire des tests d'accessibilité.

+ +

Les outils d'audit

+ +

Il y a plusieurs outils d'audit disponibles que vous pouvez placer sur vos pages web, lesquels les examinerons et retournerons une liste de problèmes d'accessibilité présents sur la page. A titre d'exemple :

+ + + +

Observons un exemple, en utilisant Tenon.

+ +
    +
  1. Aller sur la page d'accueil de Tenon.
  2. +
  3. Entrez l'URL de notre exemple de bad-semantics.html dans l'entrée texte en haut de la page (ou l'URL d'une autre page que vous aimeriez analyser) et appuyez sur Analyse your Webpage.
  4. +
  5. Défilez vers le bas jusqu'à que vous trouviez la section d'erreur/signalement, comme montré ci-dessous.
  6. +
+ +

+ +

Il y a également des options que vous pouvez examiner (voir le lien Show Options vers le haut de la page), ainsi qu'une API pour utiliser Tenon comme un programme.

+ +
+

Note : De tels outils ne sont pas suffisant pour résoudre tous vos problèmes d'accessibilité en tant que tel. Vous devrez les combiner, savoir et expérience, test utilisateur, etc. pour vous faire une image exacte.

+
+ +

Les outils d'automatisation

+ +

Deque's aXe tool va un peu plus loin que les outils d'audit que nous avons mentionné plus haut. Comme les autres, il vérifie les pages et retourne des erreurs d'accessibilité. Sa forme immédiate la plus utile est sûrement son extension navigateur :

+ + + +

Cela ajoute un onglet accessibilité aux outils de développeur du navigateur, nous avons installé la version pour Firefox, puis nous l'avons utilisé pour auditer notre exemple bad-table.html. Nous obtenons les résultats suivants :

+ +

+ +

aXe est également installable en utilisant npm, et peut-être intégré avec des exécuteurs de tâche comme Grunt et Gulp, des frameworks d'automatisation comme Selenium et Cucumber, des framework de test unitaire comme Jasmin, et d'autres encore (une fois encore, voir la page principale d'aXe pour plus de détails).

+ +

Les lecteurs d'écran

+ +

Il faut définitivement tester avec un lecteur d'écran pour s'habituer à comment les personnes malvoyantes utilisent le Web. Il y a plusieurs lecteurs d'écran disponible : 

+ + + +

La plupart du temps, les lecteurs d'écran sont des applis séparées, qui s'exécutent sur le système d'exploitation hôte et peuvent lire des pages web, mais aussi du texte dans d'autres appli. Ce n'est pas toujours le cas (ChromeVox est une extension navigateur), mais ça l'est souvent. Les lecteurs d'écran ont tendance à agir de manière légèrement différente et ont des contrôles différents, donc vous devrez consulter la documentation pour le lecteur d'écran que vous avez choisi pour obtenir tous les détails — cela dit, il fonctionne tous à peu près de la même manière.

+ +

Commençons à effectuer quelques tests avec deux lecteurs d'écran différents pour vous donner une idée générale de comment ils fonctionnent et de comment tester avec eux.

+ +
+

Note Designing for Screen Reader Compatibility de WebAIM fournit des informations utiles à propos de l'utilisation des lecteurs d'écran et qu'est-ce qui est le plus efficace pour les lecteurs d'écran. Aller également voir Screen Reader User Survey #6 Results pour des statistiques intéressantes concernant l'utilisation de lecteur d'écran.

+
+ +

VoiceOver

+ +

VoiceOver (VO) est gratuit avec votre Mac/iPhone/iPad, donc c'est utile pour tester sur votre ordinateur/mobile si vous utilisez des produits Apple. Nous le testerons sur Mac OS X sur un MacBook Pro.

+ +

Pour le démarrer, pressez Cmd + Fn + F5. Si vous n'avez jamais utilisé VO auparavant, vous obtiendrez un écran de bienvenue où vous pouvez choisir de démarrer VO ou de ne pas le démarrer, et vous parcourrez un tutoriel utile pour apprendre à comment l'utiliser. Pour l'arrêter, pressez Cmd + Fn + F5 à nouveau.

+ +
+

Note : Vous devriez parcourir le tutoriel au moins une fois — il est vraiment très utile pour en apprendre à propos de VO.

+
+ +

Lorsque VO est démarré, l'affichage ressemblera à peu près à cela, mais vous verrez une boîte noire en bas à gauche de l'écran qui contient l'information sur quoi est-ce que VO est actuellement sélectionné. La sélection courante sera également mise en avant, avec une bordure noire — cette mise en avant est connue comme le curseur VO.

+ +

+ +

Pour utiliser VO, vous aller beaucoup utiliser le "modificateur VO" — c'est une touche ou une combinaison de touches que vous devez presser en plus de l'actuel raccourci VO pour qu'elles fonctionnent. Utiliser un modificateur comme celui-ci est courant avec les lecteurs d'écran, pour leur permettre de garder leur propres commandes en évitant d'entrer en conflit avec d'autres commandes. Dans le cas de VO, le modificateur peut aussi être VerrMaj, ou Ctrl + Option.

+ +

VO a beaucoup de commandes clavier, et nous n'allons pas toutes les lister ici. Les principales dont vous aurez besoin pour tester une page web sont dans le tableau suivant. Dans les raccourcis clavier, "VO" veut dire "le modificateur VoiceOver".

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Les raccourcis clavier VoiceOver les plus communs

+
Raccourci clavierDescription
VO + Touches du curseurDéplace le curseur VO vers le haut, la droite, le bas, la gauche.
VO + Barre espace +

Sélectionne/active les éléments mis en avant par le curseur VO. Cela inclut les items sélectionnés dans le Rotor (voir plus bas).

+
VO + Shift + curseur bas +

Se déplacer dans un groupe d'éléments (comme un tableau HTML, ou un formulaire, etc.) Une fois dans un groupe vous pouvez vous déplacer et sélectionner les éléments à l'intérieur de ce groupe en utilisant les commandes ci-dessus normalement.

+
VO + Shift + curseur hautSortir d'un groupe.
VO + C +

(à l'intérieur d'un tableau) lire l'entête de la colonne courante.

+
VO + R(à l'intérieur d'un tableau) lire l'entête de la ligne courante.
VO + C + C (deux C d'affilé)(à l'intérieur d'un tableau) lire toute la colonne courante, incluant l'entête.
VO + R + R (deux R d'affilé) +

(à l'intérieur d'un tableau) lire toute la ligne courante, incluant les entêtes qui correspondent à chacune des cellules.

+
VO + curseur gauche, VO + curseur droit(à l'intérieur d'options horizontales, comme un sélecteur de date ou de temps) Se déplacer entre les options
VO + curseur haut, VO + curseur bas(à l'intérieur d'options horizontales, comme un sélecteur de date ou de temps) Modifier l'option courante.
VO + U +

Utiliser le rotor, qui affiche des listes de rubriques, de liens, de contrôles de formulaires, etc. pour une navigation simplifiée.

+
VO + curseur gauche, VO + curseur droit +

(à l'intérieur du Rotor) Se déplacer ente les différentes listes disponibles dans le Rotor.

+
VO + curseur haut, VO + curseur bas +

(à l'intérieur du Rotor) Se déplacer entre les différents éléments dans la liste courante du Rotor.

+
Esc(à l'intérieur du Rotor) Sortir du Rotor.
Ctrl(Lorsque VO parle) Arrêter/Reprendre l'allocution.
VO + ZRelance la dernière partie de l'allocution.
VO + D +

Aller dans le Dock du Mac, pour que vous puissiez sélectionner des applis à exécuter.

+
+ +

Cela peut paraître comme beaucoup de commandes, mais pas tant que ça que vous vous y habituez, et VO vous rappelle régulièrement quels commandes utiliser dans quels cas. Essayer de tester VO maintenant ; vous pouvez dorénavant essayer de tester certains de nos exemples dans la section {{anch("Screenreader testing")}}.

+ +

NVDA

+ +

NVDA est exclusif à Windows, et vous allez devoir l'installer.

+ +
    +
  1. Téléchargez-le depuis nvaccess.org. Vous pouvez choisir si vous voulez faire une donation ou le télécharger gratuitement ; vous devrez également leur donner votre adresse e-mail avant de pouvoir le télécharger.
  2. +
  3. Une fois téléchargé, installez-le — double cliquez sur l'installeur, acceptez la licence et suivez les instructions.
  4. +
  5. Pour lancer NVDA, double cliquez sur fichier/raccourci du programme, ou utilisez le raccourci clavier Ctrl + Alt + N. Vous verrez la boîte de dialogue de bienvenue de NVDA lorsque vous le démarrez. Vous pouvez choisir ici différentes options, puis appuyez sur OK pour continuer.
  6. +
+ +

NVDA sera maintenant actif sur votre ordinateur.

+ +

Pour utiliser NVDA, vous aller beaucoup utiliser le "modificateur NVDA" — c'est une touche que vous devez presser en plus de l'actuel raccourci NVDA pour qu'elles fonctionnent. Utiliser un modificateur comme celui-ci est courant avec les lecteurs d'écran, pour leur permettre de garder leurs propres commandes en évitant d'entrer en conflit avec d'autres commandes. Dans le cas de NVDA, le modificateur peut aussi être Insert (par défaut), ou VerrMaj (peut être choisi en cochant la première case à cocher dans la boîte de dialogue de bienvenue avant d'appuyer sur OK).

+ +
+

Note : NVDA est plus subtile que VoiceOver en termes de comment il met en valeur là où il est et qu'est-ce qu'il fait. Lorsque vous défilez à travers des rubriques, listes, etc. les éléments que vous sélectionnez seront généralement mis à avant avec un contour subtile, mais ça n'est pas toujours le cas pour toutes les choses. Si vous vous retrouvez complètement perdu, vous pouvez appuyer sur Ctrl + F5 pour rafraîchir la page courante et recommencer en haut de la page.

+
+ +

NVDA a beaucoup de commandes clavier, et nous n'allons pas toutes les lister ici. Les principales dont vous aurez besoin pour tester une page web sont dans le tableau suivant. Dans les raccourcis clavier, "NVDA" veut dire "le modificateur NVDA".

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Les raccourcis clavier NVDA les plus communs
Raccourci clavierDescription
NVDA + Q +

Arrête NVDA après que vous l'ayez démarré.

+
NVDA + curseur hautLit la ligne courante.
NVDA + curseur basCommence à lire à la position courante.
curseur haut ou curseur bas, ou Shift + Tab et Tab +

Se déplace à l'élément suivant/précédent de la page et le lit.

+
curseur gauche et curseur droit +

Se déplace au caractère suivant/précédent dans l'élément courant et le lit.

+
Shift + H et H +

Se déplace au titre suivante/précédente et le lit.

+
Shift + K et K +

Se déplace au lien suivant/précédent et le lit.

+
Shift + D et D +

Se déplace au repère de document (par ex. <nav>) suivant/précédent et le lit.

+
Shift + 1–6 et 1–6 +

Se déplace au titre (niveau 1 à 6) suivant/précédent et le lit.

+
Shift + F et F +

Se déplace à l'entrée de formulaire suivante/précédente et se focalise dessus.

+
Shift + T et T +

Se déplace sur la donnée de tableau suivante/précédente et se focalise dessus.

+
Shift + B et B +

Se déplace sur le bouton suivant/précédent et lit son libellé.

+
Shift + L et L +

Se déplace à la liste suivante/précédente et lit son premier item de liste.

+
Shift + I et I +

Se déplace à l'item de liste suivant/précédent et le lit.

+
Entrée/Retour +

(quand un lien/bouton ou autre élément activable est sélectionné) Active l'élément.

+
NVDA + Barre espace +

(quand un formulaire est sélectionné) Entre dans le formulaire pour que les éléments puissent être sélectionnés individuellement, ou quitter le formulaire si vous êtes déjà dedans.

+
Shift Tab et Tab +

(à l'intérieur d'un formulaire) Se déplacer entre les entrées de formulaire.

+
Curseur haut et curseur bas +

(à l'intérieur d'un formulaire) Modifier les valeurs d'une entrée de formulaire (dans les cas comme les listes déroulantes)

+
Barre espace +

(à l'intérieur d'un formulaire) Sélectionner la valeur choisie.

+
Ctrl + Alt + touches fléchées(à l'intérieur d'un tableau) Se déplacer entre les cellules du tableau.
+ +

Test avec lecteur d'écran

+ +

Maintenant que vous vous êtes habitué à utiliser un lecteur d'écran, nous aimerions que vous vous habituiez à faire quelques tests d'accessibilité rapides, pour vous faire une idée de comment les lecteurs d'écran se débrouillent avec les bonnes et mauvaises caractéristiques d'une page web :

+ + + +

Test utilisateur

+ +

Comme mentionné plus haut, vous ne pouvez pas uniquement compter sur les outils automatisés pour déterminer les problèmes d'accessibilité sur votre site. Il est recommandé que lorsque vous établissez votre plan de test, vous devez inclure quelques groupes d'utilisateur d'accessibilité si c'est possible (voir notre section Test Utilisateur plus tôt dans ce cours pour plus de contexte). Essayez d'inclure des utilisateurs de lecteur d'écran, des utilisateurs exclusifs au clavier, des utilisateurs malentendants, et peut-être d'autres groupes encore, selon vos besoins.

+ +

Checklist de tests d'accessibilité

+ +

La liste suivante vous fournit une checklist à suivre pour vous assurer de mener à bien les tests d'accessibilité recommandés pour votre projet :

+ +
    +
  1. Assurez-vous que votre HTML est sémantiquement correct au possible. Le valider est un bon début, comme utiliser un outil d'Audit.
  2. +
  3. Vérifiez que votre contenu a du sens lorsque le CSS est désactivé.
  4. +
  5. Assurez-vous que votre fonctionnalité est accessible au clavier. Testez en utilisant Tab, Retour/Entrée, etc.
  6. +
  7. Assurez-vous que votre contenu non-textuel a un texte alternatif. Un Outil d'audit est bien pour repérer ce type de problèmes.
  8. +
  9. Assurez-vous que votre contraste de couleurs est acceptable, en utilisant un outil de vérification approprié.
  10. +
  11. Assurez-vous que le contenu caché est visible par les lecteurs d'écran.
  12. +
  13. Assurez-vous qu'une fonctionnalité est utilisable sans JavaScript autant que possible.
  14. +
  15. Utilisez ARIA pour améliorer l'accessibilité quand c'est approprié.
  16. +
  17. Exécutez votre site dans un Outil d'audit.
  18. +
  19. Testez avec un lecteur d'écran.
  20. +
  21. Incluez une politique/déclaration d'accessibilité à un endroit que l'on peut trouver sur votre site pour dire ce que vous avez fait.
  22. +
+ +

Trouver de l'aide

+ +

Il y a bien d'autres problèmes que vous allez rencontrer avec l'accessibilité ; la chose la plus importante à vraiment savoir est comment trouver des réponses en ligne. Consultez l'article la section Trouver de l'aide de l'article sur le HTML et le CSS pour des bonnes directions.

+ +

Résumé

+ +

Espérons que cet article vous aura donné des bonnes connaissances concernant les problèmes principaux d'accessibilité que vous pourrez rencontrer, et comment les tester et les surmonter.

+ +

Dans le prochain article nous nous tournerons vers la fonctionnalité de détection dans plus de détail.

+ +

{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/JavaScript","Learn/Tools_and_testing/Cross_browser_testing/Feature_detection", "Learn/Tools_and_testing/Cross_browser_testing")}}

+ +

 

+ +

Dans ce module

+ + + +

 

diff --git "a/files/fr/learn/tools_and_testing/cross_browser_testing/accessibilit\303\251/index.html" "b/files/fr/learn/tools_and_testing/cross_browser_testing/accessibilit\303\251/index.html" deleted file mode 100644 index 0af81a09b0..0000000000 --- "a/files/fr/learn/tools_and_testing/cross_browser_testing/accessibilit\303\251/index.html" +++ /dev/null @@ -1,684 +0,0 @@ ---- -title: Gérer les problèmes courants d'accessibilité -slug: Learn/Tools_and_testing/Cross_browser_testing/Accessibilité -tags: - - Accessibilité - - Apprentissage - - Article - - CSS - - Clavier - - Débutant - - HTML - - JavaScript - - Outils - - navigateur croisé - - test -translation_of: Learn/Tools_and_testing/Cross_browser_testing/Accessibility ---- -
{{LearnSidebar}}
- -
{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/JavaScript","Learn/Tools_and_testing/Cross_browser_testing/Feature_detection", "Learn/Tools_and_testing/Cross_browser_testing")}}
- -

Tournons maintenant notre attention vers l'accessibilité, les informations sur les problèmes communs, comment faire des tests simples, et comment faire pour utiliser les outils d'audit/automatisation pour trouver les problèmes d'accessibilités.

- - - - - - - - - - - - -
Prérequis : -

Connaissances avec le noyau des langages HTML, CSS et JavaScript ; une idée du haut niveau des principes du test en navigateur croisé.

-
Objectif : -

Être capable de diagnostiquer les problèmes courants d'Accessibilité, et utiliser les outils et techniques appropriés pour les résoudre.

-
- -

Qu'est-ce que l'accessibilité ?

- -

Quand on parle d'accessibilité dans le contexte de la technologie web, la plupart des gens pense directement au fait de s'assurer que les sites web/apps sont utilisables par les personnes avec des handicap, par exemple :

- - - -

Toutefois, ce serait faux de réduire l'accessibilité uniquement aux handicaps. Le vrai but de l'accessibilité est de faire en sorte que vos sites web/applis soient utilisables par le plus grand nombre de personnes dans le plus grand nombre de contextes possibles, pas uniquement ces utilisateurs qui utilisant des ordinateurs de bureau puissants. Les exemples extrêmes pourraient inclure :

- - - -

D'une certaine manière, la totalité de ce module concerne l'accessibilité — le test en navigateur croisé assure que vos sites peuvent être utilisé par le plus de personne possible. Qu'est-ce que l'accessibilité ? décrit plus largement et précisément l'accessibilité que cet article ne le fait.

- -

Cela dit, cet article couvrira les problèmes en navigateur croisé et de test entourant les personnes avec des handicaps, et comment ils utilisent le Web. Nous avons déjà parlé des autres domaines comme le responsive design et la performance à d'autres endroits dans ce module.

- -
-

Note : Comme beaucoup de choses dans le développement web, l'accessibilité ne concerne pas la totale réussite ou échec ; l'accessibilité à 100% est quasiment impossible à atteindre pour tous les contenus, spécialement quand les sites deviennent plus complexes. Il s'agit plutôt de faire un effort pour rendre votre contenu accessible au plus grand nombre de personnes possible, avec du code de prévention, et se tenir aux meilleures pratiques.

-
- -

Problèmes d'accessibilité courants

- -

Dans cette section nous détaillerons certains des problèmes principaux qui se manifestent autour de l'accessibilité, liée à des technologies spécifiques, avec les bonnes pratiques à adopter, et quelques tests rapides que vous pouvez faire pour voir si vos sites vont dans le bon sens.

- -
-

Note : L'accessibilité est moralement la bonne chose à faire, est bonne pour les affaires (nombre élevé d'utilisateurs handicapés, utilisateurs sur des appareils mobiles, etc. représentent un segment du marché signifiant), mais c'est aussi illégal dans de nombreuses régions de la planète de ne pas rendre les propriétés du web accessibles aux personnes avec des handicaps. Pour plus d'informations, lisez Accessibility guidlines and the law.

-
- -

HTML

- -

La sémantique HTML (où les éléments sont utilisés à leur fin prévues) est accessible sans aucune modification — les contenus sont lisibles par les spectateurs voyants (à condition que vous n'ayez rien fait d'absurde comme rendre le texte bien trop petit ou ne l'ayez caché en utilisant du CSS), mais il sera aussi utilisable par des technologies d'assistance comme les lecteurs d'écran (applis qui lisent littéralement une page à leurs utilisateurs), et apporte également d'autres avantages.

- -

La structure sémantique

- -

Le quick win le plus important en sémantique HTML et d'utiliser une structure de rubriques et de paragraphes pour votre contenu ; parce que les utilisateurs de lecteurs d'écran ont tendance à utiliser les rubriques d'un document comme indications pour trouver le contenu qu'il recherche plus rapidement. Si votre contenu n'a pas de rubriques, tout ce qu'ils auraient c'est un énorme mur de texte sans aucune indication pour trouver quelque chose. Exemples de bon et de mauvais HTML :

- -
<font size="7">My heading</font>
-<br><br>
-This is the first section of my document.
-<br><br>
-I'll add another paragraph here too.
-<br><br>
-<font size="5">My subheading</font>
-<br><br>
-This is the first subsection of my document. I'd love people to be able to find this content!
-<br><br>
-<font size="5">My 2nd subheading</font>
-<br><br>
-This is the second subsection of my content. I think is more interesting than the last one.
- -
<h1>My heading</h1>
-
-<p>This is the first section of my document.</p>
-
-<p>I'll add another paragraph here too.</p>
-
-<h2>My subheading</h2>
-
-<p>This is the first subsection of my document. I'd love people to be able to find this content!</p>
-
-<h2>My 2nd subheading</h2>
-
-<p>This is the second subsection of my content. I think is more interesting than the last one.</p>
- -

De plus, votre contenu doit avoir un sens logique dans son code source — vous pourrez toujours le placer où vous voulez en utilisant du CSS plus tard, mais vous devez avoir un bon code source avec lequel commencer.

- -

Comme test, vous pouvez désactiver le CSS d'un site et voir à quel point il est compréhensible sans ce dernier. Vous pouvez le faire manuellement juste en retirant le CSS de votre code, mais la façon la plus simple reste d'utiliser les fonctionnalités du navigateur, par exemple :

- - - -

Utiliser l'accessibilité native du clavier

- -

Certaines fonctionnalités HTML peuvent être sélectionnées en utilisant uniquement le clavier — c'est le comportement par défaut, disponible depuis les prémices du web. Les éléments qui ont cette capacité sont les plus communs qui permettent à l'utilisateur d'interagir avec les pages web, à savoir les liens, {{htmlelement("button")}}s, et les éléments des formulaire comme {{htmlelement("input")}}.

- -

Vous pouvez essayer ceci en utilisant notre exemple native-keyboard-accessibility.html (voir le code source) — ouvrez le dans un nouvel onglet, et essayez de presser la touche tab ; après quelques pressions, vous devriez voir la focalisation du tab commencer à se déplacer entre les différents éléments focalisables ; les éléments focalisés ont un style de mise en avant par défaut dans tous les navigateurs (cela diffère peu entre les différents navigateurs) donc vous pouvez dire quel éléments est focalisé.

- -

- -

Vous pouvez ensuite presser Entrée/Retour pour accéder à un lien focalisé ou presser un bouton (nous avons inclus un peu de JavaScript pour que les boutons renvoies un message d'alerte), ou commencer à taper pour entrer du texte dans un des input texte (d'autres éléments de formulaire ont différents contrôles, par exemple l'élément {{htmlelement("select")}} peut avoir ses options affichées et navigable en utilisant les touches haut et bas).

- -

Notez que différents navigateurs peuvent avoir différentes options de contrôle par clavier disponibles. La plupart des navigateurs modernes respectent le modèle de tab écrit plus haut (vous pouvez aussi faire une Shift + Tab pour reculer entre les éléments focalisables), mais certains navigateurs ont leurs propres particularités :

- - - -
-

Important : Vous devez jouer ce genre de test sur toutes les pages que vous écrivez — assurez-vous que la fonctionnalité peut être accessible par le clavier.

-
- -

Cet exemple souligne l'importance de l'utilisation de la sémantique correcte d'élément pour le travail correct. C'est possible de styler n'importe quel élément pour qu'il ressemble à un lien ou un bouton avec le CSS, et de le faire se comporter comme un lien ou un bouton avec JavaScript, mais ils ne seront toujours pas des liens ou des boutons, et vous perdrez beaucoup de l'accessibilité que ces éléments vous fournissent pour rien. Donc ne le faîte pas si vous pouvez l'éviter.

- -

Un autre conseil — comme vu dans notre exemple, vous pouvez contrôler comment vos éléments focalisables paraissent quand ils sont focalisés, en utilisant la pseudo-class :focus. C'est une bonne idée de doubler les styles focus et hover, comme ça vos utilisateurs auront un indice visuel qu'un contrôle fera quelque chose lorsqu'il sera activé, qu'ils utilisent la souris ou le clavier :

- -
a:hover, input:hover, button:hover, select:hover,
-a:focus, input:focus, button:focus, select:focus {
-  font-weight: bold;
-}
- -
-

Note : Si vous décidez de retirer le style focus par défaut en utilisant du CSS, assurez-vous de le remplacer par autre chose qui s'accorde au mieux avec votre design — c'est un outil d'accessibilité de grande valeur, qui ne doit pas être supprimé.

-
- -

Intégrer l'accessibilité clavier

- -

Parfois ça n'est pas possible d'éviter la perte de l'accessibilité clavier. Vous pouvez avoir hérité d'un site où la sémantique n'est pas parfaite (peut-être que vous vous êtes retrouvé avec un CMS horrible qui génère des boutons créés avec des <div>s), ou que vous utilisez un contrôle complexe qui n'a pas d'accessibilité clavier intégré, comme l'élément {{htmlelement("video")}} (étonnamment, Opera est le seul navigateur qui vous permet de tabuler dans l'élément <video> avec les contrôles par défaut du navigateur). Vous avez quelques options ici :

- -
    -
  1. Créer des contrôles personnalisés en utilisant les éléments <button> (sur lequel nous pouvons tabuler par défaut !) et JavaScript pour les relier à leur fonction. Pour des bons exemples voir Creating a cross-browser video player.
  2. -
  3. Créer des raccourcis clavier en utilisant JavaScript, les fonctions sont activés quand vous appuyez sur une certaine touche du clavier. Voir Desktop mouse and keyboard controls pour des exemples en rapport avec le jeu qui peuvent être adaptés à d'autres fins.
  4. -
  5. Utilisez des approches intéressantes pour simuler le comportement d'un bouton. Prenez par exemple notre exemple fake-div-buttons.html (voir le code source). Nous donnons à nos faux boutons <div> la capacité d'être focalisé (y compris avec la tabulation) en donnant à chacun d'entre eux l'attribut tabindex="0" (voir l'article tabindex de WebAIM pour plus de détails utiles). Cela nous permet de tabuler sur les boutons, mais pas de les activer avec la toucher Entrée/Retour. Pour faire cela, nous devons ajouter ce petit bout de tromperie en JavaScript :
  6. -
  7. -
    document.onkeydown = function(e) {
    -  if(e.keyCode === 13) { // The Enter/Return key
    -    document.activeElement.onclick(e);
    -  }
    -};
    - Ici nous ajoutons un listener à l'objet document pour détecter quand une touche a été appuyée sur le clavier. Nous vérifions quelle touche a été pressée avec la propriété d'évènement d'objet keyCode ; si c'est le code de la touche qui retourne Entrée/Retour, on exécute la fonction stockée dans le onclick du bouton en utilisant document.activeElement.onclick()activeElement nous donne l'élément courant qui est focalisé sur la page.
  8. -
- -
-

Note : Cette technique ne fonctionnera que si vous configurer vos propres gestionnaires d'évènement avec les propriétés de gestion d'évènement (par ex. onclick). addEventListener ne fonctionnera pas. C'est beaucoup de prises de tête pour construire la fonctionnalité de retour. Et il y a d'autres problèmes rattachés avec. Vaut mieux commencer par utiliser les bons éléments pour leurs buts initiaux.

-
- -

Les textes alternatifs

- -

Les textes alternatifs sont très importants pour l'accessibilité — si une personne a un trouble visuel ou auditif qui l'empêche de voir ou d'entendre un contenu, alors c'est un problème. Le texte alternatif le plus simple disponible est le modeste attribut alt, que nous devrions inclure dans toutes les images qui contiennent un contenu pertinent. Il peut contenir une description de l'image qui transmet clairement son sens et son contenu sur la page, pour être récupéré par un lecteur d'écran et lu à l'utilisateur.

- -
-

Note : Pour plus d'informations, lisez Text alternatives.

-
- -

L'oubli de texte alt peut être testé de bien des façons, par exemple en utilisant le {{anch("Auditing tools")}} d'accessibilité.

- -

Le texte alt est légèrement plus complexe pour du contenu vidéo ou audio. Il y a une manière de gérer l'affichage du texte (par ex. les sous-titres) et de les afficher quand la vidéo est jouée, sous le forme de l'élément {{htmlelement("track")}}, et du format WebVTT (voir Ajouter des légendes et des sous-titres à des vidéos HTML5 pour un tutoriel détaillé). La compatibilité entre navigateur pour cette fonction est assez bonne, mais si vous voulez fournir des textes alternatifs pour de l'audio ou supporter les vieux navigateurs, une simple transcription du texte présenté quelque part sur la page ou sur une page séparée peut être une bonne idée.

- -

Relations et contexte entre élément

- -

Il y a certaines caractéristiques et pratiques optimales en HTML conçues pour apporter du contexte et des relations entre des éléments lorsqu'aucune n'aurait autrement existé. Les trois exemples les plus courants sont les liens, les libellés de formulaire et les tableau de données.

- -

La solution pour les textes de type lien c'est que les personnes utilisant des lecteurs d'écran vont souvent utiliser une fonctionnalité commune avec laquelle ils vont récupérer une liste de tous les liens sur la page. Par exemple, une liste de lien libellés "cliquez ici", "cliquez ici", etc. est vraiment mauvaise pour l'accessibilité. Il est préférable pour les textes de type lien d'avoir du sens en contexte et hors contexte.

- -

Le suivant sur notre liste, l'élément de formulaire {{htmlelement("label")}} est une des fonctionnalités centrales qui nous permet de rendre les formulaires accessibles. Le problème avec les formulaires c'est que vous avez besoin de libellés pour dire quelle donnée doit être entrée dans chaque champs du formulaire. Chaque libellé doit être inclus dans un {{htmlelement("label")}} pour le relier clairement à son champs partenaire (chaque valeur de l'attribut for de <label> doit aller avec la valeur de l'id de l'élément du formulaire), et cela aura du sens même si le code source n'est pas totalement logique (ce qui pour être tout à fait juste devrait être fait).

- -
-

Note : Lisez Meaningful text labels, pour plus d'information à propos des textes de type lien et les libellés des formulaires.

-
- -

Pour terminer, un mot rapide sur les tableaux de données. Un tableau de données basique peut être écrit avec des indications très simples (voir bad-table.html en direct, et la source), mais il y a des problèmes — il n'y a aucun moyen pour un utilisateur de lecteur d'écran d'associer des lignes ou des colonnes ensembles comme un groupe de données — pour faire cela vous devez connaître les lignes d'en-têtes, et si elles se dirigent en lignes, colonnes, etc. Cela ne peut être fait qu'en visuel pour un tel tableau.

- -

Si vous regardez plutôt notre exemple punk-band-complete.html (direct, source), vous pouvez voir plusieurs aides à l'accessibilité en place, comme les entêtes de tableau ({{htmlelement("th")}} et les attributs scope), l'élément {{htmlelement("caption")}}, etc.

- -
-

Note : Lisez Accessible data tables, pour plus d'information à propos des tableaux accessibles.

-
- -

CSS

- -

Le CSS tend à fournir beaucoup moins de caractéristiques fondamentales d'accessibilité que le HTML, mais il peut aussi faire beaucoup de dommage à l'accessibilité s'il est mal utilisé. Nous avons déjà mentionné quelques conseils sur l'accessibilité incluant le CSS :

- - - -

Il y a quelques autres considérations que vous devriez prendre en compte.

- -

Couleur et contraste

- -

Lorsque vous choisissez une palette de couleurs pour votre site web, vous devez vous assurer que la couleur du texte (au premier plan) contraste bien avec la couleur d'arrière-plan. Votre design peut avoir l'air cool, mais ce n'est pas bon si les personnes avec un handicap visuel comme le daltonisme ne peuvent pas lire votre contenu. Utilisez un outil comme le Color Contrast Checker de WebAIM si votre palette contraste suffisamment.

- -

Une autre astuce est de ne pas compter sur une couleur seule pour les indications/informations, comme ça ne sera pas bon pour ceux qui ne peuvent pas voir la couleur. Plutôt que de marquer en rouge les champs requis d'un formulaire, par exemple, marquez-les avec un astérisque et en rouge.

- -
-

Note : un contraste élevé permettra également à toute personnes utilisant un smartphone ou une tablette avec un écran brillant de mieux lire les pages dans un environnement lumineux, comme avec la lumière du soleil.

-
- -

Cacher du contenu

- -

Il y a plusieurs cas où un design visuel requerra que tout le contenu ne soit pas montré d'un seul coup. Par exemple, dans notre Exemple de boîte d'info avec onglets (voir le code source) nous avons trois panneau d'information, mais nous les positionnons les uns sur les autres et fournissons des onglets qui peuvent être cliqués pour montrer chacun d'entre eux (c'est aussi accessible au clavier — vous pouvez utiliser alternativement Tab et Entrée/Retour pour les sélectionner).

- -

- -

Les utilisateurs de lecteur d'écran ne se soucient pas vraiment de cela — ils sont satisfaits tant que le contenu a du sens dans le code source, et qu'ils peuvent entièrement y accéder. Le positionnement absolute (comme utilisé dans cet exemple) est souvent vu comme l'un des meilleur mécanismes pour cacher du contenu pour des effets visuels, parce que ça n'empêche pas les lecteur d'écran d'y accéder.

- -

D'un autre côté, vous ne devriez pas utiliser {{cssxref("visibility")}}:hidden ou {{cssxref("display")}}:none, parce qu'il cache le contenu aux lecteurs d'écran. A moins que, bien entendu, il y est une bonne raison qui justifie que ce contenu soit caché aux lecteurs d'écran.

- -
-

Note : Invisible Content Just for Screen Reader Users vous décrira beaucoup de détails utilesà propos de ce sujet.

-
- -

JavaScript

- -

Le JavaScript a le même type de problèmes que le CSS concernant l'accessibilité — cela peut être désastreux pour l'accessibilité si mal utilisé, ou trop utilisé. Nous avions déjà abordé quelques problèmes d'accessibilité en rapport avec le JavaScript, principalement dans le champ de la sémantique HTML — vous devez toujours utiliser une sémantique HTML appropriée pour implémenter une fonctionnalité qu'importe où elle est disponible, par exemple utiliser des liens et des boutons de façon appropriée. N'utilisez pas les éléments <div> avec du code JavaScript pour simuler une fonctionnalité si c'est possible — c'est une source d'erreur, et ça fonctionne mieux d'utiliser les fonctionnalités disponibles qu'HTML vous fournit.

- -

Fonctionnalité simple

- -

Normalement, une fonctionnalité simple doit marcher uniquement avec le HTML en place — le JavaScript ne doit pas être utilisé que pour améliorer la fonctionnalité, par pour la construire en entier. Les bons usages de JavaScript incluent :

- - - -
-

Note Accessible JavaScript de WebAIM fourni des renseignements approfondis à propos des considérations pour du JavaScript accessible.

-
- -

Les implémentations JavaScript plus complexes peuvent mener à des problèmes avec l'accessibilité — vous devez faire ce que vous pouvez. par exemple, cela ne serait pas raisonnable d'attendre de vous que vous fassiez un jeu complexe 3D écrit avec WebGL accessible à 100% pour une personne aveugle, mais vous pouvez implémenter des contrôles clavier pour qu'il soit utilisable pour un utilisateur sans souris, et réaliser une palette de couleurs suffisamment contrastée pour être utilisable par les personnes avec des lacunes pour percevoir les couleurs.

- -

Fonctionnalité complexe

- -

L'un des domaines de problématique principal pour l'accessibilité c'est les applis complexes qui nécessitent des contrôles de formulaires compliqués (comme les sélecteurs de date) et le contenu dynamique qui se met souvent à jour et de façon incrémentale.

- -

Les contrôles de formulaire compliqués non natifs sont problématiques parce qu'ils ont tendance à nécessiter beaucoup de <div>s imbriquées, et le navigateur ne sait pas quoi faire par défaut avec elles. Si vous les inventer vous-même, vous devez vous assurer qu'ils sont accessibles par le clavier ; si vous utilisez des structures externes, revoyez en profondeur les options disponibles pour voir à quel point elles sont accessibles avant de vous plonger dedans. Bootstrap à l'air d'être assez bon pour l'accessibilité, par exemple, bien que Making Bootstrap a Little More Accessible de Rhiana Heath aborde certain de ses problèmes (principalement en rapport avec le contraste des couleurs), et examine certaines solutions.

- -

Le contenu dynamique régulièrement mis à jour peut-être un problème parce que les utilisateurs de lecteur d'écran peuvent le manquer, spécialement si les mises à jour sont inattendues. Si vous avez une appli en single-page avec un contenu principal dans un panneau qui est régulièrement mis à jour en utilisant XMLHttpRequest ou Fetch, un utilisateur utilisant un lecteur d'écran peut rater ces mises à jour.

- -

WAI-ARIA

- -

Avez-vous besoin d'utiliser une fonctionnalité complexe, ou à la place vous le faîte avec une bonne vieille sémantique HTML ? Si vous avez besoin de complexité, vous devriez songer à utiliser WAI-ARIA (Accessible Rich Internet Applications), une spécification qui fournit une sémantique (sous la forme des nouveaux attributs HTML) pour les objets comme les contrôles complexes de formulaire et les panneaux mis à jour qui peuvent être compris par la plupart des navigateurs et les lecteurs d'écran.

- -

Pour traiter avec les widgets complexes de formulaire, vous devez utiliser les attributs ARIA comme roles pour déclarer quel rôle les différents éléments on dans un widget (par exemple, est-ce qu'ils sont un onglet, ou un panneau ?), aria-disabled pour dire si un contrôle est désactivé ou pas, etc.

- -

Pour traiter avec les zones de contenu qui sont régulièrement mises à jour, vous pouvez utiliser l'attribut aria-live, qui identifie une zone mise à jour. Sa valeur indique avec quelle urgence le lecteur d'écran doit faire la lecture :

- - - -

Voici un exemple :

- -
<p><span id="LiveRegion1" aria-live="polite" aria-atomic="false"></span></p>
- -

Vous pouvez voir un exemple en action sur l'exemple ARIA (Accessible Rich Internet Applications) Live Regions de Freedom Scientific — le paragraphe surligné doit mettre à jour son contenu toutes les 10 secondes, et un lecteur d'écran doit le lire à l'utilisateur. ARIA Live Regions - Atomic apporte un autre exemple utile.

- -

Nous n'avons pas de place pour couvrir WAI-ARIA en détail ici, vous pouvez en apprendre beaucoup plus à ce propos sur WAI-ARIA basics.

- -

Les outils d'accessibilité

- -

Maintenant que nous avons couvers les considérations de l'accessibilité pour les différentes technologies web, incluant quelques techniques de test (comme la navigation au clavier et le vérificateur de contraste de couleur), tournons-nous maintenant vers d'autres outils que vous pouvez utiliser pour faire des tests d'accessibilité.

- -

Les outils d'audit

- -

Il y a plusieurs outils d'audit disponibles que vous pouvez placer sur vos pages web, lesquels les examinerons et retournerons une liste de problèmes d'accessibilité présents sur la page. A titre d'exemple :

- - - -

Observons un exemple, en utilisant Tenon.

- -
    -
  1. Aller sur la page d'accueil de Tenon.
  2. -
  3. Entrez l'URL de notre exemple de bad-semantics.html dans l'entrée texte en haut de la page (ou l'URL d'une autre page que vous aimeriez analyser) et appuyez sur Analyse your Webpage.
  4. -
  5. Défilez vers le bas jusqu'à que vous trouviez la section d'erreur/signalement, comme montré ci-dessous.
  6. -
- -

- -

Il y a également des options que vous pouvez examiner (voir le lien Show Options vers le haut de la page), ainsi qu'une API pour utiliser Tenon comme un programme.

- -
-

Note : De tels outils ne sont pas suffisant pour résoudre tous vos problèmes d'accessibilité en tant que tel. Vous devrez les combiner, savoir et expérience, test utilisateur, etc. pour vous faire une image exacte.

-
- -

Les outils d'automatisation

- -

Deque's aXe tool va un peu plus loin que les outils d'audit que nous avons mentionné plus haut. Comme les autres, il vérifie les pages et retourne des erreurs d'accessibilité. Sa forme immédiate la plus utile est sûrement son extension navigateur :

- - - -

Cela ajoute un onglet accessibilité aux outils de développeur du navigateur, nous avons installé la version pour Firefox, puis nous l'avons utilisé pour auditer notre exemple bad-table.html. Nous obtenons les résultats suivants :

- -

- -

aXe est également installable en utilisant npm, et peut-être intégré avec des exécuteurs de tâche comme Grunt et Gulp, des frameworks d'automatisation comme Selenium et Cucumber, des framework de test unitaire comme Jasmin, et d'autres encore (une fois encore, voir la page principale d'aXe pour plus de détails).

- -

Les lecteurs d'écran

- -

Il faut définitivement tester avec un lecteur d'écran pour s'habituer à comment les personnes malvoyantes utilisent le Web. Il y a plusieurs lecteurs d'écran disponible : 

- - - -

La plupart du temps, les lecteurs d'écran sont des applis séparées, qui s'exécutent sur le système d'exploitation hôte et peuvent lire des pages web, mais aussi du texte dans d'autres appli. Ce n'est pas toujours le cas (ChromeVox est une extension navigateur), mais ça l'est souvent. Les lecteurs d'écran ont tendance à agir de manière légèrement différente et ont des contrôles différents, donc vous devrez consulter la documentation pour le lecteur d'écran que vous avez choisi pour obtenir tous les détails — cela dit, il fonctionne tous à peu près de la même manière.

- -

Commençons à effectuer quelques tests avec deux lecteurs d'écran différents pour vous donner une idée générale de comment ils fonctionnent et de comment tester avec eux.

- -
-

Note Designing for Screen Reader Compatibility de WebAIM fournit des informations utiles à propos de l'utilisation des lecteurs d'écran et qu'est-ce qui est le plus efficace pour les lecteurs d'écran. Aller également voir Screen Reader User Survey #6 Results pour des statistiques intéressantes concernant l'utilisation de lecteur d'écran.

-
- -

VoiceOver

- -

VoiceOver (VO) est gratuit avec votre Mac/iPhone/iPad, donc c'est utile pour tester sur votre ordinateur/mobile si vous utilisez des produits Apple. Nous le testerons sur Mac OS X sur un MacBook Pro.

- -

Pour le démarrer, pressez Cmd + Fn + F5. Si vous n'avez jamais utilisé VO auparavant, vous obtiendrez un écran de bienvenue où vous pouvez choisir de démarrer VO ou de ne pas le démarrer, et vous parcourrez un tutoriel utile pour apprendre à comment l'utiliser. Pour l'arrêter, pressez Cmd + Fn + F5 à nouveau.

- -
-

Note : Vous devriez parcourir le tutoriel au moins une fois — il est vraiment très utile pour en apprendre à propos de VO.

-
- -

Lorsque VO est démarré, l'affichage ressemblera à peu près à cela, mais vous verrez une boîte noire en bas à gauche de l'écran qui contient l'information sur quoi est-ce que VO est actuellement sélectionné. La sélection courante sera également mise en avant, avec une bordure noire — cette mise en avant est connue comme le curseur VO.

- -

- -

Pour utiliser VO, vous aller beaucoup utiliser le "modificateur VO" — c'est une touche ou une combinaison de touches que vous devez presser en plus de l'actuel raccourci VO pour qu'elles fonctionnent. Utiliser un modificateur comme celui-ci est courant avec les lecteurs d'écran, pour leur permettre de garder leur propres commandes en évitant d'entrer en conflit avec d'autres commandes. Dans le cas de VO, le modificateur peut aussi être VerrMaj, ou Ctrl + Option.

- -

VO a beaucoup de commandes clavier, et nous n'allons pas toutes les lister ici. Les principales dont vous aurez besoin pour tester une page web sont dans le tableau suivant. Dans les raccourcis clavier, "VO" veut dire "le modificateur VoiceOver".

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

Les raccourcis clavier VoiceOver les plus communs

-
Raccourci clavierDescription
VO + Touches du curseurDéplace le curseur VO vers le haut, la droite, le bas, la gauche.
VO + Barre espace -

Sélectionne/active les éléments mis en avant par le curseur VO. Cela inclut les items sélectionnés dans le Rotor (voir plus bas).

-
VO + Shift + curseur bas -

Se déplacer dans un groupe d'éléments (comme un tableau HTML, ou un formulaire, etc.) Une fois dans un groupe vous pouvez vous déplacer et sélectionner les éléments à l'intérieur de ce groupe en utilisant les commandes ci-dessus normalement.

-
VO + Shift + curseur hautSortir d'un groupe.
VO + C -

(à l'intérieur d'un tableau) lire l'entête de la colonne courante.

-
VO + R(à l'intérieur d'un tableau) lire l'entête de la ligne courante.
VO + C + C (deux C d'affilé)(à l'intérieur d'un tableau) lire toute la colonne courante, incluant l'entête.
VO + R + R (deux R d'affilé) -

(à l'intérieur d'un tableau) lire toute la ligne courante, incluant les entêtes qui correspondent à chacune des cellules.

-
VO + curseur gauche, VO + curseur droit(à l'intérieur d'options horizontales, comme un sélecteur de date ou de temps) Se déplacer entre les options
VO + curseur haut, VO + curseur bas(à l'intérieur d'options horizontales, comme un sélecteur de date ou de temps) Modifier l'option courante.
VO + U -

Utiliser le rotor, qui affiche des listes de rubriques, de liens, de contrôles de formulaires, etc. pour une navigation simplifiée.

-
VO + curseur gauche, VO + curseur droit -

(à l'intérieur du Rotor) Se déplacer ente les différentes listes disponibles dans le Rotor.

-
VO + curseur haut, VO + curseur bas -

(à l'intérieur du Rotor) Se déplacer entre les différents éléments dans la liste courante du Rotor.

-
Esc(à l'intérieur du Rotor) Sortir du Rotor.
Ctrl(Lorsque VO parle) Arrêter/Reprendre l'allocution.
VO + ZRelance la dernière partie de l'allocution.
VO + D -

Aller dans le Dock du Mac, pour que vous puissiez sélectionner des applis à exécuter.

-
- -

Cela peut paraître comme beaucoup de commandes, mais pas tant que ça que vous vous y habituez, et VO vous rappelle régulièrement quels commandes utiliser dans quels cas. Essayer de tester VO maintenant ; vous pouvez dorénavant essayer de tester certains de nos exemples dans la section {{anch("Screenreader testing")}}.

- -

NVDA

- -

NVDA est exclusif à Windows, et vous allez devoir l'installer.

- -
    -
  1. Téléchargez-le depuis nvaccess.org. Vous pouvez choisir si vous voulez faire une donation ou le télécharger gratuitement ; vous devrez également leur donner votre adresse e-mail avant de pouvoir le télécharger.
  2. -
  3. Une fois téléchargé, installez-le — double cliquez sur l'installeur, acceptez la licence et suivez les instructions.
  4. -
  5. Pour lancer NVDA, double cliquez sur fichier/raccourci du programme, ou utilisez le raccourci clavier Ctrl + Alt + N. Vous verrez la boîte de dialogue de bienvenue de NVDA lorsque vous le démarrez. Vous pouvez choisir ici différentes options, puis appuyez sur OK pour continuer.
  6. -
- -

NVDA sera maintenant actif sur votre ordinateur.

- -

Pour utiliser NVDA, vous aller beaucoup utiliser le "modificateur NVDA" — c'est une touche que vous devez presser en plus de l'actuel raccourci NVDA pour qu'elles fonctionnent. Utiliser un modificateur comme celui-ci est courant avec les lecteurs d'écran, pour leur permettre de garder leurs propres commandes en évitant d'entrer en conflit avec d'autres commandes. Dans le cas de NVDA, le modificateur peut aussi être Insert (par défaut), ou VerrMaj (peut être choisi en cochant la première case à cocher dans la boîte de dialogue de bienvenue avant d'appuyer sur OK).

- -
-

Note : NVDA est plus subtile que VoiceOver en termes de comment il met en valeur là où il est et qu'est-ce qu'il fait. Lorsque vous défilez à travers des rubriques, listes, etc. les éléments que vous sélectionnez seront généralement mis à avant avec un contour subtile, mais ça n'est pas toujours le cas pour toutes les choses. Si vous vous retrouvez complètement perdu, vous pouvez appuyer sur Ctrl + F5 pour rafraîchir la page courante et recommencer en haut de la page.

-
- -

NVDA a beaucoup de commandes clavier, et nous n'allons pas toutes les lister ici. Les principales dont vous aurez besoin pour tester une page web sont dans le tableau suivant. Dans les raccourcis clavier, "NVDA" veut dire "le modificateur NVDA".

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Les raccourcis clavier NVDA les plus communs
Raccourci clavierDescription
NVDA + Q -

Arrête NVDA après que vous l'ayez démarré.

-
NVDA + curseur hautLit la ligne courante.
NVDA + curseur basCommence à lire à la position courante.
curseur haut ou curseur bas, ou Shift + Tab et Tab -

Se déplace à l'élément suivant/précédent de la page et le lit.

-
curseur gauche et curseur droit -

Se déplace au caractère suivant/précédent dans l'élément courant et le lit.

-
Shift + H et H -

Se déplace au titre suivante/précédente et le lit.

-
Shift + K et K -

Se déplace au lien suivant/précédent et le lit.

-
Shift + D et D -

Se déplace au repère de document (par ex. <nav>) suivant/précédent et le lit.

-
Shift + 1–6 et 1–6 -

Se déplace au titre (niveau 1 à 6) suivant/précédent et le lit.

-
Shift + F et F -

Se déplace à l'entrée de formulaire suivante/précédente et se focalise dessus.

-
Shift + T et T -

Se déplace sur la donnée de tableau suivante/précédente et se focalise dessus.

-
Shift + B et B -

Se déplace sur le bouton suivant/précédent et lit son libellé.

-
Shift + L et L -

Se déplace à la liste suivante/précédente et lit son premier item de liste.

-
Shift + I et I -

Se déplace à l'item de liste suivant/précédent et le lit.

-
Entrée/Retour -

(quand un lien/bouton ou autre élément activable est sélectionné) Active l'élément.

-
NVDA + Barre espace -

(quand un formulaire est sélectionné) Entre dans le formulaire pour que les éléments puissent être sélectionnés individuellement, ou quitter le formulaire si vous êtes déjà dedans.

-
Shift Tab et Tab -

(à l'intérieur d'un formulaire) Se déplacer entre les entrées de formulaire.

-
Curseur haut et curseur bas -

(à l'intérieur d'un formulaire) Modifier les valeurs d'une entrée de formulaire (dans les cas comme les listes déroulantes)

-
Barre espace -

(à l'intérieur d'un formulaire) Sélectionner la valeur choisie.

-
Ctrl + Alt + touches fléchées(à l'intérieur d'un tableau) Se déplacer entre les cellules du tableau.
- -

Test avec lecteur d'écran

- -

Maintenant que vous vous êtes habitué à utiliser un lecteur d'écran, nous aimerions que vous vous habituiez à faire quelques tests d'accessibilité rapides, pour vous faire une idée de comment les lecteurs d'écran se débrouillent avec les bonnes et mauvaises caractéristiques d'une page web :

- - - -

Test utilisateur

- -

Comme mentionné plus haut, vous ne pouvez pas uniquement compter sur les outils automatisés pour déterminer les problèmes d'accessibilité sur votre site. Il est recommandé que lorsque vous établissez votre plan de test, vous devez inclure quelques groupes d'utilisateur d'accessibilité si c'est possible (voir notre section Test Utilisateur plus tôt dans ce cours pour plus de contexte). Essayez d'inclure des utilisateurs de lecteur d'écran, des utilisateurs exclusifs au clavier, des utilisateurs malentendants, et peut-être d'autres groupes encore, selon vos besoins.

- -

Checklist de tests d'accessibilité

- -

La liste suivante vous fournit une checklist à suivre pour vous assurer de mener à bien les tests d'accessibilité recommandés pour votre projet :

- -
    -
  1. Assurez-vous que votre HTML est sémantiquement correct au possible. Le valider est un bon début, comme utiliser un outil d'Audit.
  2. -
  3. Vérifiez que votre contenu a du sens lorsque le CSS est désactivé.
  4. -
  5. Assurez-vous que votre fonctionnalité est accessible au clavier. Testez en utilisant Tab, Retour/Entrée, etc.
  6. -
  7. Assurez-vous que votre contenu non-textuel a un texte alternatif. Un Outil d'audit est bien pour repérer ce type de problèmes.
  8. -
  9. Assurez-vous que votre contraste de couleurs est acceptable, en utilisant un outil de vérification approprié.
  10. -
  11. Assurez-vous que le contenu caché est visible par les lecteurs d'écran.
  12. -
  13. Assurez-vous qu'une fonctionnalité est utilisable sans JavaScript autant que possible.
  14. -
  15. Utilisez ARIA pour améliorer l'accessibilité quand c'est approprié.
  16. -
  17. Exécutez votre site dans un Outil d'audit.
  18. -
  19. Testez avec un lecteur d'écran.
  20. -
  21. Incluez une politique/déclaration d'accessibilité à un endroit que l'on peut trouver sur votre site pour dire ce que vous avez fait.
  22. -
- -

Trouver de l'aide

- -

Il y a bien d'autres problèmes que vous allez rencontrer avec l'accessibilité ; la chose la plus importante à vraiment savoir est comment trouver des réponses en ligne. Consultez l'article la section Trouver de l'aide de l'article sur le HTML et le CSS pour des bonnes directions.

- -

Résumé

- -

Espérons que cet article vous aura donné des bonnes connaissances concernant les problèmes principaux d'accessibilité que vous pourrez rencontrer, et comment les tester et les surmonter.

- -

Dans le prochain article nous nous tournerons vers la fonctionnalité de détection dans plus de détail.

- -

{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/JavaScript","Learn/Tools_and_testing/Cross_browser_testing/Feature_detection", "Learn/Tools_and_testing/Cross_browser_testing")}}

- -

 

- -

Dans ce module

- - - -

 

diff --git a/files/fr/learn/tools_and_testing/cross_browser_testing/html_and_css/index.html b/files/fr/learn/tools_and_testing/cross_browser_testing/html_and_css/index.html new file mode 100644 index 0000000000..7b2a01fc95 --- /dev/null +++ b/files/fr/learn/tools_and_testing/cross_browser_testing/html_and_css/index.html @@ -0,0 +1,509 @@ +--- +title: Gérer les problèmes courants en HTML et CSS +slug: Learn/Tools_and_testing/Cross_browser_testing/HTML_et_CSS +tags: + - Apprentissage + - CSS + - Débutant + - HTML + - Sélecteurs + - linting + - navigateur croisé + - test +translation_of: Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS +--- +
{{LearnSidebar}}
+ +
{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/Testing_strategies","Learn/Tools_and_testing/Cross_browser_testing/JavaScript", "Learn/Tools_and_testing/Cross_browser_testing")}}
+ +

Maintenant que les bases sont posées, nous allons nous concentrer sur les problèmes courants en navigateur croisé que vous allez rencontrer en code HTML et CSS, et quels outils peuvent être utilisés pour prévenir l'arrivée de ces problèmes, ou résoudre les problèmes qui surviennent. Cela inclut le linting code, la gestion des préfixes CSS, l'utilisation des outils de dev des navigateurs pour localiser les problèmes, utiliser des polyfills pour apporter du support dans les navigateurs, se confronter aux problèmes de responsive design et plus encore.

+ + + + + + + + + + + + +
Prérequis : +

Connaissances avec le noyau des langages HTML, CSS, et JavaScript ; une idée du haut niveau des principes du test en navigateur croisé.

+
Objectif : +

Etre capable de diagnostiquer des problèmes courants de CSS et de HTML en navigateur croisé, et utiliser les techniques et outils appropriés pour les réparer.

+
+ +

Les difficultés avec HTML et CSS

+ +

Certains des problèmes avec le HTML et le CSS viennent du fait qu'ils sont tous les deux des langages qui sont assez simples, et souvent les développeurs ne les considèrent pas sérieusement, en termes de s'assurer que le code est bien conçu, efficace, et qu'il décrit sémantiquement les but de la fonctionnalité sur la page. Dans les pires des cas, Javascript est utilisé pour générer tout le contenu et le style d'une page web, ce qui rend vos pages inaccessibles, et moins performantes (générer des éléments de DOM est coûteux). Dans d'autres cas, des fonctionnalités naissantes ne sont pas supportées constamment par tous les navigateurs, ce qui peut empêcher certaines fonctionnalités et styles de fonctionner pour certains utilisateurs. Les problèmes de responsive design sont également courant — un site qui paraît bien sur le navigateur d'un ordinateur de bureau pourra fournir une expérience horrible sur un appareil mobile, à cause du contenu qui est trop petit pour être lu, ou peut-être que le site sera lent à cause de animations coûteuses.

+ +

Commençons et regardons comment nous pouvons réduire les erreurs en navigateur croisé issues du HTML/CSS.

+ +

Commençons par le commencement : résoudre les problèmes généraux

+ +

Nous disions dans le premier article de cette série que c'était une bonne stratégie de commencer à tester sur une paire de navigateurs modernes sur desktop/mobile, afin de vous assurer que votre site fonctionne pour l'essentiel, avant de commencer à se concentrer sur les problèmes en navigateur croisé.

+ +

Dans nos articles Debugging HTML et Debugging CSS, nous avancions quelques conseils très basiques sur le débogage HTML/CSS — si vous ne maîtrisez pas ces bases, vous devriez sans aucun doute aller étudier ces articles avant de continuer.

+ +

Il s'agit essentiellement de vérifier si votre code HTML et CSS est bien conçu et s'il ne contient aucune erreur de syntaxe.

+ +
+

Note : Un problème fréquent avec le HTML et le CSS arrive quand différentes règles CSS commencent à entrer en conflit avec une autre. Cela peut être particulièrement problématique lorsque vous utilisez un bout de code tierce. Par exemple, vous pouvez utiliser un modèle CSS et remarquer qu'un des noms de classe qui est utilisé entre en conflit avec un que vous utilisez déjà dans un but différent. Ou vous pouvez trouver que du HTML généré par une API tierce (générateur de bannières publicitaires, par exemple) inclut un nom de classe ou d'ID que vous utilisez déjà dans un but différent. Afin de garantir que cela ne se produira pas, vous devez rechercher les outils que vous allez utiliser en premier et construire votre code en conséquence. Il convient également de relever les "espace de noms" en CSS, par ex. si vous avez un widget, assurez-vous qu'il a des classes distinctes, et ensuite commencez les sélecteurs qui sélectionnent les éléments à l'intérieur du widget avec cette classe, les conflits risqueront moins d'arriver. Par exemple .audio-player ul a.

+
+ +

La validation

+ +

Pour le HTML, la validation implique de s'assurer que toutes vos balises sont correctement fermées et imbriquées, que vous utilisez un DOCTYPE, et que vous utilisez les balises à leur fin prévue. Une bonne stratégie est de valider régulièrement votre code. On service qui peut le faire est le W3C Markup Validation Service, qui vous permet de montrer votre code, et retourne une liste d'erreurs :

+ +

The HTML validator homepage

+ +

Le CSS a une histoire semblable — vous devez vérifier que vos noms de propriétés sont correctement épelés, ques les valeurs des propriétés sont correctement épelées et qu'elles sont valides pour les propriétés auxquelles elles s'appliquent, que vous n'oubliez aucune accolades ouvrantes et fermantes. Les W3C a un CSS Validator également disponible à cet effet.

+ +

Les linters

+ +

Une autre bonne option à envisager est ce qu'on appelle les applications Linter, qui ne font pas que souligner les erreurs, mais peuvent aussi mettre en évidence des avertissements à propos des mauvaises pratiques dans votre CSS, et encore d'autres points. Les linters peuvent pour la plupart être configurés pour être plus strictes ou plus coulants dans leur rapport d'erreur/avertissement.

+ +

Il y a beaucoup d'applications linter en ligne, les meilleures d'entre elles sont probablement Dirty Markup (HTML, CSS, JavaScript), et CSS Lint (seulement CSS). Elles vous permettent de coller votre code dans une fenêtre, et mettront en évidence toutes les erreurs avec des croix, qui peuvent être survolées pour obtenir un message d'erreur décrivant le problème. Dirty Markup vous permet également de faire des fixs dans votre code en utilisant le bouton Clean.

+ +

+ +

Néanmoins, ce n'est pas très pratique de devoir copier et coller votre code dans une page web pour vérifier sa validité plusieurs fois. Ce dont vous avez vraiment besoin c'est d'un linter qui s'installera dans votre espace de travail standard avec le minimum de prise de tête.

+ + + +

La plupart des éditeurs de code ont leur plugins linter. Par exemple, l'éditeur de code Atom de Github possède un riche écosystème de plugins disponibles, avec beaucoup d'options de linting. Voici un exemple pour vous montrer comment un plugin marche généralement :

+ +
    +
  1. Installer Atom (si vous n'avez pas déjà une version à jour installée) — télécharger-le depuis la page Atom indiquée plus haut.
  2. +
  3. Aller dans la boîte de dialogue Préférences... d'Atom (par ex. en sélectionnant Atom > Préférences... sur Mac, ou Fichier > Préférences... sur Windows/Linux) et choisissez l'option Installer dans le menu gauche.
  4. +
  5. Dans le champs texte Rechercher des packages, taper "lint" et presser Entrer/Envoyer pour rechercher des packages liés au linting.
  6. +
  7. Vous devriez voir un package appelé lint dans le haut de la liste. Installez celui-ci en premier (en utilisant le bouton Installer), comme les autres linters lui font appel pour fonctionner. Ensuite, installer le plugin linter-csslint pour le linting CSS, et le plugin linter-tidy pour le linting HTML.
  8. +
  9. Une fois que les packages ont fini de s'installer, essayer de charger un fichier HTML et un fichier CSS : vous verrez plusieurs zones soulignées en vert (pour les avertissements) et des cercles rouges (pour les erreurs) à côté des numéros de ligne, et un panneau séparé en bas qui affiche les numéros de ligne, les messages d'erreur, et parfois qui vous suggère des valeur par défaut ou d'autres solutions.
  10. +
+ + + +

+ +

D'autres éditeurs populaires ont des packages de linting similaires. Voir, par exemple :

+ + + +

Les outils de développement des navigateurs

+ +

Les outils de développement inclus dans la plupart des navigateurs fournissent également des outils pour traquer les erreurs, en particulier pour le CSS.

+ +
+

Note : Les erreurs HTML n'ont pas tendance à se montrer facilement avec les outils de dev, étant donné que le navigateur va essayer de corriger en fermant automatiquement mal les balises ; le validateur W3C est la meilleure façon d'obtenir des erreurs HTML — voir {{anch("Validation")}} plus haut.

+
+ +

As an example, in Firefox the CSS inspector will show CSS declarations that aren't applied crossed out, with a warning triangle. Hovering the warning triangle will provide a descriptive error message:

+ +

+ +

Les outils de dev des autres navigateurs ont des fonctionnalités semblables.

+ +

Problèmes fréquents en navigateur croisé

+ +

Attaquons-nous maintenant à certains des problèmes HTML et CSS les plus courants en navigateur croisé. Les sujets principaux que nous allons aborder sont l'absence de support pour les fonctionnalités modernes, et les problèmes de mise en page.

+ +

Les vieux navigateurs ne supportant pas les fonctionnalités récentes

+ +

C'est un problème courant, particulièrement lorsque vous devez supporter de vieux navigateurs (comme les anciennes versions d'IE) ou que vous utilisez des fonctionnalités qui sont implémentées en utilisant des préfixes CSS. En général, les fonctionnalités principales du HTML et du CSS (comme les éléments HTML basiques, les couleurs et styles de texte principaux de CSS) marchent sur la plupart des navigateurs que vous voulez supporter ; la majorité des problèmes sont découverts lorsque que vous commencez à vouloir utiliser des nouveautés comme Flexbox, ou HTML5 video/audio, ou encore plus récent, CSS Grids ou -webkit-background-clip: text.

+ +

Une fois que vous avez identifié une liste des potentielles technologies à problèmes que vous allez utiliser, c'est une bonne initiative des rechercher sur quels navigateurs elles sont supportées, et quelles techniques associées sont utiles. Voir {{anch("Finding help")}} plus bas.

+ +

Comportement naturel du HTML

+ +

Certains problèmes peuvent être résolus, seulement en tirant parti des réactions naturelles du HTML/CSS.

+ +

Les éléments HTML non reconnus sont traités par les navigateurs comme des éléments inline anonymes (véritablement des éléments inline avec aucune valeur sémantiques, similaires aux éléments {{htmlelement("span")}} ). Vous pouvez toujours vous référez à eux avec leurs noms, et les styler avec du CSS, par exemple — vous avez juste besoin de vous assurer qu'ils se comportent comme vous le voulez, par exemple configurer display: block; sur tous les nouveaux éléments sémantiques (comme {{htmlelement("article")}}, {{htmlelement("aside")}}, etc.), mais seulement sur les vieilles versions d'IE qui ne les reconnaissent pas (donc, IE 8 et plus faible). De cette façon les nouveaux navigateurs peuvent juste utiliser le code normalement, mais les anciennes versions d'IE seront également capables de styler ces éléments.

+ +
+

Note : Voir {{anch("IE conditional comments")}} pour une application efficace.

+
+ + + +

Des éléments HTML plus complexes comme <video>, <audio>, et <canvas> (et encore d'autres) ont des mécanismes naturels pour que les recours soient ajoutés, qui se basent sur le même principe décrit plus haut. Vous pouvez ajouter un contenu de repli entre la balise ouvrante et fermante, et les navigateurs ne supportant pas la feature vont effectivement ignorer les éléments extérieurs et exécuter le contenu imbriqué.

+ +

Par exemple :

+ +
<video id="video" controls preload="metadata" poster="img/poster.jpg">
+  <source src="video/tears-of-steel-battle-clip-medium.mp4" type="video/mp4">
+  <source src="video/tears-of-steel-battle-clip-medium.webm" type="video/webm">
+  <source src="video/tears-of-steel-battle-clip-medium.ogg" type="video/ogg">
+  <!-- Flash fallback -->
+  <object type="application/x-shockwave-flash" data="flash-player.swf?videoUrl=video/tears-of-steel-battle-clip-medium.mp4" width="1024" height="576">
+     <param name="movie" value="flash-player.swf?videoUrl=video/tears-of-steel-battle-clip-medium.mp4" />
+     <param name="allowfullscreen" value="true" />
+     <param name="wmode" value="transparent" />
+     <param name="flashvars" value="controlbar=over&amp;image=img/poster.jpg&amp;file=flash-player.swf?videoUrl=video/tears-of-steel-battle-clip-medium.mp4" />
+      <img alt="Tears of Steel poster image" src="img/poster.jpg" width="1024" height="428" title="No video playback possible, please download the video from the link below" />
+  </object>
+  <!-- Offer download -->
+  <a href="video/tears-of-steel-battle-clip-medium.mp4">Download MP4</a>
+</video>
+ +

Cette exemple (issu de Creating a cross-browser video player) n'inclut pas seulement un lecteur Flash de repli pour les anciennes versions d'IE, mais aussi un lien simple vous permettant de télécharger la vidéo si jamais le lecteur Flash ne fonctionne pas, finalement l'utilisateur peut toujours accéder à la vidéo.

+ +
+

Note : les librairies tierces comme Video.js et JW Player utilisent ce type de mécanismes de recours pour fournir un support en navigateur croisé.

+
+ +

Les éléments des formulaire HTML5 présentent également des recours de qualités — HTML5 a introduit des types d'<input> spéciaux pour insérer des informations spécifiques dans les formulaires, en particulier sur les plateformes mobiles, où fournir une insertion de données sans difficultés est primordiale pour l'expérience utilisateur. Supporter les plateformes apporte des widgets UI spéciaux lorsque ces types d'input sont utilisés, comme le widget calendrier pour entrer des dates.

+ +

L'exemple suivant montre des inputs date et time :

+ +
<form>
+  <div>
+    <label for="date">Enter a date:</label>
+    <input id="date" type="date">
+  </div>
+  <div>
+    <label for="time">Enter a time:</label>
+    <input id="time" type="time">
+  </div>
+</form>
+ +

Le résultat de ce code est le suivant :

+ + + +

{{ EmbedLiveSample('Hidden_example', '100%', 150) }}

+ +
+

Note : Vous pouvez également le voir exécuté en direct depuis forms-test.html sur GitHub (voir aussi le code source).

+
+ +

Si vous consultez l'exemple sur un navigateur qui supporte les technologies récentes comme Android Chrome ou iOS Safari, vous verrez le widget/fonctionnalité spécial en action quand vous essaierai de saisir des données. Sur des plateformes non compatibles comme Firefox ou Internet Explorer, les inputs vont juste recourir à un input texte normal, finalement l'utilisateur peut toujours entrer des informations.

+ +

Note : Bien entendu, cela n'est pas une solution viable pour les besoins de votre projet — la différence dans une présentation visuelle n'est pas désirée, de plus c'est compliqué de garantir que la donnée qui a été inscrite est dans le format que vous voulez qu'elle soit. Pour les formulaires en navigateur croisé, il est préférable de se référer aux simples éléments de formulaire, ou utiliser les éléments avancés de formulaire de manière sélective uniquement sur les navigateurs qui les supportent, ou utiliser une librairie qui fournit des widget décents en navigateur croisé, comme jQuery UI ou Bootstrap datepicker.

+ +

Comportement naturel du CSS

+ + + +

Le CSS est sans doute meilleur en solution de recours que le HTML. Si un navigateur rencontre une déclaration ou une règle qu'il ne comprend pas, il la passe complètement sans l'appliquer ou provoquer une erreur. Cela peut être frustrant pour vous et vos utilisateurs si de telles erreurs se glissent à travers le code en production, mais au moins cela veut dire que l'ensemble du site ne va pas crasher à cause d'une erreur, et si utilisé intelligemment vous pouvez vous en servir à votre avantage.

+ +

Observons un exemple — une simple boîte stylée avec du CSS, qui a certains styles apportés par différentes caractéristiques CSS3 :

+ +

+ +
+

Note : Vous pouvez également voir cet exemple exécuté en direct sur GitHub comme button-with-fallback.html (voir aussi le code source).

+
+ +

Le bouton a un nombre de déclarations qui le style, mais les deux qui nous intéressent le plus sont les suivantes :

+ +
button {
+  ...
+
+  background-color: #ff0000;
+  background-color: rgba(255,0,0,1);
+  box-shadow: inset 1px 1px 3px rgba(255,255,255,0.4),
+              inset -1px -1px 3px rgba(0,0,0,0.4);
+}
+
+button:hover {
+  background-color: rgba(255,0,0,0.5);
+}
+
+button:active {
+  box-shadow: inset 1px 1px 3px rgba(0,0,0,0.4),
+              inset -1px -1px 3px rgba(255,255,255,0.4);
+}
+ +

Ici on fournit un {{cssxref("background-color")}} RGBA qui modifie l'opacité au survol afin de donner à l'utilisateur l'information que le bouton est interactif, et une ombre {{cssxref("box-shadow")}} interne semi-transparente pour donner au bouton un peu de texture et de profondeur. Le problème est que les couleurs RGBA et les box shadows ne fonctionnent pas sur les versions d'IE plus vieilles que la 9 — dans les versions plus anciennes le background ne sera juste pas visible du tout et le texte sera illisible, pas bon du tout !

+ +

+ +

Pour résoudre ce problème, nous avons ajouté une deuxième déclaration background-color, qui précise juste une couleur hex — c'est un recours supporté par les vieux navigateurs, et agit en tant que solution de repli si les fonctionnalités belles et brillantes ne fonctionnent pas. Ce qui se passe c'est que le navigateur parcourant cette page applique pour commencer la première valeur background-color ; lorsqu'il sélectionne la deuxième déclaration background-color, il remplace la valeur initiale avec cette valeur s'il supporte les couleurs RGBA. S'il ne supporte pas, il ignorera juste toute la déclaration et continuera à avancer.

+ +
+

Note : Il se produit la même chose pour les autres caractéristiques de CSS comme les blocs media queries, @font-face et @supports — s'ils ne sont pas supportés, le navigateur va juste les ignorer.

+
+ +

Les commentaires conditionnels d'IE

+ +

Les commentaires conditionnels d'IE sont une propriété modifiée de la syntaxe des commentaires HTML, qui peuvent être utilisés pour appliquer du code HTML de manière sélective à différentes versions d'IE. Cela s'est avéré être un mécanisme très efficace pour résoudre les bugs en navigateur croisé. La syntaxe ressemble à ça :

+ +
<!--[if lte IE 8]>
+  <script src="ie-fix.js"></script>
+  <link href="ie-fix.css" rel="stylesheet" type="text/css">
+<![endif]-->
+ +

Ce block appliquera les CSS et Javascript spécifiques à IE uniquement si le navigateur qui affiche la page est IE 8 ou plus vieux. lte veux dire "moins que ou égal", mais vous pouvez aussi utiliser lt, gt, gte, ! pour NOT, et d'autre syntaxe logique.

+ +
+

Note : L'article Internet Explorer Conditional Comments de Sitepoint apporte un tutoriel/référence utile pour les débutants qui explique la syntaxe des commentaires conditionnels en détail.

+
+ +

Comme vous pouvez le voir, c'est particulièrement utile pour appliquer des fixes aux vieilles versions d'IE. Le cas d'usage que nous avons mentionné plus tôt (rendre les éléments sémantiques modernes stylables sur les vieilles versions d'IE) peut être atteint facilement en utilisant des commentaires conditionnels, par exemple vous pouvez mettre quelque chose comme ça dans votre feuille de style IE :

+ +
aside, main, article, section, nav, figure, figcaption {
+  display: block;
+}
+ +

Ce n'est cependant pas aussi simple — vous devez également créer une copie de chacun des éléments que vous voulez styler dans le DOM via Javascript, pour les rendre stylable ; c'est un peu bizarre, et nous ne vous ennuierons pas avec les détails ici. Par exemple :

+ +
var asideElem = document.createElement('aside');
+ ...
+ +

Cela paraît assez compliqué à gérer, mais heureusement il y a un {{glossary("polyfill")}} disponible qui fait les fixs nécessaires pour vous, et plus encore — voir HTML5Shiv pour tous les détails (voir manual installation pour les usages les plus simples).

+ +

Support de sélecteur

+ +

Naturellement, aucune caractéristiques CSS ne s'appliquera si vous n'utilisez pas les bons sélecteurs pour sélectionner l'élément que vous voulez styler ! Si vous écrivez juste mal un sélecteur alors le style ne sera juste pas celui attendu sur aucun navigateur, vous devez juste résoudre le problème et trouver ce qui ne va pas avec votre sélecteur. Nous trouvons utile d'inspecter l'élément que vous essayez de styler en utilisant l'outil de dev de votre navigateur, ensuite regarder l'arborescence du fil d'Ariane du DOM que les inspecteurs du DOM fournissent en général afin de voir si votre sélecteur est pertinent par rapport à ce fil d'Ariane.

+ +

Par exemple, dans l'outil de dev de Firefox, vous obtenez ce genre rendement en bas de l'inspecteur du DOM :

+ +

+ +

Si pour cet exemple vous essayez d'utiliser ce sélecteur, vous vous rendrez compte qu'il ne sélectionnera pas l'élément input comme désiré :

+ +
form > #date
+ +

(L'input date du formulaire n'est pas directement dans le <form> ; vous feriez mieux d'utiliser un sélecteur descendant général plutôt qu'un sélecteur d'enfant).

+ +

Il y a néanmoins un autre problème qui apparaît sur les versions d'IE plus anciennes que la 9 c'est qu'il n'y a aucun nouveau sélecteur (principalement les pseudo-classes et les pseudo-éléments comme :nth-of-type, :not, ::selection, etc.) qui marche. Si vous voulez les utiliser dans votre CSS et que vous devez supporter les anciennes versions d'IE, une bonne initiative et d'utiliser la librairie Selectivizr de Keith Clark — c'est une petite librairie Javascript qui s'exécute au-dessus d'une librairie Javascript existante comme  jQuery ou MooTools.

+ +
    +
  1. Afin de tester cet exemple, faites une copie locale de selectivizr-example-start.html. Si vous le regarder s'exécuter en direct, vous verrez qu'il contient deux paragraphes, dont l'un est stylé. Nous avons sélectionné le paragraphe avec p:first-child, qui ne fonctionne pas sur les anciennes versions d'IE.
  2. +
  3. Maintenant télécharger MooTools et Selectivizr, et placez-les dans le même répertoire que votre fichier HTML.
  4. +
  5. Placer le code suivant dans la têtière de votre document HTML, juste avant la balise ouvrante <style> : +
    <script type="text/javascript" src="MooTools-Core-1.6.0.js"></script>
    +    <!--[if (gte IE 6)&(lte IE 8)]>
    +      <script type="text/javascript" src="selectivizr-min.js"></script>
    +    <![endif]-->
    +
  6. +
+ +

Si vous essayer d'exécuter cette page sur une vieille version d'IE, cela devrait bien fonctionner.

+ +

+ +

Gestion des préfixes CSS

+ +

Une autre source de problèmes arrive avec les préfixes CSS — ceux sont des mécanismes utilisés à la base pour permettre au navigateur d'implémenter leur propre version d'une fonctionnalité CSS (ou Javascript) tant que la technologie est en stade expérimentale, donc ils peuvent jouer avec et la finaliser sans entrer en conflit avec les implémentations des autres navigateurs, ou la dernière implémentation non-préfixée. Voici par exemple :

+ + + +

Voici quelques exemples :

+ +
-webkit-transform: rotate(90deg);
+
+background-image: -moz-linear-gradient(left,green,yellow);
+background-image: -webkit-gradient(linear,left center,right center,from(green),to(yellow));
+background-image: linear-gradient(to right,green,yellow);
+
+ +

La première ligne déclare une propriété {{cssxref("transform")}} avec un préfixe -webkit- — c'était nécessaire pour que la transformation fonctionne sur Chrome, etc jusqu'à ce que la fonctionnalité soit finalisée et beaucoup de navigateurs ont ajouté une version de la propriété sans préfixes (au moment de la rédaction, Chrome supportait les deux versions).

+ +

Les trois dernières images montrent trois versions différentes de la fonction linear-gradient(), qui est utilisée pour générer un dégradé linéaire dans la background d'un élément :

+ +
    +
  1. La première a un préfixe -moz-, et montre une version plutôt ancienne de la syntaxe (Firefox)
  2. +
  3. La seconde a un préfixe -webkit-, et montre encore une vieille version de la syntaxe de la propriété (également issue d'une vraiment vieille version du moteur Wekkit)
  4. +
  5. La troisième n'a pas de préfixe, et montre la version finale de la syntaxe (inclue dans  CSS Image Values and Replaced Content Module Level 3 spec, qui définit cette fonctionnalité).
  6. +
+ +

Les fonctionnalités préfixées sont supposées ne jamais être utilisées dans des sites web en production — elles sont susceptibles de changer ou d'être supprimées sans avertissement, et causent des problèmes en navigateur croisé. C'est particulièrement un problème lorsque les développeurs décident de n'utiliser que la version -webkit- d'une propriété — ce qui veut dire que le site ne fonctionnera pas sur d'autres navigateurs. En fait, cela arrive tellement souvent que d'autres navigateurs ont commencé à implémenter les versions préfixées -webkit- de plusieurs propriétés CSS, ils marcheront donc avec un tel code. L'utilisation des préfixes fournit par chaque navigateur a récemment déclinée précisément à cause de ce type de problèmes, mais il en reste encore certain qui demandent de l'attention.

+ +

Si vous persistez a utiliser des fonctionnalités préfixées, assurez-vous d'utiliser les bonnes. Vous pouvez vérifier quels navigateurs ont besoin de préfixes sur les pages de référence MDN, et des sites comme caniuse.com. Si vous doutez, vous pouvez aussi vérifier en faisant des tests directement sur les navigateurs.

+ +

Essayez cet exemple simple :

+ +
    +
  1. Ouvrez google.com, ou un autre site qui a un en-tête proéminent ou un niveau de bloc d'élément.
  2. +
  3. Clic droit sur l'élément en question et choisir Inspecter/Inspecter l'élément (ou qu'importe l'option de votre navigateur) — cela devrait ouvrir les outils de dev dans votre navigateur, avec l'élément mis en valeur dans l'inspecteur du DOM.
  4. +
  5. Chercher une fonctionnalité que vous pouvez utiliser pour sélectionner cet élément. Par exemple, au moment de la rédaction, le logo principal de Google a un ID hplogo.
  6. +
  7. Entreposer une référence à cet élément dans une variable, par exemple : +
    var test = document.getElementById('hplogo');
    +
  8. +
  9. Maintenant essayez d'appliquer une nouvelle valeur pour la propriété CSS qui vous intéresse sur cet élément ; vous pouvez le faire en utilisant la propriété style de l'élément, par exemple essayez de taper ça dans votre console Javascript :
  10. +
  11. +
    test.style.transform = 'rotate(90deg)'
    +test.style.webkitTransform = 'rotate(90deg)'
    +
  12. +
+ +

Quand vous commencez à taper la transcription du nom de la propriété après le deuxième point (notez qu'en Javascript, les noms des propriétés CSS sont écrites en lower camel case, sans trait d'union), la console Javascript devrait commencer à saisir automatiquement les noms des propriétés qui existent dans le navigateur et qui correspondent au mieux avec ce que vous écrivez. C'est utile pour trouver quelles versions de la propriété est implémentée dans ce navigateur.

+ +

A l'heure où ces lignes sont écrites, Firefox et Chrome ont implémenté tous les deux les versions préfixées -webkit- et non préfixées de {{cssxref("transform")}} !

+ +

Une fois que vous avez trouvé quels préfixes vous avez besoin de supporter, vous devriez tous les inscrire dans votre CSS, par exemple :

+ +
-ms-transform: rotate(90deg);
+-webkit-transform: rotate(90deg);
+transform: rotate(90deg);
+ +

Cela vous assurera que tous les navigateurs qui supportent n'importe laquelle des formes de la propriété ci-dessus pourront faire marcher la fonctionnalité. Il convient de placer la version non préfixée en dernier, parce qu'elle sera la version la plus récente, que vous voulez que les navigateurs utilisent si c'est possible. Si par exemple un navigateur implémente la version -webkit- et la version non préfixée, il va en premier temps appliquer la version -webkit-, puis la remplacer par la version non préfixée. Vous voulez que cela se produise dans ce sens, et non dans l'autre.

+ +

Bien entendu, appliquer cela à de nombreuses différentes règles CSS peut devenir très fastidieux. Il est préférable d'utiliser des outils d'automatisation qui le font pour vous. Et de tels outils existent :

+ +

La prefix-free JavaScript library peut être jointe à une page, et détectera automatiquement quels sont les aptitudes détenues par navigateurs en analysant la page et en ajoutant les préfixes appropriés. C'est très facile et pratique à utiliser, bien qu'il ait quelques inconvénients (voir le lien au-dessus pour plus de détails), et on peut discuter du fait qu'analyser chaque feuille de style de votre site et ajouter des préfixes lors de l'exécution peut être un fardeau pour la puissance de traitement de l'ordinateur pour un grand site.

+ +

Une autre solution est d'ajouter automatiquement les préfixes pendant le développement, et cela (et d'autres choses à venir) peut être fait en utilisant des outils comme Autoprefixer et PostCSS. Ces outils peuvent être utilisés de diverses manières, par exemple Autoprefixer a une version en ligne qui vous permet d'entrer votre CSS non préfixé sur la gauche, et vous donne une version avec préfixes ajoutés sur la droite. Vous pouvez sélectionner quels navigateurs vous voulez afin de vous assurer de bien supporter en utilisant la notation définie dans Autoprefixer options ; pour plus de détails, voir aussi Browserslist queries, qui est basé dessus. Comme exemple, la requête suivante sélectionnera les deux dernières versions de tous le navigateurs principaux et les versions d'IE  supérieure à la 9.

+ +
last 2 versions, ie > 9
+ + + +

Autoprefixer peut aussi être utilisé dans d'autres cas, plus pratiques — voir Autoprefixer usage. Par exemple vous pouvez l'utiliser avec un exécuteur de tâche/outil de build comme Gulp ou Webpack pour ajouter automatiquement les préfixes une fois que le développement a été fait. (Expliquer comment cela fonctionne est plutôt au-delà de la portée de cet article).

+ +

Vous pouvez également utiliser un plugin pour éditeur de texte comme Atom ou Sublime text. Par exemple, dans Atom :

+ +
    +
  1. Vous pouvez l'installer en allant dans Préférences > Installer, chercher Autoprefixer, puis cliquer sur installer.
  2. +
  3. Vous pouvez configurer une requête navigateur en appuyant sur le bouton Settings d'Autoprefixer et entrer la requête dans le champs texte de la section Setting de la page.
  4. +
  5. Dans votre code, vous pouvez sélectionner des sections de CSS auxquelles vous voulez ajouter des préfixes, ouvrez la palette de commande (Cmd/Ctrl + Shift + P), puis tapez Autoprefixer dedans et sélectionnez le résultat Autoprefixer qui auto complète.
  6. +
+ +

En tant qu'exemple, nous avons entré le code suivant :

+ +
body {
+  display: flex;
+}
+ +

Nous l'avons sélectionné et exécuté la commande Autoprefixer, et il l'a remplacé par ça :

+ +
body {
+  display: -webkit-box;
+  display: -ms-flexbox;
+  display: flex;
+}
+ +

Les problèmes de mise en page

+ +

Un autre problème qui peut survenir est la différence de mise en page entre les navigateurs. Historiquement c'était traité comme bien plus qu'un problème, mais ces derniers temps, avec les navigateurs modernes qui ont tendance à supporter le CSS plus systématiquement, les problèmes de mise en page ont plus tendance à être couramment associés avec :

+ + + +
+

Note : Historiquement les développeurs web étaient habitués à utiliser des fichiers CSS appelés resets, qui supprimaient tous les styles par défaut des navigateurs qui s'appliquaient au HTML, et ensuite appliquaient leurs propres styles pour tout le reste — c'était fait pour rendre le style sur un projet plus cohérent, et réduire les possibles problèmes en navigateur croisé, spécialement pour les choses issues de la mise en page. Toutefois, cela a récemment été défini comme exagéré. Le meilleur équivalent que nous avons de nos jours c'est le normalize.css, un peu de CSS propre qui style discrètement par-dessus le style par défaut des navigateurs afin de rendre les éléments plus cohérents et fixe quelques problèmes de disposition. Nous vous recommandons d'appliquer normalize.css sur toutes vos pages HTML.

+
+ +
+

Note :  Lorsque vous essayer de localiser un problème de disposition difficile, une bonne technique et d'ajouter une couleur éclatante {{cssxref("outline")}} sur l'élément dérangeant, ou sur tous les éléments à côté. Cela facilite la tâche pour voir où tous les éléments sont placés. Voir Debug your CSS with outline visualizations pour plus de détails...

+
+ +

Support pour les nouvelles caractéristiques de disposition

+ +

La plupart du travail de mise en page sur le web aujourd'hui et réalisé en utilisant les floats — c'est parce que les floats sont bien supportés (depuis IE 4, bien qu'il y ait un certain nombre de bugs qui auront besoin d'être examinés si vous essayez de supporter IE aussi loin). Il n'y a néanmoins pas de véritables explications sur la mise en page — utiliser les floats comme nous les utilisons est un vrai hack — et ils ont de sérieuses limites (par ex. voir Why Flexbox?)

+ +

Plus récemment, des mécanismes dédiés à la disposition ont fait leur apparition, comme Flexbox et CSS Grids, qui rendent les tâches ordinaires de disposition bien plus simples et enlèvent les défauts. Ils ne sont cependant pas bien supportés dans les navigateurs :

+ + + +

Les fonctionnalités de disposition ne sont pas aussi simples pour fournir des solutions de repli que de simples couleurs, ombres ou dégradés. Si les propriétés de disposition sont ignorées, la totalité de votre design sera réduit en pièces. De ce fait, vous devez utiliser une fonctionnalité de détection pour détecter si les navigateurs qui consultent votre site supportent ces caractéristiques de disposition, et appliquer différentes dispositions de manière sélective selon le résultat (nous couvrirons les fonctionnalités de détection dans un article à venir).

+ +

Par exemple, vous pourriez appliquer une disposition flexbox sur les navigateurs modernes, et aussi appliquer une disposition en float pour les plus vieux navigateurs qui ne supportent pas flexbox.

+ +
+

Note : Il y a une fonctionnalité assez récente en CSS appelé @supports, qui vous permet d'implémenter des tests de détection de fonctionnalités natives.

+
+ +

Les problèmes de responsive design

+ +

Le design responsive est la pratique de créer des dispositions web qui s'adaptent en fonction des facteurs de formes de l'appareil — par exemple différentes tailles d'écran, l'orientation (portait ou paysage), ou la résolution. Une disposition pour ordinateur de bureau par exemple paraîtra atroce lorsqu'elle sera affichée sur un appareil mobile, vous allez donc devoir fournir une disposition appropriée aux mobiles en utilisant les media queries, et assurez-vous qu'il est appliqué correctement en utilisant viewport. Vous pouvez trouver un bilan précis de telles pratiques dans The building blocks of responsive design.

+ +

La résolution est également très préoccupante — par exemple, les appareils mobiles sont moins susceptibles d'avoir besoin de grosses images lourdes que des ordinateurs de bureau, et ont davantage tendance à avoir des connexions internet plus lentes et sans doute un échange de données coûteux qui gaspille la bande passante qui est un problème supplémentaire. De plus, certains appareils peuvent avoir une gamme de plusieurs résolutions, ce qui veut dire que des petites images peuvent s'afficher pixelisées. Il y a un nombre de techniques qui vous permette de travailler autour de tels problèmes, des simples mobile first media queries, aux plus complexes responsive image techniques.

+ +

Une autre difficulté qui peut présenter des problèmes c'est le support des fonctionnalités par les navigateurs qui rendent les techniques suscitées possibles. Les media queries ne sont pas supportés sur IE 8 ou plus vieux, donc si vous voulez utiliser une disposition mobile en premier lieu puis une disposition pour ordinateur de bureau qui applique aux vieilles versions d'IE, vous devrez appliquer un media querie {{glossary("polyfill")}} à votre page, comme css3-mediaqueries-js ou Respond.js.

+ +

Trouver de l'aide

+ +

Il y bien d'autres problèmes que vous allez rencontrer avec le HTML et le CSS ; la chose la plus important à vraiment savoir est de comment trouver des solutions en ligne.

+ +

Parmi les meilleures sources d'information de support il y a Mozilla Developer Network (c'est où vous vous trouvez actuellement !), stackoverflow.com et caniuse.com.

+ +

Pour utiliser le Mozilla Developer Network (MDN), la plupart des gens font une recherche de la technologie sur laquelle ils essayent de trouver des informations, et ajoutent le terme "mdn", par exemple "mdn HTML5 video". MDN contient plusieurs types de contenus utiles :

+ + + +

caniuse.com fournit des informations de support, tout au long avec des ressources externes. Par exemple, voir http://caniuse.com/#search=video (vous avez juste à entrer la fonctionnalité que vous recherchez dans la boîte de recherche)

+ +

stackoverflow.com (SO) est un forum en ligne où vous pouvez poser des questions et avez un ensemble de développeurs partageant leurs solutions, observez les commentaires passés, et aidez les autres développeurs. Nous vous conseillons de chercher et de regarder s'il existe déjà une réponse à votre question, avant de poster une nouvelle question. Par exemple, nous avons cherché pour "cross browser html5 video" sur SO, et très rapidement la solution HTML5 Video with full cross browser compatibility est remontée.

+ +

Par ailleurs, essayez de chercher votre moteur de recherche favori pour trouver une réponse à vos problèmes. C'est souvent utile de chercher les messages d'erreur spécifiques si vous en avez — d'autres développeurs seront susceptibles d'avoir les mêmes problèmes que vous

+ +

Résumé

+ +

Vous devriez maintenant être familier avec les problèmes principaux en navigateur croisé avec HTML et CSS que vous rencontrerez en développement web, et comment faire pour les résoudre.

+ +

{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/Testing_strategies","Learn/Tools_and_testing/Cross_browser_testing/JavaScript", "Learn/Tools_and_testing/Cross_browser_testing")}}

+ + + +

Dans ce module

+ + diff --git a/files/fr/learn/tools_and_testing/cross_browser_testing/html_et_css/index.html b/files/fr/learn/tools_and_testing/cross_browser_testing/html_et_css/index.html deleted file mode 100644 index 7b2a01fc95..0000000000 --- a/files/fr/learn/tools_and_testing/cross_browser_testing/html_et_css/index.html +++ /dev/null @@ -1,509 +0,0 @@ ---- -title: Gérer les problèmes courants en HTML et CSS -slug: Learn/Tools_and_testing/Cross_browser_testing/HTML_et_CSS -tags: - - Apprentissage - - CSS - - Débutant - - HTML - - Sélecteurs - - linting - - navigateur croisé - - test -translation_of: Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS ---- -
{{LearnSidebar}}
- -
{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/Testing_strategies","Learn/Tools_and_testing/Cross_browser_testing/JavaScript", "Learn/Tools_and_testing/Cross_browser_testing")}}
- -

Maintenant que les bases sont posées, nous allons nous concentrer sur les problèmes courants en navigateur croisé que vous allez rencontrer en code HTML et CSS, et quels outils peuvent être utilisés pour prévenir l'arrivée de ces problèmes, ou résoudre les problèmes qui surviennent. Cela inclut le linting code, la gestion des préfixes CSS, l'utilisation des outils de dev des navigateurs pour localiser les problèmes, utiliser des polyfills pour apporter du support dans les navigateurs, se confronter aux problèmes de responsive design et plus encore.

- - - - - - - - - - - - -
Prérequis : -

Connaissances avec le noyau des langages HTML, CSS, et JavaScript ; une idée du haut niveau des principes du test en navigateur croisé.

-
Objectif : -

Etre capable de diagnostiquer des problèmes courants de CSS et de HTML en navigateur croisé, et utiliser les techniques et outils appropriés pour les réparer.

-
- -

Les difficultés avec HTML et CSS

- -

Certains des problèmes avec le HTML et le CSS viennent du fait qu'ils sont tous les deux des langages qui sont assez simples, et souvent les développeurs ne les considèrent pas sérieusement, en termes de s'assurer que le code est bien conçu, efficace, et qu'il décrit sémantiquement les but de la fonctionnalité sur la page. Dans les pires des cas, Javascript est utilisé pour générer tout le contenu et le style d'une page web, ce qui rend vos pages inaccessibles, et moins performantes (générer des éléments de DOM est coûteux). Dans d'autres cas, des fonctionnalités naissantes ne sont pas supportées constamment par tous les navigateurs, ce qui peut empêcher certaines fonctionnalités et styles de fonctionner pour certains utilisateurs. Les problèmes de responsive design sont également courant — un site qui paraît bien sur le navigateur d'un ordinateur de bureau pourra fournir une expérience horrible sur un appareil mobile, à cause du contenu qui est trop petit pour être lu, ou peut-être que le site sera lent à cause de animations coûteuses.

- -

Commençons et regardons comment nous pouvons réduire les erreurs en navigateur croisé issues du HTML/CSS.

- -

Commençons par le commencement : résoudre les problèmes généraux

- -

Nous disions dans le premier article de cette série que c'était une bonne stratégie de commencer à tester sur une paire de navigateurs modernes sur desktop/mobile, afin de vous assurer que votre site fonctionne pour l'essentiel, avant de commencer à se concentrer sur les problèmes en navigateur croisé.

- -

Dans nos articles Debugging HTML et Debugging CSS, nous avancions quelques conseils très basiques sur le débogage HTML/CSS — si vous ne maîtrisez pas ces bases, vous devriez sans aucun doute aller étudier ces articles avant de continuer.

- -

Il s'agit essentiellement de vérifier si votre code HTML et CSS est bien conçu et s'il ne contient aucune erreur de syntaxe.

- -
-

Note : Un problème fréquent avec le HTML et le CSS arrive quand différentes règles CSS commencent à entrer en conflit avec une autre. Cela peut être particulièrement problématique lorsque vous utilisez un bout de code tierce. Par exemple, vous pouvez utiliser un modèle CSS et remarquer qu'un des noms de classe qui est utilisé entre en conflit avec un que vous utilisez déjà dans un but différent. Ou vous pouvez trouver que du HTML généré par une API tierce (générateur de bannières publicitaires, par exemple) inclut un nom de classe ou d'ID que vous utilisez déjà dans un but différent. Afin de garantir que cela ne se produira pas, vous devez rechercher les outils que vous allez utiliser en premier et construire votre code en conséquence. Il convient également de relever les "espace de noms" en CSS, par ex. si vous avez un widget, assurez-vous qu'il a des classes distinctes, et ensuite commencez les sélecteurs qui sélectionnent les éléments à l'intérieur du widget avec cette classe, les conflits risqueront moins d'arriver. Par exemple .audio-player ul a.

-
- -

La validation

- -

Pour le HTML, la validation implique de s'assurer que toutes vos balises sont correctement fermées et imbriquées, que vous utilisez un DOCTYPE, et que vous utilisez les balises à leur fin prévue. Une bonne stratégie est de valider régulièrement votre code. On service qui peut le faire est le W3C Markup Validation Service, qui vous permet de montrer votre code, et retourne une liste d'erreurs :

- -

The HTML validator homepage

- -

Le CSS a une histoire semblable — vous devez vérifier que vos noms de propriétés sont correctement épelés, ques les valeurs des propriétés sont correctement épelées et qu'elles sont valides pour les propriétés auxquelles elles s'appliquent, que vous n'oubliez aucune accolades ouvrantes et fermantes. Les W3C a un CSS Validator également disponible à cet effet.

- -

Les linters

- -

Une autre bonne option à envisager est ce qu'on appelle les applications Linter, qui ne font pas que souligner les erreurs, mais peuvent aussi mettre en évidence des avertissements à propos des mauvaises pratiques dans votre CSS, et encore d'autres points. Les linters peuvent pour la plupart être configurés pour être plus strictes ou plus coulants dans leur rapport d'erreur/avertissement.

- -

Il y a beaucoup d'applications linter en ligne, les meilleures d'entre elles sont probablement Dirty Markup (HTML, CSS, JavaScript), et CSS Lint (seulement CSS). Elles vous permettent de coller votre code dans une fenêtre, et mettront en évidence toutes les erreurs avec des croix, qui peuvent être survolées pour obtenir un message d'erreur décrivant le problème. Dirty Markup vous permet également de faire des fixs dans votre code en utilisant le bouton Clean.

- -

- -

Néanmoins, ce n'est pas très pratique de devoir copier et coller votre code dans une page web pour vérifier sa validité plusieurs fois. Ce dont vous avez vraiment besoin c'est d'un linter qui s'installera dans votre espace de travail standard avec le minimum de prise de tête.

- - - -

La plupart des éditeurs de code ont leur plugins linter. Par exemple, l'éditeur de code Atom de Github possède un riche écosystème de plugins disponibles, avec beaucoup d'options de linting. Voici un exemple pour vous montrer comment un plugin marche généralement :

- -
    -
  1. Installer Atom (si vous n'avez pas déjà une version à jour installée) — télécharger-le depuis la page Atom indiquée plus haut.
  2. -
  3. Aller dans la boîte de dialogue Préférences... d'Atom (par ex. en sélectionnant Atom > Préférences... sur Mac, ou Fichier > Préférences... sur Windows/Linux) et choisissez l'option Installer dans le menu gauche.
  4. -
  5. Dans le champs texte Rechercher des packages, taper "lint" et presser Entrer/Envoyer pour rechercher des packages liés au linting.
  6. -
  7. Vous devriez voir un package appelé lint dans le haut de la liste. Installez celui-ci en premier (en utilisant le bouton Installer), comme les autres linters lui font appel pour fonctionner. Ensuite, installer le plugin linter-csslint pour le linting CSS, et le plugin linter-tidy pour le linting HTML.
  8. -
  9. Une fois que les packages ont fini de s'installer, essayer de charger un fichier HTML et un fichier CSS : vous verrez plusieurs zones soulignées en vert (pour les avertissements) et des cercles rouges (pour les erreurs) à côté des numéros de ligne, et un panneau séparé en bas qui affiche les numéros de ligne, les messages d'erreur, et parfois qui vous suggère des valeur par défaut ou d'autres solutions.
  10. -
- - - -

- -

D'autres éditeurs populaires ont des packages de linting similaires. Voir, par exemple :

- - - -

Les outils de développement des navigateurs

- -

Les outils de développement inclus dans la plupart des navigateurs fournissent également des outils pour traquer les erreurs, en particulier pour le CSS.

- -
-

Note : Les erreurs HTML n'ont pas tendance à se montrer facilement avec les outils de dev, étant donné que le navigateur va essayer de corriger en fermant automatiquement mal les balises ; le validateur W3C est la meilleure façon d'obtenir des erreurs HTML — voir {{anch("Validation")}} plus haut.

-
- -

As an example, in Firefox the CSS inspector will show CSS declarations that aren't applied crossed out, with a warning triangle. Hovering the warning triangle will provide a descriptive error message:

- -

- -

Les outils de dev des autres navigateurs ont des fonctionnalités semblables.

- -

Problèmes fréquents en navigateur croisé

- -

Attaquons-nous maintenant à certains des problèmes HTML et CSS les plus courants en navigateur croisé. Les sujets principaux que nous allons aborder sont l'absence de support pour les fonctionnalités modernes, et les problèmes de mise en page.

- -

Les vieux navigateurs ne supportant pas les fonctionnalités récentes

- -

C'est un problème courant, particulièrement lorsque vous devez supporter de vieux navigateurs (comme les anciennes versions d'IE) ou que vous utilisez des fonctionnalités qui sont implémentées en utilisant des préfixes CSS. En général, les fonctionnalités principales du HTML et du CSS (comme les éléments HTML basiques, les couleurs et styles de texte principaux de CSS) marchent sur la plupart des navigateurs que vous voulez supporter ; la majorité des problèmes sont découverts lorsque que vous commencez à vouloir utiliser des nouveautés comme Flexbox, ou HTML5 video/audio, ou encore plus récent, CSS Grids ou -webkit-background-clip: text.

- -

Une fois que vous avez identifié une liste des potentielles technologies à problèmes que vous allez utiliser, c'est une bonne initiative des rechercher sur quels navigateurs elles sont supportées, et quelles techniques associées sont utiles. Voir {{anch("Finding help")}} plus bas.

- -

Comportement naturel du HTML

- -

Certains problèmes peuvent être résolus, seulement en tirant parti des réactions naturelles du HTML/CSS.

- -

Les éléments HTML non reconnus sont traités par les navigateurs comme des éléments inline anonymes (véritablement des éléments inline avec aucune valeur sémantiques, similaires aux éléments {{htmlelement("span")}} ). Vous pouvez toujours vous référez à eux avec leurs noms, et les styler avec du CSS, par exemple — vous avez juste besoin de vous assurer qu'ils se comportent comme vous le voulez, par exemple configurer display: block; sur tous les nouveaux éléments sémantiques (comme {{htmlelement("article")}}, {{htmlelement("aside")}}, etc.), mais seulement sur les vieilles versions d'IE qui ne les reconnaissent pas (donc, IE 8 et plus faible). De cette façon les nouveaux navigateurs peuvent juste utiliser le code normalement, mais les anciennes versions d'IE seront également capables de styler ces éléments.

- -
-

Note : Voir {{anch("IE conditional comments")}} pour une application efficace.

-
- - - -

Des éléments HTML plus complexes comme <video>, <audio>, et <canvas> (et encore d'autres) ont des mécanismes naturels pour que les recours soient ajoutés, qui se basent sur le même principe décrit plus haut. Vous pouvez ajouter un contenu de repli entre la balise ouvrante et fermante, et les navigateurs ne supportant pas la feature vont effectivement ignorer les éléments extérieurs et exécuter le contenu imbriqué.

- -

Par exemple :

- -
<video id="video" controls preload="metadata" poster="img/poster.jpg">
-  <source src="video/tears-of-steel-battle-clip-medium.mp4" type="video/mp4">
-  <source src="video/tears-of-steel-battle-clip-medium.webm" type="video/webm">
-  <source src="video/tears-of-steel-battle-clip-medium.ogg" type="video/ogg">
-  <!-- Flash fallback -->
-  <object type="application/x-shockwave-flash" data="flash-player.swf?videoUrl=video/tears-of-steel-battle-clip-medium.mp4" width="1024" height="576">
-     <param name="movie" value="flash-player.swf?videoUrl=video/tears-of-steel-battle-clip-medium.mp4" />
-     <param name="allowfullscreen" value="true" />
-     <param name="wmode" value="transparent" />
-     <param name="flashvars" value="controlbar=over&amp;image=img/poster.jpg&amp;file=flash-player.swf?videoUrl=video/tears-of-steel-battle-clip-medium.mp4" />
-      <img alt="Tears of Steel poster image" src="img/poster.jpg" width="1024" height="428" title="No video playback possible, please download the video from the link below" />
-  </object>
-  <!-- Offer download -->
-  <a href="video/tears-of-steel-battle-clip-medium.mp4">Download MP4</a>
-</video>
- -

Cette exemple (issu de Creating a cross-browser video player) n'inclut pas seulement un lecteur Flash de repli pour les anciennes versions d'IE, mais aussi un lien simple vous permettant de télécharger la vidéo si jamais le lecteur Flash ne fonctionne pas, finalement l'utilisateur peut toujours accéder à la vidéo.

- -
-

Note : les librairies tierces comme Video.js et JW Player utilisent ce type de mécanismes de recours pour fournir un support en navigateur croisé.

-
- -

Les éléments des formulaire HTML5 présentent également des recours de qualités — HTML5 a introduit des types d'<input> spéciaux pour insérer des informations spécifiques dans les formulaires, en particulier sur les plateformes mobiles, où fournir une insertion de données sans difficultés est primordiale pour l'expérience utilisateur. Supporter les plateformes apporte des widgets UI spéciaux lorsque ces types d'input sont utilisés, comme le widget calendrier pour entrer des dates.

- -

L'exemple suivant montre des inputs date et time :

- -
<form>
-  <div>
-    <label for="date">Enter a date:</label>
-    <input id="date" type="date">
-  </div>
-  <div>
-    <label for="time">Enter a time:</label>
-    <input id="time" type="time">
-  </div>
-</form>
- -

Le résultat de ce code est le suivant :

- - - -

{{ EmbedLiveSample('Hidden_example', '100%', 150) }}

- -
-

Note : Vous pouvez également le voir exécuté en direct depuis forms-test.html sur GitHub (voir aussi le code source).

-
- -

Si vous consultez l'exemple sur un navigateur qui supporte les technologies récentes comme Android Chrome ou iOS Safari, vous verrez le widget/fonctionnalité spécial en action quand vous essaierai de saisir des données. Sur des plateformes non compatibles comme Firefox ou Internet Explorer, les inputs vont juste recourir à un input texte normal, finalement l'utilisateur peut toujours entrer des informations.

- -

Note : Bien entendu, cela n'est pas une solution viable pour les besoins de votre projet — la différence dans une présentation visuelle n'est pas désirée, de plus c'est compliqué de garantir que la donnée qui a été inscrite est dans le format que vous voulez qu'elle soit. Pour les formulaires en navigateur croisé, il est préférable de se référer aux simples éléments de formulaire, ou utiliser les éléments avancés de formulaire de manière sélective uniquement sur les navigateurs qui les supportent, ou utiliser une librairie qui fournit des widget décents en navigateur croisé, comme jQuery UI ou Bootstrap datepicker.

- -

Comportement naturel du CSS

- - - -

Le CSS est sans doute meilleur en solution de recours que le HTML. Si un navigateur rencontre une déclaration ou une règle qu'il ne comprend pas, il la passe complètement sans l'appliquer ou provoquer une erreur. Cela peut être frustrant pour vous et vos utilisateurs si de telles erreurs se glissent à travers le code en production, mais au moins cela veut dire que l'ensemble du site ne va pas crasher à cause d'une erreur, et si utilisé intelligemment vous pouvez vous en servir à votre avantage.

- -

Observons un exemple — une simple boîte stylée avec du CSS, qui a certains styles apportés par différentes caractéristiques CSS3 :

- -

- -
-

Note : Vous pouvez également voir cet exemple exécuté en direct sur GitHub comme button-with-fallback.html (voir aussi le code source).

-
- -

Le bouton a un nombre de déclarations qui le style, mais les deux qui nous intéressent le plus sont les suivantes :

- -
button {
-  ...
-
-  background-color: #ff0000;
-  background-color: rgba(255,0,0,1);
-  box-shadow: inset 1px 1px 3px rgba(255,255,255,0.4),
-              inset -1px -1px 3px rgba(0,0,0,0.4);
-}
-
-button:hover {
-  background-color: rgba(255,0,0,0.5);
-}
-
-button:active {
-  box-shadow: inset 1px 1px 3px rgba(0,0,0,0.4),
-              inset -1px -1px 3px rgba(255,255,255,0.4);
-}
- -

Ici on fournit un {{cssxref("background-color")}} RGBA qui modifie l'opacité au survol afin de donner à l'utilisateur l'information que le bouton est interactif, et une ombre {{cssxref("box-shadow")}} interne semi-transparente pour donner au bouton un peu de texture et de profondeur. Le problème est que les couleurs RGBA et les box shadows ne fonctionnent pas sur les versions d'IE plus vieilles que la 9 — dans les versions plus anciennes le background ne sera juste pas visible du tout et le texte sera illisible, pas bon du tout !

- -

- -

Pour résoudre ce problème, nous avons ajouté une deuxième déclaration background-color, qui précise juste une couleur hex — c'est un recours supporté par les vieux navigateurs, et agit en tant que solution de repli si les fonctionnalités belles et brillantes ne fonctionnent pas. Ce qui se passe c'est que le navigateur parcourant cette page applique pour commencer la première valeur background-color ; lorsqu'il sélectionne la deuxième déclaration background-color, il remplace la valeur initiale avec cette valeur s'il supporte les couleurs RGBA. S'il ne supporte pas, il ignorera juste toute la déclaration et continuera à avancer.

- -
-

Note : Il se produit la même chose pour les autres caractéristiques de CSS comme les blocs media queries, @font-face et @supports — s'ils ne sont pas supportés, le navigateur va juste les ignorer.

-
- -

Les commentaires conditionnels d'IE

- -

Les commentaires conditionnels d'IE sont une propriété modifiée de la syntaxe des commentaires HTML, qui peuvent être utilisés pour appliquer du code HTML de manière sélective à différentes versions d'IE. Cela s'est avéré être un mécanisme très efficace pour résoudre les bugs en navigateur croisé. La syntaxe ressemble à ça :

- -
<!--[if lte IE 8]>
-  <script src="ie-fix.js"></script>
-  <link href="ie-fix.css" rel="stylesheet" type="text/css">
-<![endif]-->
- -

Ce block appliquera les CSS et Javascript spécifiques à IE uniquement si le navigateur qui affiche la page est IE 8 ou plus vieux. lte veux dire "moins que ou égal", mais vous pouvez aussi utiliser lt, gt, gte, ! pour NOT, et d'autre syntaxe logique.

- -
-

Note : L'article Internet Explorer Conditional Comments de Sitepoint apporte un tutoriel/référence utile pour les débutants qui explique la syntaxe des commentaires conditionnels en détail.

-
- -

Comme vous pouvez le voir, c'est particulièrement utile pour appliquer des fixes aux vieilles versions d'IE. Le cas d'usage que nous avons mentionné plus tôt (rendre les éléments sémantiques modernes stylables sur les vieilles versions d'IE) peut être atteint facilement en utilisant des commentaires conditionnels, par exemple vous pouvez mettre quelque chose comme ça dans votre feuille de style IE :

- -
aside, main, article, section, nav, figure, figcaption {
-  display: block;
-}
- -

Ce n'est cependant pas aussi simple — vous devez également créer une copie de chacun des éléments que vous voulez styler dans le DOM via Javascript, pour les rendre stylable ; c'est un peu bizarre, et nous ne vous ennuierons pas avec les détails ici. Par exemple :

- -
var asideElem = document.createElement('aside');
- ...
- -

Cela paraît assez compliqué à gérer, mais heureusement il y a un {{glossary("polyfill")}} disponible qui fait les fixs nécessaires pour vous, et plus encore — voir HTML5Shiv pour tous les détails (voir manual installation pour les usages les plus simples).

- -

Support de sélecteur

- -

Naturellement, aucune caractéristiques CSS ne s'appliquera si vous n'utilisez pas les bons sélecteurs pour sélectionner l'élément que vous voulez styler ! Si vous écrivez juste mal un sélecteur alors le style ne sera juste pas celui attendu sur aucun navigateur, vous devez juste résoudre le problème et trouver ce qui ne va pas avec votre sélecteur. Nous trouvons utile d'inspecter l'élément que vous essayez de styler en utilisant l'outil de dev de votre navigateur, ensuite regarder l'arborescence du fil d'Ariane du DOM que les inspecteurs du DOM fournissent en général afin de voir si votre sélecteur est pertinent par rapport à ce fil d'Ariane.

- -

Par exemple, dans l'outil de dev de Firefox, vous obtenez ce genre rendement en bas de l'inspecteur du DOM :

- -

- -

Si pour cet exemple vous essayez d'utiliser ce sélecteur, vous vous rendrez compte qu'il ne sélectionnera pas l'élément input comme désiré :

- -
form > #date
- -

(L'input date du formulaire n'est pas directement dans le <form> ; vous feriez mieux d'utiliser un sélecteur descendant général plutôt qu'un sélecteur d'enfant).

- -

Il y a néanmoins un autre problème qui apparaît sur les versions d'IE plus anciennes que la 9 c'est qu'il n'y a aucun nouveau sélecteur (principalement les pseudo-classes et les pseudo-éléments comme :nth-of-type, :not, ::selection, etc.) qui marche. Si vous voulez les utiliser dans votre CSS et que vous devez supporter les anciennes versions d'IE, une bonne initiative et d'utiliser la librairie Selectivizr de Keith Clark — c'est une petite librairie Javascript qui s'exécute au-dessus d'une librairie Javascript existante comme  jQuery ou MooTools.

- -
    -
  1. Afin de tester cet exemple, faites une copie locale de selectivizr-example-start.html. Si vous le regarder s'exécuter en direct, vous verrez qu'il contient deux paragraphes, dont l'un est stylé. Nous avons sélectionné le paragraphe avec p:first-child, qui ne fonctionne pas sur les anciennes versions d'IE.
  2. -
  3. Maintenant télécharger MooTools et Selectivizr, et placez-les dans le même répertoire que votre fichier HTML.
  4. -
  5. Placer le code suivant dans la têtière de votre document HTML, juste avant la balise ouvrante <style> : -
    <script type="text/javascript" src="MooTools-Core-1.6.0.js"></script>
    -    <!--[if (gte IE 6)&(lte IE 8)]>
    -      <script type="text/javascript" src="selectivizr-min.js"></script>
    -    <![endif]-->
    -
  6. -
- -

Si vous essayer d'exécuter cette page sur une vieille version d'IE, cela devrait bien fonctionner.

- -

- -

Gestion des préfixes CSS

- -

Une autre source de problèmes arrive avec les préfixes CSS — ceux sont des mécanismes utilisés à la base pour permettre au navigateur d'implémenter leur propre version d'une fonctionnalité CSS (ou Javascript) tant que la technologie est en stade expérimentale, donc ils peuvent jouer avec et la finaliser sans entrer en conflit avec les implémentations des autres navigateurs, ou la dernière implémentation non-préfixée. Voici par exemple :

- - - -

Voici quelques exemples :

- -
-webkit-transform: rotate(90deg);
-
-background-image: -moz-linear-gradient(left,green,yellow);
-background-image: -webkit-gradient(linear,left center,right center,from(green),to(yellow));
-background-image: linear-gradient(to right,green,yellow);
-
- -

La première ligne déclare une propriété {{cssxref("transform")}} avec un préfixe -webkit- — c'était nécessaire pour que la transformation fonctionne sur Chrome, etc jusqu'à ce que la fonctionnalité soit finalisée et beaucoup de navigateurs ont ajouté une version de la propriété sans préfixes (au moment de la rédaction, Chrome supportait les deux versions).

- -

Les trois dernières images montrent trois versions différentes de la fonction linear-gradient(), qui est utilisée pour générer un dégradé linéaire dans la background d'un élément :

- -
    -
  1. La première a un préfixe -moz-, et montre une version plutôt ancienne de la syntaxe (Firefox)
  2. -
  3. La seconde a un préfixe -webkit-, et montre encore une vieille version de la syntaxe de la propriété (également issue d'une vraiment vieille version du moteur Wekkit)
  4. -
  5. La troisième n'a pas de préfixe, et montre la version finale de la syntaxe (inclue dans  CSS Image Values and Replaced Content Module Level 3 spec, qui définit cette fonctionnalité).
  6. -
- -

Les fonctionnalités préfixées sont supposées ne jamais être utilisées dans des sites web en production — elles sont susceptibles de changer ou d'être supprimées sans avertissement, et causent des problèmes en navigateur croisé. C'est particulièrement un problème lorsque les développeurs décident de n'utiliser que la version -webkit- d'une propriété — ce qui veut dire que le site ne fonctionnera pas sur d'autres navigateurs. En fait, cela arrive tellement souvent que d'autres navigateurs ont commencé à implémenter les versions préfixées -webkit- de plusieurs propriétés CSS, ils marcheront donc avec un tel code. L'utilisation des préfixes fournit par chaque navigateur a récemment déclinée précisément à cause de ce type de problèmes, mais il en reste encore certain qui demandent de l'attention.

- -

Si vous persistez a utiliser des fonctionnalités préfixées, assurez-vous d'utiliser les bonnes. Vous pouvez vérifier quels navigateurs ont besoin de préfixes sur les pages de référence MDN, et des sites comme caniuse.com. Si vous doutez, vous pouvez aussi vérifier en faisant des tests directement sur les navigateurs.

- -

Essayez cet exemple simple :

- -
    -
  1. Ouvrez google.com, ou un autre site qui a un en-tête proéminent ou un niveau de bloc d'élément.
  2. -
  3. Clic droit sur l'élément en question et choisir Inspecter/Inspecter l'élément (ou qu'importe l'option de votre navigateur) — cela devrait ouvrir les outils de dev dans votre navigateur, avec l'élément mis en valeur dans l'inspecteur du DOM.
  4. -
  5. Chercher une fonctionnalité que vous pouvez utiliser pour sélectionner cet élément. Par exemple, au moment de la rédaction, le logo principal de Google a un ID hplogo.
  6. -
  7. Entreposer une référence à cet élément dans une variable, par exemple : -
    var test = document.getElementById('hplogo');
    -
  8. -
  9. Maintenant essayez d'appliquer une nouvelle valeur pour la propriété CSS qui vous intéresse sur cet élément ; vous pouvez le faire en utilisant la propriété style de l'élément, par exemple essayez de taper ça dans votre console Javascript :
  10. -
  11. -
    test.style.transform = 'rotate(90deg)'
    -test.style.webkitTransform = 'rotate(90deg)'
    -
  12. -
- -

Quand vous commencez à taper la transcription du nom de la propriété après le deuxième point (notez qu'en Javascript, les noms des propriétés CSS sont écrites en lower camel case, sans trait d'union), la console Javascript devrait commencer à saisir automatiquement les noms des propriétés qui existent dans le navigateur et qui correspondent au mieux avec ce que vous écrivez. C'est utile pour trouver quelles versions de la propriété est implémentée dans ce navigateur.

- -

A l'heure où ces lignes sont écrites, Firefox et Chrome ont implémenté tous les deux les versions préfixées -webkit- et non préfixées de {{cssxref("transform")}} !

- -

Une fois que vous avez trouvé quels préfixes vous avez besoin de supporter, vous devriez tous les inscrire dans votre CSS, par exemple :

- -
-ms-transform: rotate(90deg);
--webkit-transform: rotate(90deg);
-transform: rotate(90deg);
- -

Cela vous assurera que tous les navigateurs qui supportent n'importe laquelle des formes de la propriété ci-dessus pourront faire marcher la fonctionnalité. Il convient de placer la version non préfixée en dernier, parce qu'elle sera la version la plus récente, que vous voulez que les navigateurs utilisent si c'est possible. Si par exemple un navigateur implémente la version -webkit- et la version non préfixée, il va en premier temps appliquer la version -webkit-, puis la remplacer par la version non préfixée. Vous voulez que cela se produise dans ce sens, et non dans l'autre.

- -

Bien entendu, appliquer cela à de nombreuses différentes règles CSS peut devenir très fastidieux. Il est préférable d'utiliser des outils d'automatisation qui le font pour vous. Et de tels outils existent :

- -

La prefix-free JavaScript library peut être jointe à une page, et détectera automatiquement quels sont les aptitudes détenues par navigateurs en analysant la page et en ajoutant les préfixes appropriés. C'est très facile et pratique à utiliser, bien qu'il ait quelques inconvénients (voir le lien au-dessus pour plus de détails), et on peut discuter du fait qu'analyser chaque feuille de style de votre site et ajouter des préfixes lors de l'exécution peut être un fardeau pour la puissance de traitement de l'ordinateur pour un grand site.

- -

Une autre solution est d'ajouter automatiquement les préfixes pendant le développement, et cela (et d'autres choses à venir) peut être fait en utilisant des outils comme Autoprefixer et PostCSS. Ces outils peuvent être utilisés de diverses manières, par exemple Autoprefixer a une version en ligne qui vous permet d'entrer votre CSS non préfixé sur la gauche, et vous donne une version avec préfixes ajoutés sur la droite. Vous pouvez sélectionner quels navigateurs vous voulez afin de vous assurer de bien supporter en utilisant la notation définie dans Autoprefixer options ; pour plus de détails, voir aussi Browserslist queries, qui est basé dessus. Comme exemple, la requête suivante sélectionnera les deux dernières versions de tous le navigateurs principaux et les versions d'IE  supérieure à la 9.

- -
last 2 versions, ie > 9
- - - -

Autoprefixer peut aussi être utilisé dans d'autres cas, plus pratiques — voir Autoprefixer usage. Par exemple vous pouvez l'utiliser avec un exécuteur de tâche/outil de build comme Gulp ou Webpack pour ajouter automatiquement les préfixes une fois que le développement a été fait. (Expliquer comment cela fonctionne est plutôt au-delà de la portée de cet article).

- -

Vous pouvez également utiliser un plugin pour éditeur de texte comme Atom ou Sublime text. Par exemple, dans Atom :

- -
    -
  1. Vous pouvez l'installer en allant dans Préférences > Installer, chercher Autoprefixer, puis cliquer sur installer.
  2. -
  3. Vous pouvez configurer une requête navigateur en appuyant sur le bouton Settings d'Autoprefixer et entrer la requête dans le champs texte de la section Setting de la page.
  4. -
  5. Dans votre code, vous pouvez sélectionner des sections de CSS auxquelles vous voulez ajouter des préfixes, ouvrez la palette de commande (Cmd/Ctrl + Shift + P), puis tapez Autoprefixer dedans et sélectionnez le résultat Autoprefixer qui auto complète.
  6. -
- -

En tant qu'exemple, nous avons entré le code suivant :

- -
body {
-  display: flex;
-}
- -

Nous l'avons sélectionné et exécuté la commande Autoprefixer, et il l'a remplacé par ça :

- -
body {
-  display: -webkit-box;
-  display: -ms-flexbox;
-  display: flex;
-}
- -

Les problèmes de mise en page

- -

Un autre problème qui peut survenir est la différence de mise en page entre les navigateurs. Historiquement c'était traité comme bien plus qu'un problème, mais ces derniers temps, avec les navigateurs modernes qui ont tendance à supporter le CSS plus systématiquement, les problèmes de mise en page ont plus tendance à être couramment associés avec :

- - - -
-

Note : Historiquement les développeurs web étaient habitués à utiliser des fichiers CSS appelés resets, qui supprimaient tous les styles par défaut des navigateurs qui s'appliquaient au HTML, et ensuite appliquaient leurs propres styles pour tout le reste — c'était fait pour rendre le style sur un projet plus cohérent, et réduire les possibles problèmes en navigateur croisé, spécialement pour les choses issues de la mise en page. Toutefois, cela a récemment été défini comme exagéré. Le meilleur équivalent que nous avons de nos jours c'est le normalize.css, un peu de CSS propre qui style discrètement par-dessus le style par défaut des navigateurs afin de rendre les éléments plus cohérents et fixe quelques problèmes de disposition. Nous vous recommandons d'appliquer normalize.css sur toutes vos pages HTML.

-
- -
-

Note :  Lorsque vous essayer de localiser un problème de disposition difficile, une bonne technique et d'ajouter une couleur éclatante {{cssxref("outline")}} sur l'élément dérangeant, ou sur tous les éléments à côté. Cela facilite la tâche pour voir où tous les éléments sont placés. Voir Debug your CSS with outline visualizations pour plus de détails...

-
- -

Support pour les nouvelles caractéristiques de disposition

- -

La plupart du travail de mise en page sur le web aujourd'hui et réalisé en utilisant les floats — c'est parce que les floats sont bien supportés (depuis IE 4, bien qu'il y ait un certain nombre de bugs qui auront besoin d'être examinés si vous essayez de supporter IE aussi loin). Il n'y a néanmoins pas de véritables explications sur la mise en page — utiliser les floats comme nous les utilisons est un vrai hack — et ils ont de sérieuses limites (par ex. voir Why Flexbox?)

- -

Plus récemment, des mécanismes dédiés à la disposition ont fait leur apparition, comme Flexbox et CSS Grids, qui rendent les tâches ordinaires de disposition bien plus simples et enlèvent les défauts. Ils ne sont cependant pas bien supportés dans les navigateurs :

- - - -

Les fonctionnalités de disposition ne sont pas aussi simples pour fournir des solutions de repli que de simples couleurs, ombres ou dégradés. Si les propriétés de disposition sont ignorées, la totalité de votre design sera réduit en pièces. De ce fait, vous devez utiliser une fonctionnalité de détection pour détecter si les navigateurs qui consultent votre site supportent ces caractéristiques de disposition, et appliquer différentes dispositions de manière sélective selon le résultat (nous couvrirons les fonctionnalités de détection dans un article à venir).

- -

Par exemple, vous pourriez appliquer une disposition flexbox sur les navigateurs modernes, et aussi appliquer une disposition en float pour les plus vieux navigateurs qui ne supportent pas flexbox.

- -
-

Note : Il y a une fonctionnalité assez récente en CSS appelé @supports, qui vous permet d'implémenter des tests de détection de fonctionnalités natives.

-
- -

Les problèmes de responsive design

- -

Le design responsive est la pratique de créer des dispositions web qui s'adaptent en fonction des facteurs de formes de l'appareil — par exemple différentes tailles d'écran, l'orientation (portait ou paysage), ou la résolution. Une disposition pour ordinateur de bureau par exemple paraîtra atroce lorsqu'elle sera affichée sur un appareil mobile, vous allez donc devoir fournir une disposition appropriée aux mobiles en utilisant les media queries, et assurez-vous qu'il est appliqué correctement en utilisant viewport. Vous pouvez trouver un bilan précis de telles pratiques dans The building blocks of responsive design.

- -

La résolution est également très préoccupante — par exemple, les appareils mobiles sont moins susceptibles d'avoir besoin de grosses images lourdes que des ordinateurs de bureau, et ont davantage tendance à avoir des connexions internet plus lentes et sans doute un échange de données coûteux qui gaspille la bande passante qui est un problème supplémentaire. De plus, certains appareils peuvent avoir une gamme de plusieurs résolutions, ce qui veut dire que des petites images peuvent s'afficher pixelisées. Il y a un nombre de techniques qui vous permette de travailler autour de tels problèmes, des simples mobile first media queries, aux plus complexes responsive image techniques.

- -

Une autre difficulté qui peut présenter des problèmes c'est le support des fonctionnalités par les navigateurs qui rendent les techniques suscitées possibles. Les media queries ne sont pas supportés sur IE 8 ou plus vieux, donc si vous voulez utiliser une disposition mobile en premier lieu puis une disposition pour ordinateur de bureau qui applique aux vieilles versions d'IE, vous devrez appliquer un media querie {{glossary("polyfill")}} à votre page, comme css3-mediaqueries-js ou Respond.js.

- -

Trouver de l'aide

- -

Il y bien d'autres problèmes que vous allez rencontrer avec le HTML et le CSS ; la chose la plus important à vraiment savoir est de comment trouver des solutions en ligne.

- -

Parmi les meilleures sources d'information de support il y a Mozilla Developer Network (c'est où vous vous trouvez actuellement !), stackoverflow.com et caniuse.com.

- -

Pour utiliser le Mozilla Developer Network (MDN), la plupart des gens font une recherche de la technologie sur laquelle ils essayent de trouver des informations, et ajoutent le terme "mdn", par exemple "mdn HTML5 video". MDN contient plusieurs types de contenus utiles :

- - - -

caniuse.com fournit des informations de support, tout au long avec des ressources externes. Par exemple, voir http://caniuse.com/#search=video (vous avez juste à entrer la fonctionnalité que vous recherchez dans la boîte de recherche)

- -

stackoverflow.com (SO) est un forum en ligne où vous pouvez poser des questions et avez un ensemble de développeurs partageant leurs solutions, observez les commentaires passés, et aidez les autres développeurs. Nous vous conseillons de chercher et de regarder s'il existe déjà une réponse à votre question, avant de poster une nouvelle question. Par exemple, nous avons cherché pour "cross browser html5 video" sur SO, et très rapidement la solution HTML5 Video with full cross browser compatibility est remontée.

- -

Par ailleurs, essayez de chercher votre moteur de recherche favori pour trouver une réponse à vos problèmes. C'est souvent utile de chercher les messages d'erreur spécifiques si vous en avez — d'autres développeurs seront susceptibles d'avoir les mêmes problèmes que vous

- -

Résumé

- -

Vous devriez maintenant être familier avec les problèmes principaux en navigateur croisé avec HTML et CSS que vous rencontrerez en développement web, et comment faire pour les résoudre.

- -

{{PreviousMenuNext("Learn/Tools_and_testing/Cross_browser_testing/Testing_strategies","Learn/Tools_and_testing/Cross_browser_testing/JavaScript", "Learn/Tools_and_testing/Cross_browser_testing")}}

- - - -

Dans ce module

- - diff --git a/files/fr/learn/tools_and_testing/github/index.html b/files/fr/learn/tools_and_testing/github/index.html new file mode 100644 index 0000000000..ce3590b73f --- /dev/null +++ b/files/fr/learn/tools_and_testing/github/index.html @@ -0,0 +1,94 @@ +--- +title: Git and GitHub +slug: Apprendre/Outils_et_tests/GitHub +tags: + - Apprendre + - Beginner + - Débutant + - GitHub + - Learn + - Web + - git +translation_of: Learn/Tools_and_testing/GitHub +--- +
{{LearnSidebar}}
+ +

Tous les développeurs utiliseront une sorte de système de contrôle des versions (version control system ou VCS en anglais), un outil leur permettant de collaborer avec d'autres développeurs sur un projet sans prendre le risque que l'un d'eux écrase le travail d'un autre, et de revenir à une version précédente de la base de code si un problème est découvert plus tard. Le plus populaires de ces outils (au mois parmi les développeurs) est Git, ainsi que GitHub, un site vous proposant d'héberger vos dépôts de code et plusieurs outils pour travailler avec eux. Ce module vise à vous enseigner ce que vous devez savoir à propos de ces deux outils.

+ +

Vue d'ensemble

+ +

Les systèmes de contrôles des versions sont nécessaires pour le développement de logiciel :

+ + + +

Les systèmes de contrôle des versions fournissent des outils pour répondre à ces besoins. Git est un exrmple d'un tel système, et GitHub est un site web avec une infrastructure qui propose un serveur Git et d'autres outils très pratiques pour travailler avec des dépôts Git individuellement ou en équipe, tel que le rapportage de problèmes liés au code, la relecture et validation de code, la gestion de projet par différentes fonctions comme l'assignation de tâches et les statistiques sur l'utilisation de tâches, et plus encore.

+ +
+

Note: Git est actuellement un système de contrôle des versions distribué, signifiant qu'une copie complète du dépôt contenant la base de code est fait sur votre ordinateur (et celui de tous les autres participants). Vous modifiez votre propre copie et puis vous les envoyez vers le serveur, où un administrateur pourra décider de les fusionner avec la copie commune ou non.

+
+ +
+

Vous cherchez à devenir un développeur web front-end ?

+ +

Nous avons mis ensemble un cours incluant toutes les informations nécessaires dont vous avez besoin pour atteindre votre objectif.

+ +

Commencer

+
+ +

Prérequis

+ +

Pour utiliser Git et GitHub, vous avez besoin :

+ + + +

En matière de connaissances prérequises, vous n'avez besoin de rien concernant le développement web, Git/GitHub ou les système de contrôle des versions pour commencer ce module. Toutefois, il vous est recommandé de connaitre les bases de la programmation afin que vous ayiez des connaissances informatiques suffisantes ainsi qu'un code à héberger dans vos dépôts !

+ +

Il est aussi préférable que vous ayiez quelques connaissances fondamentales sur le terminal, par exemple du déplacement entre dossiers, de la création de fichiers et de la modification du PATH du système.

+ +
+

Note: Github n'est pas le seul site et un ensemble d'outils que vous pouvez utiliser avec Git. Il existe d'autres alternatives telles que GitLab que vous pourriez essayer. Vous pouvez même tenter de configurer votre propre serveur Git et l'utiliser à la place de GitHub. Nous nous en sommes tenus à GitHub dans ce cours pour vous montrer une seule manière de faire.

+
+ +

Guides

+ +

Notez que les liens ci-après vous amènent à des ressources sur des sites externes. Nous envisageons la possibilité d'avoir notre cours  consacré à Git/GitHub, mais pour l'instant, ceux-ci vous aideront à mieux appréhender le sujet.

+ +
+
Hello World (de GitHub)
+
C'est un bon point pour commencer — ce guide pratique vous fera entrer dans l'utilisation de GitHub en vous apprenant les fondements de Git tels que la création de dépôts et de branches, la créations de commits ainsi qu'à l'ouverture et à la fusion de pull requests.
+
Git Handbook (de GitHub)
+
Ce manuel sur Git va plus en profondeur en expliquant ce qu'un système de contrôle des versions est, ce qu'on dépôt est, comment le modèle minimal de GitHub fonctionne, les commandes Git avec divers exemples et plus encore.
+
Forking Projects (de GitHub)
+
Forking projects est nécessaire quand vous souhaitez contribuer au code de quelqu'un d'autre. Ce guide vous explique comment.
+
About Pull Requests (de GitHub)
+
Un guide utile pour apprendre à gérer les pull requests, la manière dont les changements de code suggérés sont envoyés aux dépôts locaux des autres contributeurs pour être pris en considération.
+
Mastering issues (de GitHub)
+
Les issues (problèmes) sont comme un forum pour votre projet GitHub, où chacun peut venir poser des questions et rapporter des problèmes, et vous pouvez gérer les mises à jour (par exemple assigner certaines personnes à la résolution de problèmes, à la clarification de problèmes ou à l'information de la correction de problèmes). Cet article vous donne ce dont vous avez besoin de savoir à propos des issues.
+
+ +
+

Note: Il existe beaucoup d'autres choses que vous pouvez faire avec Git et GitHub, mais nous pensons que ce qui précède représente le minimum dont vous aurez besoin pour commencer à utiliser Git efficacement. Au fur et à mesure de votre progression avec Git, vous comprendrez de plus en plus qu'il est facile de faire des erreurs quand on commence à utiliser des commandes plus complexes. Ne vous inquiétez pas, même les développeurs web aguerris pensent que Git est parfois déroutant, et résolvent souvent des problèmes en cherchant des solutions sur internet ou en consultat des sites comme Flight rules for Git et Dangit, git!

+
+ +

Voir aussi

+ + diff --git a/files/fr/learn/tools_and_testing/index.html b/files/fr/learn/tools_and_testing/index.html new file mode 100644 index 0000000000..7fbb181871 --- /dev/null +++ b/files/fr/learn/tools_and_testing/index.html @@ -0,0 +1,42 @@ +--- +title: Outils et tests +slug: Apprendre/Outils_et_tests +tags: + - Accessibilité + - Apprendre + - Automatisation + - CSS + - Déboguage + - Débutant + - HTML + - JavaScript + - Outils + - tests +translation_of: Learn/Tools_and_testing +--- +
{{LearnSidebar}}
+ +

Une fois que vous commencerez à être à l'aise avec les langages de programmation web (comme le HTML, le CSS, et le JavaScript), et acquerrez plus d'expérience, lirez plus de ressources, et apprendrez plus de choses, vous commencerez à tomber sur toute sorte d'outils, comme par exemple des scripts CSS et JavaScript, des outils de tests et d'automatisation, et bien plus encore. Au fur et à mesure que vos projets web deviendront de plus en plus grands et complexes, vous allez vouloir savoir comment utiliser certains de ces outils et élaborer des tests fiables pour votre code. Cette partie de la zone d'apprentissage cherche à vous donner tout ce dont vous avez besoin afin de commencer sur de bonnes bases et faire des choix informés.

+ +

L'industrie du web est un endroit excitant où travailler, mais ce n'est pas sans ses complications. Les technologies de base que nous utilisons pour concevoir des sites web sont assez stables maintenant, mais de nouvelles fonctionnalités sont ajoutées continuellement, et de nouveaux outils — qui les rendent faciles d'utilisation, et sont construits sur ces technologies — apparaissent constamment. En plus de cela, il ne faut pas oublier de vérifier que notre code utilise les meilleures pratiques qui permettront à notre projet de fonctionner sur différents navigateurs et appareils, et d'être aussi utilisable par des personnes ayant un handicap.

+ +

Savoir précisément quels outils prendre peut parfois être une tâche difficile, c'est pourquoi nous avons écrit cette séries d'articles, afin de vous expliquer quels types d'outils existent, ce qu'ils peuvent faire pour vous et comment se servir des plus utilisés dans l'industrie.

+ +
+

Note: parce que de nouveaux outils apparaissent tout le temps et que les anciens se démodent, nous avons écrit ceci afin d'être aussi neutre que possible — nous voulons nous concentrer premièrement et essentiellement sur les tâches générales que ces outils vont vous aider à accomplir, plutôt que de parler des outils qui sont spécifiques à une tâche. Nous devons bien sûr vous montrer comment utiliser un outil avant de vous en apprendre les techniques spécifiques, mais gardez à l'esprit que les outils que nous vous montrons ne sont pas forcément les meilleurs, ni les seuls disponibles — dans la plupart des cas il existe d'autre façons de faire, mais nous voulons vous fournir une méthodologie claire et qui fonctionne.

+
+ +

Parcours d'apprentissage

+ +

Vous devriez vraiment apprendre les langages de base HTML, CSS, et JavaScript avant d'essayer d'utiliser les outils présentés ici. Par exemple, vous allez avoir besoin de connaître les fondamentaux de ces langages avant de commencer à déboguer des erreurs dans un code source web complexe, ou utiliser efficacement les librairies JavaScript , ou encore écrire des tests et les utiliser sur vos codes, etc.

+ +

Vous avez d'abord besoin d'une base solide.

+ +

Modules

+ +
+
Outils de développement web
+
Dans ce module, nous explorons les différents types d'outils de développement web. Ceci inclut de connaître les tâches les plus courantes que vous serez amenés à résoudre, comment les intégrer au sein d'un workflow, et les meilleurs outils actuellement disponibles afin d'effectuer ces tâches.
+
Test à travers différents navigateurs
+
Ce module est orienté spécifiquement vers les tests de projets web à travers différents navigateurs. Ici on cherche à identifier quel type d'audience vous ciblez (ex. de quels utilisateurs, navigateurs et appareils avez vous le plus besoin de vous soucier?), comment faire des tests, les principaux problèmes auxquels vous devrez faire face avec différents types de codes et comment en venir à bout, quels outils sont les plus adaptés pour vous aider à cerner et résoudre ces problèmes, et comment utiliser l'automatisation afin d'accélérer les tests.
+
diff --git a/files/fr/learn/tools_and_testing/understanding_client-side_tools/command_line/index.html b/files/fr/learn/tools_and_testing/understanding_client-side_tools/command_line/index.html new file mode 100644 index 0000000000..74d503b7d4 --- /dev/null +++ b/files/fr/learn/tools_and_testing/understanding_client-side_tools/command_line/index.html @@ -0,0 +1,487 @@ +--- +title: Cours express sur la ligne de commande +slug: Learn/Tools_and_testing/Understanding_client-side_tools/Ligne_de_commande +tags: + - CLI + - Côté client + - Débutant + - Outils + - Terminal + - ligne de commande + - npm +translation_of: Learn/Tools_and_testing/Understanding_client-side_tools/Command_line +--- +
{{LearnSidebar}}
+ +
{{PreviousMenuNext("Learn/Tools_and_testing/Understanding_client-side_tools/Overview","Learn/Tools_and_testing/Understanding_client-side_tools/Package_management", "Learn/Tools_and_testing/Understanding_client-side_tools")}}
+ +

Au cours de tout process de développement, vous allez très certainement être confronté à la nécessité d'exécuter des commandes dans un terminal (ce que l'on appelle "travailler en ligne de commande"). Cet article vous propose une introduction au terminal et vous dévoile les commandes essentielles dont vous aurez besoin, la façon de les chaîner, et comment ajouter vos propres outils d'interface en ligne de commande (CLI, command line interface).

+ + + + + + + + + + + + +
Prérequis : +

Être familiarisé avec les bases des langages

+ HTML, CSS, et JavaScript.
Objectif : +

Comprendre ce qu'est la ligne de commande, savoir quelles sont les commandes de base que vous devriez connaître, et comment installer de nouveaux outils de ligne de commande.

+
+ +

Bienvenue sur le terminal

+ +

Le terminal est une interface de texte pour l'exécution de programmes qui utilisent un langage lui-même textuel . Quel que soit le type d'outils que vous allez utiliser pour le développement web, il y a de grandes chances que vous soyez amené à travailler en ligne de commande pour les utiliser (vous rencontrerez aussi l'appellation "console" ou encore "CLI tools" pour désigner de tels outils d'interface en ligne de commande).

+ +

Il existe de nombreux outils pour travailler en ligne de commande ; certains sont pré-installés sur votre système, et une infinité d'autres sont disponibles sur des dépôts de "paquets" (packages). Ces dépôts sont un peu comme des magasins spécialisés (pour la plupart) dans les outils de ligne de commande et les logiciels. Nous allons voir un peu plus loin dans ce chapitre comment installer certains de ces outils, et nous en apprendrons plus sur les dépôts de paquets dans le prochain chapitre.

+ +

L'une des critiques les plus fréquentes envers la ligne de commande, c'est que l'utilisateur courant n'en a pratiquement aucune expérience. Se retrouver devant un terminal pour la première fois peut être vraiment intimidant : un écran vide, un curseur qui clignote, et rien ou presque pour vous aider à en tirer quelque chose.

+ +

Malgré cette apparence rebutante, le terminal est pourtant un outil puissant, et nous pouvons vous promettre qu'avec une petite formation et un peu de pratique, son utilisation vous deviendra bien plus facile ! C'est la raison pour laquelle nous vous proposons ce chapitre - pour vous aider à démarrer dans cet environnement apparemment inhospitalier.

+ +

.

+ +

Quelle est l'origine du terminal ?

+ +

Elle se situe dans les années 50-60, et son aspect d'alors ne ressemble pas du tout à ce que nous connaissons aujourd'hui (heureusement). Vous pouvez en apprendre davantage sur la page de Wikipédia Terminal (informatique).

+ +

Depuis, le terminal est resté un élément constant de tout système d'exploitation - des ordinateurs de bureau aux serveurs du cloud (qui n'est pas vraiment un nuage) en passant par les micro-cartes comme la Raspberry PI Zero et même les téléphones mobiles. Il offre un accès direct au système de fichiers de l'ordinateur et à des fonctionnalités de bas niveau, ce qui le rend incroyablement apte à accomplir rapidement des tâches complexes, à condition de savoir ce que vous faites.

+ +

Il est également utile pour automatiser certaines tâches, comme par exemple modifier les titres de centaines de fichiers instantanément - par exemple changer tous les "ch01-xxxx.png" en "ch02-xxxx.png", ce qui vous prendrait un temps considérable si vous deviez le faire à la main dans la fenêtre d'un gestionnaire de fichiers.

+ +

En tous cas, le terminal ne va pas disparaître de si tôt.

+ +

À quoi ressemble un terminal ?

+ +

Vous pouvez voir ci-dessous les apparences de quelques terminaux émulés par des programmes courants.

+ +

Les images suivantes montrent les invites de commande disponibles sous Windows – il y a une panoplie d’options, du programme « cmd » au « powershell » - qui peuvent être lancées depuis le menu de démarrage en tapant le nom du programme.

+ +

A vanilla windows cmd line window, and a windows powershell window

+ +

Et ci-dessous, vous pouvez voir l’application de terminal pour macOS.

+ +

A basic vanilla mac terminal

+ +

Comment ouvrir un terminal ?

+ +

Beaucoup de développeurs se servent aujourd'hui de terminaux de type Unix (c'est-à-dire le terminal en lui-même plus les outils auxquels il donne accès). Beaucoup de tutoriels sur le web sont basés sur ces terminaux Unix qu'ils considèrent (malheureusement) comme universels, mais nous allons voir dans cette section comment ouvrir un terminal sur le système de votre choix.

+ +

Linux/Unix

+ +

Comme indiqué plus haut, les systèmes Linux/Unix disposent d'un terminal par défaut, présent dans vos Applications.

+ +

macOS

+ +

macOS a un système nommé Darwin qui réside sous l'interface graphique. Darwin est un système de type Unix, qui fournit le terminal, et l'accès aux outils de bas niveau. Darwin est dans l'ensemble assez proche d'Unix pour ne pas nous causer trop de problèmes lors de notre progression dans cet article.

+ +

Ce terminal est disponible sur macOS dans Applications/Utilitaires/Terminal.

+ +

Windows

+ +

Comme pour d'autres outils de programmation, c’est un peu une tradition pour Windows de ne pas faciliter l’utilisation du terminal (ou ligne de commande) par rapport à d’autres systèmes d’exploitation. Mais les choses s’améliorent.

+ +

Traditionnellement aussi, Windows a depuis longtemps eu son propre programme de type « terminal », appelé « cmd » (« l’invite de commande »), mais celui-ci n’est en rien comparable aux commandes Unix, et il est en fait équivalent au programme DOS des temps héroïques.

+ +

On trouve malgré tout de meilleurs programmes qui offrent une expérience de terminal sur Windows, tels que Powershell (voir ici pour l’installer), et Gitbash (qui fait partie de la trousse à outils git for Windows).

+ +

Quoi qu’il en soit, aujourd’hui, la meilleure option est le « Windows Subsystem for Linux » (WSL) – une couche de compatibilité qui permet de lancer des systèmes d’exploitation Linux directement dans Windows 10, ce qui vous permet d’avoir un « vrai terminal », sans recourir à une machine virtuelle.

+ +

Vous pouvez l’installer gratuitement directement à partir du Windows store. Toute la documentation utile est disponible dans la Windows Subsystem for Linux Documentation .

+ +

a screenshot of the windows subsystem for linux documentation

+ +

Si vous vous demandez quelle option choisir sur Windows, nous vous recommandons vivement de vous décider pour le WSL. Vous pourriez certes vous en tenir à l’invite de commande par défaut (« cmd »), et faire tourner pas mal d’outils correctement, mais tout sera bien plus facile si vous avez une meilleure équivalence avec les outils Unix.

+ +

En passant, quelle est la différence entre ligne de commande et terminal ?

+ +

En général, vous rencontrerez ces deux termes utilisés de façon interchangeable. Techniquement, un terminal (ou console) est un logiciel qui se connecte à un shell au démarrage. Un shell correspond à votre session et à votre environnement de session (où des choses comme l’invite de commande et les raccourcis peuvent être personnalisés). La ligne de commande quant à elle (ou prompt) est la ligne de texte où vous entrez des commandes et où le curseur clignote.

+ +

Est-ce qu'il faut se servir du terminal?

+ +

Bien que les outils disponibles à partir de la ligne de commande soient très riches, si vous utilisez des outils tels que Visual Studio Code vous allez avoir accès à une quantité d’extensions que vous pourrez utiliser pour vous aider dans l’édition et vous allez pouvoir vous passer presque complètement du terminal lui-même. Cependant, vous ne pourrez pas trouver une extension sur votre éditeur de code pour tout ce que vous voudrez faire – en définitive, vous devrez malgré tout vous confronter au terminal.

+ +

Les commandes intégrées de base

+ +

Assez parlé — voyons maintenant quelques commandes utilisables dans un terminal ! Voici, clés en main, un petit aperçu de tout ce que l'on peut faire en ligne de commande, avec la référence des outils pertinents dans chaque cas :

+ + + +
+

Note : On trouve  sur le web un bon nombre de tutoriels de qualité qui permettent d'aller beaucoup plus loin avec la ligne de commande — ceci n'est qu'une brève introduction ! L'auteur de ces lignes lui-même a sa propre série de vidéos de formation au terminal (80% de réduction en utilisant le code mdn au moment du paiement — 19$).

+
+ +

Pour aller plus loin, voyons maintenant comment utiliser quelques-uns de ces outils en ligne de commande. Commencez par ouvrir votre programme de terminal (ou console) !

+ + + +

Lorsque vous vous mettez sur la ligne de commande, vous allez inévitablement devoir naviguer vers un répertoire spécifique pour y "faire quelque chose". Tous les systèmes d'exploitation (du moins avec un paramétrage par défaut) démarrent leur terminal dans votre répertoire d'utilisateur, et il y a des chances pour que vous souhaitiez vous rendre de là à un autre emplacement.

+ +

La commande cd vous permet de changer de répertoire (Change Directory). Techniquement, cd n'est pas un programme mais une commande intégrée. Cela signifie que votre système d'exploitation la fournit de façon native, et aussi que vous ne pouvez pas l'effacer accidentellement - bonne nouvelle ! Cela dit, vous n'avez pas besoin de vous soucier de savoir si une commande est intégrée ou non, mais vous pouvez garder à l'esprit que les commandes intégrées sont présentes sur les systèmes basés sur Unix.

+ +

Pour changer de répertoire, vous tapez cd dans votre terminal, suivi par le répertoire dans lequel vous voulez vous rendre. En supposant que le répertoire (ou dossier) Desktop se trouve dans votre répertoire utilisateur, vous allez donc taper cd Desktop (voir les copies d'écran ci-dessous).

+ +

results of the cd Desktop command being run in a variety of windows terminals - the terminal location moves into the desktop

+ +

Sur un système en langue française, vous trouverez plus fréquemment "Bureau" plutôt que "Desktop". Essayez de taper ceci dans votre terminal système (sur un système en langue anglaise, bien sûr conservez "Desktop") :

+ +
cd Bureau
+ +

Si vous voulez revenir au répertoire précédent, utilisez les deux points :

+ +
cd ..
+ +
+

Note: Raccourci vraiment utile sur un terminal, la touche tab émule la saisie automatique des mots dont vous connaissez l'existence, ce qui vous évite de les taper en entier. Par exemple, après avoir tapé les deux commandes ci-dessus, essayez de taper cd B puis de presser la touche tab — cela devrait saisir automatiquement le nom de répertoire Bureau, à condition qu'il soit présent dans le répertoire courant. Gardez ceci à l'esprit tout en poursuivant.

+
+ +

Si le répertoire que vous visez est placé assez loin dans l'arborisation des fichiers, il vous faut connaître le chemin (on dit souvent path, qui est le terme anglais) pour vous y rendre. Cela devient en général plus facile à mesure que vous vous familiarisez avec la structure de votre système de fichiers, mais si vous n'êtes pas sûr vous pouvez le retrouver en combinant la commande ls avec des clicks dans votre Explorer ou autre gestionnaire graphique de fichiers, ce qui va vous permettre de voir où se trouve le répertoire (ou dossier) cherché par rapport à votre répertoire actuel (= répertoire courant).

+ +

Par exemple, si vous vouliez aller dans un dossier nommé src, qui se trouve dans un dossier nommé projet, qui est lui-même sur le Bureau, vous pourriez taper ces trois commandes pour y arriver à partir de votre dossier utilisateur :

+ +
cd Bureau
+cd projet
+cd src
+ +

Mais c'est une perte de temps — à la place, vous pouvez taper une seule commande, avec les différents éléments du chemin séparés par des slashes, exactement de la même manière que lorsque vous spécifiez les chemins d'accès à des images ou autres assets en CSS, HTML, ou JavaScript :

+ +
cd Bureau/projet/src
+ +

Notez que si vous commencez le chemin par un slash, vous le rendez absolu, par exemple /Utilisateurs/votre-nom/Bureau. Omettre le premier slash comme nous l'avons fait ci-dessus construit un chemin relatif à votre répertoire de travail actuel. C'est exactement la même chose qu'une URL dans un navigateur. Un slash au début signifie "à la racine du site web", alors qu'omettre le slash signifie "l'URL est relative à ma page courante".

+ +
+

Note: Sur windows vous devez utiliser des backslashes et non des slashes, p. ex. cd Bureau\projet\src — cela peut vous paraître vraiment étrange, mais si la question vous intéresse, regardez cette vidéo YouTube (en anglais) qui présente une explication par l'un des ingénieurs principaux de Microsoft.

+
+ +

Lister le contenu d'un répertoire

+ +

ls (de l'anglais list) est la commande intégrée Unix qui va vous permettre de lister le contenu du répertoire dans lequel vous vous trouvez. Notez que cela ne fonctionnera pas avec l'invite de commande par défaut de Windows (cmd) — la commande équivalente est dir.

+ +

Essayez de taper ceci dans votre terminal :

+ +
ls
+ +

Vous obtenez la liste des fichiers et répertoires de votre répertoire de travail courant, mais l'information est vraiment basique - vous n'avez que les noms des items, sans savoir s'il s'agit d'un fichier, d'un répertoire, ou d'autre chose. Heureusement, une petite modification dans l'utilisation de la commande va vous donner beaucoup plus d'informations.

+ +

Présentation des options de commandes

+ +

La plupart des commandes de terminal possèdent des options - ce sont des modificateurs que vous ajoutez à la fin d'une commande pour obtenir un comportement légèrement différent. Il s'agit en général d'un espace suivi d'un tiret puis d'une ou de plusieurs lettres.

+ +

Voyez par exemple ce que vous obtenez en essayant ceci :

+ +
ls -l 
+ +

Avec ls, l'option -l (tiret l, "dash ell" en anglais) vous donne une liste avec un fichier ou répertoire par ligne et pas mal d'autres informations. Les répertoires ("directories") sont repérés pas la lettre "d" au tout début de la ligne. Nous pouvons y entrer avec la commande cd.

+ +

Voici ci-dessous une copie d'écran avec un terminal macOS “vanilla” en haut, et en bas un terminal personnalisé avec quelques icônes supplémentaires et des couleurs pour le rendre plus vivant — les deux affichent le résultat de la commande ls -l :

+ +

A vanilla mac terminal and a more colorful custom mac terminal, showing a file listing - the result of running the ls -l command

+ +
+

Note: Pour savoir exactement quelles sont les options d'une commande, vous pouvez consulter sa page de manuel (man page en anglais). Pour cela, tapez la commande man suivie du nom de la commande que vous cherchez, par exemple man ls. La page de manuel va s'ouvrir dans le lecteur de texte par défaut de votre terminal (par exemple, less sur mon terminal), et vous allez pouvoir faire défiler la page avec les touches de flèches ou un mécanisme similaire. La page de manuel liste toutes les options de façon très détaillée, ce qui peut être un peu intimidant au début, mais au moins vous savez où les trouver si vous en avez besoin. Lorsque vous avez terminé avec la page de manuel, vous la refermez avec la commande "quitter" de votre visionneur de texte (pour less c'est "q" ; si ce n'est pas évident cherchez sur Internet).

+
+ +
+

Note: Pour lancer une commande avec des options multiples, on peut en général les regrouper dans une seule chaîne de caractères après le tiret, par exemple ls -lah, ou ls -ltrh. Exercez-vous à consulter la page man de ls pour savoir ce que vous donnent ces options !

+
+ +

Maintenant que vous connaissez ces deux commandes fondamentales, allez un peu fouiller dans votre système de fichiers en naviguant à partir de votre répertoire.

+ +

Créer, copier, déplacer, supprimer

+ +

Il y existe un certain nombre d'autres commandes d'utilité basique dont vous allez probablement pas mal vous servir en travaillant sur un terminal. Elles sont assez simples, aussi nous n'allons pas les expliquer avec autant de détails que les deux précédentes.

+ +

Jouez avec elles dans un répertoire que vous aurez créé quelque part de façon à ne pas effacer accidentellement quoi que ce soit d'important, en vous servant des exemples donnés pour vous guider :

+ + + +
+

Note : Beaucoup de commandes de terminal autorisent l'emploi d'astérisques comme caractère "joker", dont le sens est "une séquence de caractères quelconque". Cela vous permet d'exécuter une commande en une seule fois sur un nombre potentiellement important de fichiers qui correspondent au modèle donné. À titre d'exemple, rm mdn-* va effacer tous les fichiers qui commencent par mdn-. rm mdn-*.bak va effacer tous les fichiers qui commencent par mdn- et finissent par .bak.

+
+ +

Le terminal — une pratique à risque ?

+ +

Nous y avons déjà fait allusion, et soyons clairs - travailler sur terminal demande de la prudence. Des commandes simples ne présentent pas trop de risques, mais dès que vous commencez à combiner des commandes plus complexes, il vous faut réfléchir soigneusement à ce qu'elle va exécuter, et essayer de la tester avant de la lancer effectivement dans le répertoire voulu.

+ +

Supposons que vous ayez 1000 fichiers texte dans un répertoire, et que vous vouliez les parcourir en supprimant uniquement ceux dont le nom comprend une certaine chaîne de caractères. Si vous ne faites pas attention, vous risquez d'effacer quelque chose d'important et de perdre du coup une somme de travail. Une bonne habitude à prendre consiste à écrire votre ligne de commande dans un éditeur de texte, à la construire à votre idée, et ensuite à faire une copie de sauvegarde de votre répertoire avant d'essayer la commande sur celui-ci.

+ +

Autre astuce intéressante : si vous n'êtes pas à l'aise avec l'idée d'essayer des lignes de commande sur votre propre machine, le site Glitch.com est un bon endroit pour le faire en toute sécurité. En plus d'être un lieu génial pour tester du code de développement web, les projets vous donnent accès à un terminal qui vous permet de lancer toutes les commandes que vous voulez, sans risquer d'endommager votre propre machine.

+ +

a double screenshot showing the glitch.com home page, and the glitch terminal emulator

+ +

Le site tldr.sh est une formidable ressource pour obtenir un aperçu de commandes particulières. C'est un service de documentation géré de façon communautaire, similaire à MDN, mais dédié aux commandes de terminal.

+ +

Dans la section suivante, nous allons monter d'un cran (et même de plusieurs), et voir comment nous pouvons combiner plusieurs outils en ligne de commande pour révéler toute la puissance du terminal par rapport à l'interface graphique habituelle.

+ +

Combiner des commandes grâce aux "pipes"

+ +

L'usage du terminal prend toute sa valeur lorsque vous commencez à chaîner les commandes en utilisant le symbole | ("pipe" ou "tuyau" en français). Voyons comment on peut faire cela sur un exemple très rapide.

+ +

Nous avons déjà vu ls, qui liste le contenu du répertoire courant :

+ +
ls
+ +

Mais comment nous y prendre si nous voulons compter le nombre de fichiers et de répertoires à l'intérieur du répertoire courant ? ls n'est pas capable de faire cela à lui seul.

+ +

Il existe un autre outil Unix nommé wc. Celui-ci compte les mots, lignes, caractères, ou octets de la donnée qu'on lui passe, quelle qu'elle soit. Il peut s'agir d'un fichier texte — l'exemple ci-dessous donne le nombre de lignes de monfichier.txt :

+ +
wc -l monfichier.txt
+ +

Mais wc est également capable de compter les lignes de tout ce qui lui est passé par un pipe. Par exemple, la commande ci-dessous compte les lignes renvoyées par la commande ls  (lignes qui seraient normalement affichées sur le terminal) et affiche ce décompte à la place :

+ +
ls | wc -l
+ +

Comme ls affiche chaque fichier ou répertoire sur une nouvelle ligne, on obtient bien le compte des répertoires et des fichiers.

+ +

Comment ça marche ? Le comportement général des outils de ligne de commande (unix) consiste à afficher du texte dans le terminal (ce qu'on appelle aussi "imprimer sur la sortie standard (standard input)" ou  STDOUT). Un bon nombre de commandes peuvent aussi lire du contenu à partir d'un flux d'entrée (appelé "entrée standard (standard input)" ou STDIN).

+ +

L'opérateur pipe peut connecter ces entrées et sorties, ce qui nous permet de construire des opérations de plus en plus complexes selon nos besoins — la sortie d'une commande devient l'entrée de la commande suivante. Dans le cas présent, ls enverrait normalement sa sortie sur STDOUT, mais au lieu de cela la sortie de ls est passée par un pipe à wc, qui la prend en entrée, compte ses lignes et imprime ce décompte sur STDOUT.

+ +

Un exemple un peu plus complexe

+ +

Occupons-nous maintenant de quelque chose d'un peu plus compliqué. Nous allons d'abord essayer de récupérer le contenu de la page MDN "fetch" en utilisant la commande curl  (dont on peut se servir pour faire une requête de contenu à partir d'URLs), sur https://developer.mozilla.org/en-US/docs/Web/API/fetch.

+ +

En fait, cette URL est celle de l'ancien emplacement de la page. Lorsque vous l'entrez dans un nouvel onglet de votre navigateur, vous êtes (finalement) redirigé sur https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch.

+ +

Par conséquent, si vous utilisez curl pour faire une requête à https://developer.mozilla.org/docs/Web/API/fetch, vous n'aurez pas de résultat. Essayez :

+ +
curl https://developer.mozilla.org/en-US/docs/Web/API/fetch
+ +

Nous devons dire explicitement à curl de suivre les redirections en utilisant l'option -L.

+ +

Examinons également les en-têtes retournées par developer.mozilla.org en utilisant l'option -I de curl, et affichons toutes les redirections en passant la sortie de curl à grep grâce à un pipe (on va demander à grep de renvoyer toutes les lignes qui contiennent le mot "location").

+ +

Essayez maintenant la ligne suivante, et vous allez constater qu'il y a en fait trois redirections avant d'atteindre la page finale :

+ +
curl https://developer.mozilla.org/docs/Web/API/fetch -L -I | grep location
+ +

Votre sortie devrait ressembler à ceci (curl va d'abord afficher des compteurs et autres informations de téléchargement) :

+ +
location: /en-US/docs/Web/API/fetch
+location: /en-US/docs/Web/API/GlobalFetch/GlobalFetch.fetch()
+location: /en-US/docs/Web/API/GlobalFetch/fetch
+location: /en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch
+ +

Bien que ce résultat soit artificiel, nous pourrions le pousser un peu plus loin et remplacer location: par le nom de domaine, de façon à avoir des URLs complètes. Pour cela, nous allons ajouter awk à notre formule (il s'agit d'un langage de programmation tout comme JavaScript, Ruby ou Python, mais beaucoup plus ancien !).

+ +

Essayez de lancer cette commande :

+ +
curl https://developer.mozilla.org/docs/Web/API/fetch -L -I | grep location | awk '{ print "https://developer.mozilla.org" $2 }'
+ +

Votre sortie finale devrait ressembler à ceci :

+ +
https://developer.mozilla.org/en-US/docs/Web/API/fetch
+https://developer.mozilla.org/en-US/docs/Web/API/GlobalFetch/GlobalFetch.fetch()
+https://developer.mozilla.org/en-US/docs/Web/API/GlobalFetch/fetch
+https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch
+ +

En combinant ces commandes nous avons personnalisé la sortie pour qu'elle montre les URLs complètes vers lesquels le serveur de Mozilla effectue les redirections lorsque nous lui soumettons la requête pour l'URL /docs/Web/API/fetch.
+ Développer votre connaissance du système en apprenant le fonctionnement de ces simples outils et comment les intégrer à votre arsenal pour résoudre des problèmes bien particuliers - cela vous sera d'une grande utilité tout au long des années à venir.

+ +

Ajoutez des super-pouvoirs !

+ +

À présent que nous avons jeté un œil à quelques-unes des commandes intégrées dont votre système est pré-équipé, voyons comment installer un outil tiers de CLI et nous en servir.

+ +

La plus grande partie du vaste écosystème d'outils installables pour le développement web front-end se trouve sous npm, un service privé d'hébergement de packages qui fonctionne en étroite interaction avec Node.js. Celui-ci se développe peu à peu — vous pouvez vous attendre à davantage de fournisseurs de packages avec le temps.

+ +

L'installation de Node.js installe en même temps l'outil de ligne de commande npm (ainsi que npx, un outil supplémentaire centré sur npm), qui est la porte d'entrée pour l'installation d'outils de ligne de commande additionnels. Node.js et npm fonctionnent de la même façon sur tous les systèmes : macOS, Windows, ainsi que Linux.

+ +

Allons-y : installez npm sur votre système à partir de l'URL ci-dessus qui va vous permettre de télécharger et de lancer un installeur Node.js approprié à votre système d'exploitation. Si cela vous est proposé, assurez-vous d'inclure npm dans l'installation.

+ +

the node.js installer on windows, showing the option to include npm

+ +

Un certain nombre d'outils variés vous attendent dans le prochaine article ; pour l'instant nous allons nous faire la main sur Prettier. Prettier est un outil de formatage de code normatif qui se présente comme ayant "peu d'options". Moins d'options, cela évoque plus de simplicité. Vu comme on peut parfois être débordé par la complexité de certains outils, le concept  "peu d'options" peut se révéler très attractif.

+ +

Où installer nos outils de CLI ?

+ +

Avant de nous lancer dans l'installation de Prettier, une question se pose — "où allons-nous l'installer ?"

+ +

npm nous donne le choix entre une installation globale — ce qui nous permet d'y avoir accès de n'importe où — ou bien locale, dans le dossier du projet en cours.

+ +

Il y a des pour et des contre pour les deux options — la liste ci-dessous est loin d'être exhaustive:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Pour l'installation globaleContre l'installation globale
Accessible partout dans votre terminalPeut ne pas être compatible avec votre codebase.
Installation en une foisLes autres développeurs de votre équipe n'auront pas accès à ces outils, par exemple si vous partagez votre codebase sur un outil comme git.
Moins d'espace disqueEn lien avec le point précédent, rend le code du projet plus difficile à répliquer (si vous installez vos outils en local, ils peuvent être configurés comme des dépendances et installés avec npm install).
Stabilité de la version
Donne l'impression d'être une commande unix comme les autres
+ +

Bien que la liste des contre soit plus courte, l'impact négatif d'une installation globale est potentiellement beaucoup plus lourd que les bénéfices. Cela dit, pour l'instant, nous allons choisir l'installation globale dans un but de simplicité. Nous examinerons davantage les installations locales et leur intérêt dans notre prochain article.

+ +

Installation de Prettier

+ +

Dans cette partie nous allons installer Prettier en tant qu'utilitaire global de ligne de commande.

+ +

Prettier est un outil de formatage de code normatif pour les développeurs front-end, centré sur le langage JavaScript et ses dérivés, avec un support pour HTML, CSS, SCSS, JSON et plus.

+ +

Prettier offre les avantages suivants :

+ + + +

Après avoir installé node, ouvrez votre terminal et lancez les commandes suivantes pour installer Prettier :

+ +
npm install --global prettier
+ +

Lorsque la commande a terminé son exécution, l'outil Prettier est disponible sur sur votre terminal, partout dans votre système de fichiers.

+ +

En lançant la commande sans argument, comme pour beaucoup d'autres commandes, vous obtiendrez les informations d'utilisation et d'aide. Essayez :

+ +
prettier
+ +

La sortie devrait ressembler à ceci :

+ +
Usage: prettier [options] [file/glob ...]
+
+By default, output is written to stdout.
+Stdin is read if it is piped to Prettier and no files are given.
+
+…
+ +

Cela vaut toujours la peine d'au moins survoler les informations sur l'utilisation, même lorsqu'elles sont longues. Vous pourrez ainsi mieux comprendre à quoi l'outil est censé servir.

+ +

Un peu de pratique

+ +

Jouons un peu avec Prettier pour que vous puissiez voir comment il fonctionne.

+ +

Tout d'abord, créez un nouveau répertoire à un endroit que vous pourrez retrouver facilement, par exemple un répertoire nommé prettier-test sur votre Bureau.

+ +

Ensuite collez le code suivant dans un fichier que vous enregistrez dans ce répertoire sous le nom index.js.

+ +
const myObj = {
+a:1,b:{c:2}}
+function printMe(obj){console.log(obj.b.c)}
+printMe(myObj)
+ +

Nous pouvons exécuter prettier sur un code source simplement pour vérifier s'il nécessite une correction. Passez dans votre répertoire avec cd et essayez de lancer cette commande :

+ +
prettier --check index.js
+ +

Vous devriez obtenir quelque chose comme

+ +
Checking formatting...
+index.js
+Code style issues found in the above file(s). Forgot to run Prettier?
+
+ +

Le style nécessite donc des corrections. Pas de problème. On va les appliquer en ajoutant l'option --write à la commande prettier, ce qui nous laisse nous concentrer sur l'aspect utile de l'écriture du code.

+ +

Essayez maintenant de lancer cette version de la commande :

+ +
prettier --write index.js
+ +

La sortie ressemble maintenant à ceci

+ +
Checking formatting...
+index.js
+Code style issues fixed in the above file(s).
+ +

Mais le plus important, c'est que votre fichier JavaScript a été reformaté :

+ +
const myObj = {
+  a: 1,
+  b: { c: 2 },
+};
+function printMe(obj) {
+  console.log(obj.b.c);
+}
+printMe(myObj);
+ +

Vous pouvez intégrer cette opération automatisée à votre workflow. L'intérêt des outils réside justement dans l'automatisation ; personnellement, notre préférence va  au type d'automatisme qui se produit de façon transparente, sans qu'aucune configuration soit nécessaire.

+ +

Il existe de nombreuses façons de mettre en oeuvre des automatismes avec Prettier, et bien qu'elles dépassent le cadre de cet article, vous trouverez de l'aide dans d'excellentes ressources en ligne, dont certaines grâce aux liens ci-après. Vous pouvez lancer prettier :

+ + + +

Nous préférons personnellement la deuxième solution — quand on code par exemple sur VS Code, Prettier entre en jeu et nettoie le formatage lors de chaque  enregistrement. Vous trouverez dans les Prettier docs beaucoup plus d'informations sur les différentes façons d'utiliser Prettier.

+ +

Autres outils à essayer

+ +

Voici une courte liste de quelques outils supplémentaires que vous pouvez vous amuser à tester :

+ + + +

L'auteur a aussi décrit certains de ses favoris accompagnés de copies d'écrans si vous avez envie de creuser davantage le sujet.

+ +

Notez que certains de ces outils nécessitent l'installation préalable de npm, ainsi que nous l'avons fait pour Prettier.

+ +

Résumé

+ +

Nous voilà parvenus au terme de cette brève revue du terminal ou ligne de commande. Dans la suite, nous allons nous pencher plus en détail sur les package managers, et sur les possibilités qu'ils nous offrent.

+ +

{{PreviousMenuNext("Learn/Tools_and_testing/Understanding_client-side_tools/Overview","Learn/Tools_and_testing/Understanding_client-side_tools/Package_management", "Learn/Tools_and_testing/Understanding_client-side_tools")}}

+ +

Dans ce module

+ + diff --git a/files/fr/learn/tools_and_testing/understanding_client-side_tools/ligne_de_commande/index.html b/files/fr/learn/tools_and_testing/understanding_client-side_tools/ligne_de_commande/index.html deleted file mode 100644 index 74d503b7d4..0000000000 --- a/files/fr/learn/tools_and_testing/understanding_client-side_tools/ligne_de_commande/index.html +++ /dev/null @@ -1,487 +0,0 @@ ---- -title: Cours express sur la ligne de commande -slug: Learn/Tools_and_testing/Understanding_client-side_tools/Ligne_de_commande -tags: - - CLI - - Côté client - - Débutant - - Outils - - Terminal - - ligne de commande - - npm -translation_of: Learn/Tools_and_testing/Understanding_client-side_tools/Command_line ---- -
{{LearnSidebar}}
- -
{{PreviousMenuNext("Learn/Tools_and_testing/Understanding_client-side_tools/Overview","Learn/Tools_and_testing/Understanding_client-side_tools/Package_management", "Learn/Tools_and_testing/Understanding_client-side_tools")}}
- -

Au cours de tout process de développement, vous allez très certainement être confronté à la nécessité d'exécuter des commandes dans un terminal (ce que l'on appelle "travailler en ligne de commande"). Cet article vous propose une introduction au terminal et vous dévoile les commandes essentielles dont vous aurez besoin, la façon de les chaîner, et comment ajouter vos propres outils d'interface en ligne de commande (CLI, command line interface).

- - - - - - - - - - - - -
Prérequis : -

Être familiarisé avec les bases des langages

- HTML, CSS, et JavaScript.
Objectif : -

Comprendre ce qu'est la ligne de commande, savoir quelles sont les commandes de base que vous devriez connaître, et comment installer de nouveaux outils de ligne de commande.

-
- -

Bienvenue sur le terminal

- -

Le terminal est une interface de texte pour l'exécution de programmes qui utilisent un langage lui-même textuel . Quel que soit le type d'outils que vous allez utiliser pour le développement web, il y a de grandes chances que vous soyez amené à travailler en ligne de commande pour les utiliser (vous rencontrerez aussi l'appellation "console" ou encore "CLI tools" pour désigner de tels outils d'interface en ligne de commande).

- -

Il existe de nombreux outils pour travailler en ligne de commande ; certains sont pré-installés sur votre système, et une infinité d'autres sont disponibles sur des dépôts de "paquets" (packages). Ces dépôts sont un peu comme des magasins spécialisés (pour la plupart) dans les outils de ligne de commande et les logiciels. Nous allons voir un peu plus loin dans ce chapitre comment installer certains de ces outils, et nous en apprendrons plus sur les dépôts de paquets dans le prochain chapitre.

- -

L'une des critiques les plus fréquentes envers la ligne de commande, c'est que l'utilisateur courant n'en a pratiquement aucune expérience. Se retrouver devant un terminal pour la première fois peut être vraiment intimidant : un écran vide, un curseur qui clignote, et rien ou presque pour vous aider à en tirer quelque chose.

- -

Malgré cette apparence rebutante, le terminal est pourtant un outil puissant, et nous pouvons vous promettre qu'avec une petite formation et un peu de pratique, son utilisation vous deviendra bien plus facile ! C'est la raison pour laquelle nous vous proposons ce chapitre - pour vous aider à démarrer dans cet environnement apparemment inhospitalier.

- -

.

- -

Quelle est l'origine du terminal ?

- -

Elle se situe dans les années 50-60, et son aspect d'alors ne ressemble pas du tout à ce que nous connaissons aujourd'hui (heureusement). Vous pouvez en apprendre davantage sur la page de Wikipédia Terminal (informatique).

- -

Depuis, le terminal est resté un élément constant de tout système d'exploitation - des ordinateurs de bureau aux serveurs du cloud (qui n'est pas vraiment un nuage) en passant par les micro-cartes comme la Raspberry PI Zero et même les téléphones mobiles. Il offre un accès direct au système de fichiers de l'ordinateur et à des fonctionnalités de bas niveau, ce qui le rend incroyablement apte à accomplir rapidement des tâches complexes, à condition de savoir ce que vous faites.

- -

Il est également utile pour automatiser certaines tâches, comme par exemple modifier les titres de centaines de fichiers instantanément - par exemple changer tous les "ch01-xxxx.png" en "ch02-xxxx.png", ce qui vous prendrait un temps considérable si vous deviez le faire à la main dans la fenêtre d'un gestionnaire de fichiers.

- -

En tous cas, le terminal ne va pas disparaître de si tôt.

- -

À quoi ressemble un terminal ?

- -

Vous pouvez voir ci-dessous les apparences de quelques terminaux émulés par des programmes courants.

- -

Les images suivantes montrent les invites de commande disponibles sous Windows – il y a une panoplie d’options, du programme « cmd » au « powershell » - qui peuvent être lancées depuis le menu de démarrage en tapant le nom du programme.

- -

A vanilla windows cmd line window, and a windows powershell window

- -

Et ci-dessous, vous pouvez voir l’application de terminal pour macOS.

- -

A basic vanilla mac terminal

- -

Comment ouvrir un terminal ?

- -

Beaucoup de développeurs se servent aujourd'hui de terminaux de type Unix (c'est-à-dire le terminal en lui-même plus les outils auxquels il donne accès). Beaucoup de tutoriels sur le web sont basés sur ces terminaux Unix qu'ils considèrent (malheureusement) comme universels, mais nous allons voir dans cette section comment ouvrir un terminal sur le système de votre choix.

- -

Linux/Unix

- -

Comme indiqué plus haut, les systèmes Linux/Unix disposent d'un terminal par défaut, présent dans vos Applications.

- -

macOS

- -

macOS a un système nommé Darwin qui réside sous l'interface graphique. Darwin est un système de type Unix, qui fournit le terminal, et l'accès aux outils de bas niveau. Darwin est dans l'ensemble assez proche d'Unix pour ne pas nous causer trop de problèmes lors de notre progression dans cet article.

- -

Ce terminal est disponible sur macOS dans Applications/Utilitaires/Terminal.

- -

Windows

- -

Comme pour d'autres outils de programmation, c’est un peu une tradition pour Windows de ne pas faciliter l’utilisation du terminal (ou ligne de commande) par rapport à d’autres systèmes d’exploitation. Mais les choses s’améliorent.

- -

Traditionnellement aussi, Windows a depuis longtemps eu son propre programme de type « terminal », appelé « cmd » (« l’invite de commande »), mais celui-ci n’est en rien comparable aux commandes Unix, et il est en fait équivalent au programme DOS des temps héroïques.

- -

On trouve malgré tout de meilleurs programmes qui offrent une expérience de terminal sur Windows, tels que Powershell (voir ici pour l’installer), et Gitbash (qui fait partie de la trousse à outils git for Windows).

- -

Quoi qu’il en soit, aujourd’hui, la meilleure option est le « Windows Subsystem for Linux » (WSL) – une couche de compatibilité qui permet de lancer des systèmes d’exploitation Linux directement dans Windows 10, ce qui vous permet d’avoir un « vrai terminal », sans recourir à une machine virtuelle.

- -

Vous pouvez l’installer gratuitement directement à partir du Windows store. Toute la documentation utile est disponible dans la Windows Subsystem for Linux Documentation .

- -

a screenshot of the windows subsystem for linux documentation

- -

Si vous vous demandez quelle option choisir sur Windows, nous vous recommandons vivement de vous décider pour le WSL. Vous pourriez certes vous en tenir à l’invite de commande par défaut (« cmd »), et faire tourner pas mal d’outils correctement, mais tout sera bien plus facile si vous avez une meilleure équivalence avec les outils Unix.

- -

En passant, quelle est la différence entre ligne de commande et terminal ?

- -

En général, vous rencontrerez ces deux termes utilisés de façon interchangeable. Techniquement, un terminal (ou console) est un logiciel qui se connecte à un shell au démarrage. Un shell correspond à votre session et à votre environnement de session (où des choses comme l’invite de commande et les raccourcis peuvent être personnalisés). La ligne de commande quant à elle (ou prompt) est la ligne de texte où vous entrez des commandes et où le curseur clignote.

- -

Est-ce qu'il faut se servir du terminal?

- -

Bien que les outils disponibles à partir de la ligne de commande soient très riches, si vous utilisez des outils tels que Visual Studio Code vous allez avoir accès à une quantité d’extensions que vous pourrez utiliser pour vous aider dans l’édition et vous allez pouvoir vous passer presque complètement du terminal lui-même. Cependant, vous ne pourrez pas trouver une extension sur votre éditeur de code pour tout ce que vous voudrez faire – en définitive, vous devrez malgré tout vous confronter au terminal.

- -

Les commandes intégrées de base

- -

Assez parlé — voyons maintenant quelques commandes utilisables dans un terminal ! Voici, clés en main, un petit aperçu de tout ce que l'on peut faire en ligne de commande, avec la référence des outils pertinents dans chaque cas :

- - - -
-

Note : On trouve  sur le web un bon nombre de tutoriels de qualité qui permettent d'aller beaucoup plus loin avec la ligne de commande — ceci n'est qu'une brève introduction ! L'auteur de ces lignes lui-même a sa propre série de vidéos de formation au terminal (80% de réduction en utilisant le code mdn au moment du paiement — 19$).

-
- -

Pour aller plus loin, voyons maintenant comment utiliser quelques-uns de ces outils en ligne de commande. Commencez par ouvrir votre programme de terminal (ou console) !

- - - -

Lorsque vous vous mettez sur la ligne de commande, vous allez inévitablement devoir naviguer vers un répertoire spécifique pour y "faire quelque chose". Tous les systèmes d'exploitation (du moins avec un paramétrage par défaut) démarrent leur terminal dans votre répertoire d'utilisateur, et il y a des chances pour que vous souhaitiez vous rendre de là à un autre emplacement.

- -

La commande cd vous permet de changer de répertoire (Change Directory). Techniquement, cd n'est pas un programme mais une commande intégrée. Cela signifie que votre système d'exploitation la fournit de façon native, et aussi que vous ne pouvez pas l'effacer accidentellement - bonne nouvelle ! Cela dit, vous n'avez pas besoin de vous soucier de savoir si une commande est intégrée ou non, mais vous pouvez garder à l'esprit que les commandes intégrées sont présentes sur les systèmes basés sur Unix.

- -

Pour changer de répertoire, vous tapez cd dans votre terminal, suivi par le répertoire dans lequel vous voulez vous rendre. En supposant que le répertoire (ou dossier) Desktop se trouve dans votre répertoire utilisateur, vous allez donc taper cd Desktop (voir les copies d'écran ci-dessous).

- -

results of the cd Desktop command being run in a variety of windows terminals - the terminal location moves into the desktop

- -

Sur un système en langue française, vous trouverez plus fréquemment "Bureau" plutôt que "Desktop". Essayez de taper ceci dans votre terminal système (sur un système en langue anglaise, bien sûr conservez "Desktop") :

- -
cd Bureau
- -

Si vous voulez revenir au répertoire précédent, utilisez les deux points :

- -
cd ..
- -
-

Note: Raccourci vraiment utile sur un terminal, la touche tab émule la saisie automatique des mots dont vous connaissez l'existence, ce qui vous évite de les taper en entier. Par exemple, après avoir tapé les deux commandes ci-dessus, essayez de taper cd B puis de presser la touche tab — cela devrait saisir automatiquement le nom de répertoire Bureau, à condition qu'il soit présent dans le répertoire courant. Gardez ceci à l'esprit tout en poursuivant.

-
- -

Si le répertoire que vous visez est placé assez loin dans l'arborisation des fichiers, il vous faut connaître le chemin (on dit souvent path, qui est le terme anglais) pour vous y rendre. Cela devient en général plus facile à mesure que vous vous familiarisez avec la structure de votre système de fichiers, mais si vous n'êtes pas sûr vous pouvez le retrouver en combinant la commande ls avec des clicks dans votre Explorer ou autre gestionnaire graphique de fichiers, ce qui va vous permettre de voir où se trouve le répertoire (ou dossier) cherché par rapport à votre répertoire actuel (= répertoire courant).

- -

Par exemple, si vous vouliez aller dans un dossier nommé src, qui se trouve dans un dossier nommé projet, qui est lui-même sur le Bureau, vous pourriez taper ces trois commandes pour y arriver à partir de votre dossier utilisateur :

- -
cd Bureau
-cd projet
-cd src
- -

Mais c'est une perte de temps — à la place, vous pouvez taper une seule commande, avec les différents éléments du chemin séparés par des slashes, exactement de la même manière que lorsque vous spécifiez les chemins d'accès à des images ou autres assets en CSS, HTML, ou JavaScript :

- -
cd Bureau/projet/src
- -

Notez que si vous commencez le chemin par un slash, vous le rendez absolu, par exemple /Utilisateurs/votre-nom/Bureau. Omettre le premier slash comme nous l'avons fait ci-dessus construit un chemin relatif à votre répertoire de travail actuel. C'est exactement la même chose qu'une URL dans un navigateur. Un slash au début signifie "à la racine du site web", alors qu'omettre le slash signifie "l'URL est relative à ma page courante".

- -
-

Note: Sur windows vous devez utiliser des backslashes et non des slashes, p. ex. cd Bureau\projet\src — cela peut vous paraître vraiment étrange, mais si la question vous intéresse, regardez cette vidéo YouTube (en anglais) qui présente une explication par l'un des ingénieurs principaux de Microsoft.

-
- -

Lister le contenu d'un répertoire

- -

ls (de l'anglais list) est la commande intégrée Unix qui va vous permettre de lister le contenu du répertoire dans lequel vous vous trouvez. Notez que cela ne fonctionnera pas avec l'invite de commande par défaut de Windows (cmd) — la commande équivalente est dir.

- -

Essayez de taper ceci dans votre terminal :

- -
ls
- -

Vous obtenez la liste des fichiers et répertoires de votre répertoire de travail courant, mais l'information est vraiment basique - vous n'avez que les noms des items, sans savoir s'il s'agit d'un fichier, d'un répertoire, ou d'autre chose. Heureusement, une petite modification dans l'utilisation de la commande va vous donner beaucoup plus d'informations.

- -

Présentation des options de commandes

- -

La plupart des commandes de terminal possèdent des options - ce sont des modificateurs que vous ajoutez à la fin d'une commande pour obtenir un comportement légèrement différent. Il s'agit en général d'un espace suivi d'un tiret puis d'une ou de plusieurs lettres.

- -

Voyez par exemple ce que vous obtenez en essayant ceci :

- -
ls -l 
- -

Avec ls, l'option -l (tiret l, "dash ell" en anglais) vous donne une liste avec un fichier ou répertoire par ligne et pas mal d'autres informations. Les répertoires ("directories") sont repérés pas la lettre "d" au tout début de la ligne. Nous pouvons y entrer avec la commande cd.

- -

Voici ci-dessous une copie d'écran avec un terminal macOS “vanilla” en haut, et en bas un terminal personnalisé avec quelques icônes supplémentaires et des couleurs pour le rendre plus vivant — les deux affichent le résultat de la commande ls -l :

- -

A vanilla mac terminal and a more colorful custom mac terminal, showing a file listing - the result of running the ls -l command

- -
-

Note: Pour savoir exactement quelles sont les options d'une commande, vous pouvez consulter sa page de manuel (man page en anglais). Pour cela, tapez la commande man suivie du nom de la commande que vous cherchez, par exemple man ls. La page de manuel va s'ouvrir dans le lecteur de texte par défaut de votre terminal (par exemple, less sur mon terminal), et vous allez pouvoir faire défiler la page avec les touches de flèches ou un mécanisme similaire. La page de manuel liste toutes les options de façon très détaillée, ce qui peut être un peu intimidant au début, mais au moins vous savez où les trouver si vous en avez besoin. Lorsque vous avez terminé avec la page de manuel, vous la refermez avec la commande "quitter" de votre visionneur de texte (pour less c'est "q" ; si ce n'est pas évident cherchez sur Internet).

-
- -
-

Note: Pour lancer une commande avec des options multiples, on peut en général les regrouper dans une seule chaîne de caractères après le tiret, par exemple ls -lah, ou ls -ltrh. Exercez-vous à consulter la page man de ls pour savoir ce que vous donnent ces options !

-
- -

Maintenant que vous connaissez ces deux commandes fondamentales, allez un peu fouiller dans votre système de fichiers en naviguant à partir de votre répertoire.

- -

Créer, copier, déplacer, supprimer

- -

Il y existe un certain nombre d'autres commandes d'utilité basique dont vous allez probablement pas mal vous servir en travaillant sur un terminal. Elles sont assez simples, aussi nous n'allons pas les expliquer avec autant de détails que les deux précédentes.

- -

Jouez avec elles dans un répertoire que vous aurez créé quelque part de façon à ne pas effacer accidentellement quoi que ce soit d'important, en vous servant des exemples donnés pour vous guider :

- - - -
-

Note : Beaucoup de commandes de terminal autorisent l'emploi d'astérisques comme caractère "joker", dont le sens est "une séquence de caractères quelconque". Cela vous permet d'exécuter une commande en une seule fois sur un nombre potentiellement important de fichiers qui correspondent au modèle donné. À titre d'exemple, rm mdn-* va effacer tous les fichiers qui commencent par mdn-. rm mdn-*.bak va effacer tous les fichiers qui commencent par mdn- et finissent par .bak.

-
- -

Le terminal — une pratique à risque ?

- -

Nous y avons déjà fait allusion, et soyons clairs - travailler sur terminal demande de la prudence. Des commandes simples ne présentent pas trop de risques, mais dès que vous commencez à combiner des commandes plus complexes, il vous faut réfléchir soigneusement à ce qu'elle va exécuter, et essayer de la tester avant de la lancer effectivement dans le répertoire voulu.

- -

Supposons que vous ayez 1000 fichiers texte dans un répertoire, et que vous vouliez les parcourir en supprimant uniquement ceux dont le nom comprend une certaine chaîne de caractères. Si vous ne faites pas attention, vous risquez d'effacer quelque chose d'important et de perdre du coup une somme de travail. Une bonne habitude à prendre consiste à écrire votre ligne de commande dans un éditeur de texte, à la construire à votre idée, et ensuite à faire une copie de sauvegarde de votre répertoire avant d'essayer la commande sur celui-ci.

- -

Autre astuce intéressante : si vous n'êtes pas à l'aise avec l'idée d'essayer des lignes de commande sur votre propre machine, le site Glitch.com est un bon endroit pour le faire en toute sécurité. En plus d'être un lieu génial pour tester du code de développement web, les projets vous donnent accès à un terminal qui vous permet de lancer toutes les commandes que vous voulez, sans risquer d'endommager votre propre machine.

- -

a double screenshot showing the glitch.com home page, and the glitch terminal emulator

- -

Le site tldr.sh est une formidable ressource pour obtenir un aperçu de commandes particulières. C'est un service de documentation géré de façon communautaire, similaire à MDN, mais dédié aux commandes de terminal.

- -

Dans la section suivante, nous allons monter d'un cran (et même de plusieurs), et voir comment nous pouvons combiner plusieurs outils en ligne de commande pour révéler toute la puissance du terminal par rapport à l'interface graphique habituelle.

- -

Combiner des commandes grâce aux "pipes"

- -

L'usage du terminal prend toute sa valeur lorsque vous commencez à chaîner les commandes en utilisant le symbole | ("pipe" ou "tuyau" en français). Voyons comment on peut faire cela sur un exemple très rapide.

- -

Nous avons déjà vu ls, qui liste le contenu du répertoire courant :

- -
ls
- -

Mais comment nous y prendre si nous voulons compter le nombre de fichiers et de répertoires à l'intérieur du répertoire courant ? ls n'est pas capable de faire cela à lui seul.

- -

Il existe un autre outil Unix nommé wc. Celui-ci compte les mots, lignes, caractères, ou octets de la donnée qu'on lui passe, quelle qu'elle soit. Il peut s'agir d'un fichier texte — l'exemple ci-dessous donne le nombre de lignes de monfichier.txt :

- -
wc -l monfichier.txt
- -

Mais wc est également capable de compter les lignes de tout ce qui lui est passé par un pipe. Par exemple, la commande ci-dessous compte les lignes renvoyées par la commande ls  (lignes qui seraient normalement affichées sur le terminal) et affiche ce décompte à la place :

- -
ls | wc -l
- -

Comme ls affiche chaque fichier ou répertoire sur une nouvelle ligne, on obtient bien le compte des répertoires et des fichiers.

- -

Comment ça marche ? Le comportement général des outils de ligne de commande (unix) consiste à afficher du texte dans le terminal (ce qu'on appelle aussi "imprimer sur la sortie standard (standard input)" ou  STDOUT). Un bon nombre de commandes peuvent aussi lire du contenu à partir d'un flux d'entrée (appelé "entrée standard (standard input)" ou STDIN).

- -

L'opérateur pipe peut connecter ces entrées et sorties, ce qui nous permet de construire des opérations de plus en plus complexes selon nos besoins — la sortie d'une commande devient l'entrée de la commande suivante. Dans le cas présent, ls enverrait normalement sa sortie sur STDOUT, mais au lieu de cela la sortie de ls est passée par un pipe à wc, qui la prend en entrée, compte ses lignes et imprime ce décompte sur STDOUT.

- -

Un exemple un peu plus complexe

- -

Occupons-nous maintenant de quelque chose d'un peu plus compliqué. Nous allons d'abord essayer de récupérer le contenu de la page MDN "fetch" en utilisant la commande curl  (dont on peut se servir pour faire une requête de contenu à partir d'URLs), sur https://developer.mozilla.org/en-US/docs/Web/API/fetch.

- -

En fait, cette URL est celle de l'ancien emplacement de la page. Lorsque vous l'entrez dans un nouvel onglet de votre navigateur, vous êtes (finalement) redirigé sur https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch.

- -

Par conséquent, si vous utilisez curl pour faire une requête à https://developer.mozilla.org/docs/Web/API/fetch, vous n'aurez pas de résultat. Essayez :

- -
curl https://developer.mozilla.org/en-US/docs/Web/API/fetch
- -

Nous devons dire explicitement à curl de suivre les redirections en utilisant l'option -L.

- -

Examinons également les en-têtes retournées par developer.mozilla.org en utilisant l'option -I de curl, et affichons toutes les redirections en passant la sortie de curl à grep grâce à un pipe (on va demander à grep de renvoyer toutes les lignes qui contiennent le mot "location").

- -

Essayez maintenant la ligne suivante, et vous allez constater qu'il y a en fait trois redirections avant d'atteindre la page finale :

- -
curl https://developer.mozilla.org/docs/Web/API/fetch -L -I | grep location
- -

Votre sortie devrait ressembler à ceci (curl va d'abord afficher des compteurs et autres informations de téléchargement) :

- -
location: /en-US/docs/Web/API/fetch
-location: /en-US/docs/Web/API/GlobalFetch/GlobalFetch.fetch()
-location: /en-US/docs/Web/API/GlobalFetch/fetch
-location: /en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch
- -

Bien que ce résultat soit artificiel, nous pourrions le pousser un peu plus loin et remplacer location: par le nom de domaine, de façon à avoir des URLs complètes. Pour cela, nous allons ajouter awk à notre formule (il s'agit d'un langage de programmation tout comme JavaScript, Ruby ou Python, mais beaucoup plus ancien !).

- -

Essayez de lancer cette commande :

- -
curl https://developer.mozilla.org/docs/Web/API/fetch -L -I | grep location | awk '{ print "https://developer.mozilla.org" $2 }'
- -

Votre sortie finale devrait ressembler à ceci :

- -
https://developer.mozilla.org/en-US/docs/Web/API/fetch
-https://developer.mozilla.org/en-US/docs/Web/API/GlobalFetch/GlobalFetch.fetch()
-https://developer.mozilla.org/en-US/docs/Web/API/GlobalFetch/fetch
-https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch
- -

En combinant ces commandes nous avons personnalisé la sortie pour qu'elle montre les URLs complètes vers lesquels le serveur de Mozilla effectue les redirections lorsque nous lui soumettons la requête pour l'URL /docs/Web/API/fetch.
- Développer votre connaissance du système en apprenant le fonctionnement de ces simples outils et comment les intégrer à votre arsenal pour résoudre des problèmes bien particuliers - cela vous sera d'une grande utilité tout au long des années à venir.

- -

Ajoutez des super-pouvoirs !

- -

À présent que nous avons jeté un œil à quelques-unes des commandes intégrées dont votre système est pré-équipé, voyons comment installer un outil tiers de CLI et nous en servir.

- -

La plus grande partie du vaste écosystème d'outils installables pour le développement web front-end se trouve sous npm, un service privé d'hébergement de packages qui fonctionne en étroite interaction avec Node.js. Celui-ci se développe peu à peu — vous pouvez vous attendre à davantage de fournisseurs de packages avec le temps.

- -

L'installation de Node.js installe en même temps l'outil de ligne de commande npm (ainsi que npx, un outil supplémentaire centré sur npm), qui est la porte d'entrée pour l'installation d'outils de ligne de commande additionnels. Node.js et npm fonctionnent de la même façon sur tous les systèmes : macOS, Windows, ainsi que Linux.

- -

Allons-y : installez npm sur votre système à partir de l'URL ci-dessus qui va vous permettre de télécharger et de lancer un installeur Node.js approprié à votre système d'exploitation. Si cela vous est proposé, assurez-vous d'inclure npm dans l'installation.

- -

the node.js installer on windows, showing the option to include npm

- -

Un certain nombre d'outils variés vous attendent dans le prochaine article ; pour l'instant nous allons nous faire la main sur Prettier. Prettier est un outil de formatage de code normatif qui se présente comme ayant "peu d'options". Moins d'options, cela évoque plus de simplicité. Vu comme on peut parfois être débordé par la complexité de certains outils, le concept  "peu d'options" peut se révéler très attractif.

- -

Où installer nos outils de CLI ?

- -

Avant de nous lancer dans l'installation de Prettier, une question se pose — "où allons-nous l'installer ?"

- -

npm nous donne le choix entre une installation globale — ce qui nous permet d'y avoir accès de n'importe où — ou bien locale, dans le dossier du projet en cours.

- -

Il y a des pour et des contre pour les deux options — la liste ci-dessous est loin d'être exhaustive:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Pour l'installation globaleContre l'installation globale
Accessible partout dans votre terminalPeut ne pas être compatible avec votre codebase.
Installation en une foisLes autres développeurs de votre équipe n'auront pas accès à ces outils, par exemple si vous partagez votre codebase sur un outil comme git.
Moins d'espace disqueEn lien avec le point précédent, rend le code du projet plus difficile à répliquer (si vous installez vos outils en local, ils peuvent être configurés comme des dépendances et installés avec npm install).
Stabilité de la version
Donne l'impression d'être une commande unix comme les autres
- -

Bien que la liste des contre soit plus courte, l'impact négatif d'une installation globale est potentiellement beaucoup plus lourd que les bénéfices. Cela dit, pour l'instant, nous allons choisir l'installation globale dans un but de simplicité. Nous examinerons davantage les installations locales et leur intérêt dans notre prochain article.

- -

Installation de Prettier

- -

Dans cette partie nous allons installer Prettier en tant qu'utilitaire global de ligne de commande.

- -

Prettier est un outil de formatage de code normatif pour les développeurs front-end, centré sur le langage JavaScript et ses dérivés, avec un support pour HTML, CSS, SCSS, JSON et plus.

- -

Prettier offre les avantages suivants :

- - - -

Après avoir installé node, ouvrez votre terminal et lancez les commandes suivantes pour installer Prettier :

- -
npm install --global prettier
- -

Lorsque la commande a terminé son exécution, l'outil Prettier est disponible sur sur votre terminal, partout dans votre système de fichiers.

- -

En lançant la commande sans argument, comme pour beaucoup d'autres commandes, vous obtiendrez les informations d'utilisation et d'aide. Essayez :

- -
prettier
- -

La sortie devrait ressembler à ceci :

- -
Usage: prettier [options] [file/glob ...]
-
-By default, output is written to stdout.
-Stdin is read if it is piped to Prettier and no files are given.
-
-…
- -

Cela vaut toujours la peine d'au moins survoler les informations sur l'utilisation, même lorsqu'elles sont longues. Vous pourrez ainsi mieux comprendre à quoi l'outil est censé servir.

- -

Un peu de pratique

- -

Jouons un peu avec Prettier pour que vous puissiez voir comment il fonctionne.

- -

Tout d'abord, créez un nouveau répertoire à un endroit que vous pourrez retrouver facilement, par exemple un répertoire nommé prettier-test sur votre Bureau.

- -

Ensuite collez le code suivant dans un fichier que vous enregistrez dans ce répertoire sous le nom index.js.

- -
const myObj = {
-a:1,b:{c:2}}
-function printMe(obj){console.log(obj.b.c)}
-printMe(myObj)
- -

Nous pouvons exécuter prettier sur un code source simplement pour vérifier s'il nécessite une correction. Passez dans votre répertoire avec cd et essayez de lancer cette commande :

- -
prettier --check index.js
- -

Vous devriez obtenir quelque chose comme

- -
Checking formatting...
-index.js
-Code style issues found in the above file(s). Forgot to run Prettier?
-
- -

Le style nécessite donc des corrections. Pas de problème. On va les appliquer en ajoutant l'option --write à la commande prettier, ce qui nous laisse nous concentrer sur l'aspect utile de l'écriture du code.

- -

Essayez maintenant de lancer cette version de la commande :

- -
prettier --write index.js
- -

La sortie ressemble maintenant à ceci

- -
Checking formatting...
-index.js
-Code style issues fixed in the above file(s).
- -

Mais le plus important, c'est que votre fichier JavaScript a été reformaté :

- -
const myObj = {
-  a: 1,
-  b: { c: 2 },
-};
-function printMe(obj) {
-  console.log(obj.b.c);
-}
-printMe(myObj);
- -

Vous pouvez intégrer cette opération automatisée à votre workflow. L'intérêt des outils réside justement dans l'automatisation ; personnellement, notre préférence va  au type d'automatisme qui se produit de façon transparente, sans qu'aucune configuration soit nécessaire.

- -

Il existe de nombreuses façons de mettre en oeuvre des automatismes avec Prettier, et bien qu'elles dépassent le cadre de cet article, vous trouverez de l'aide dans d'excellentes ressources en ligne, dont certaines grâce aux liens ci-après. Vous pouvez lancer prettier :

- - - -

Nous préférons personnellement la deuxième solution — quand on code par exemple sur VS Code, Prettier entre en jeu et nettoie le formatage lors de chaque  enregistrement. Vous trouverez dans les Prettier docs beaucoup plus d'informations sur les différentes façons d'utiliser Prettier.

- -

Autres outils à essayer

- -

Voici une courte liste de quelques outils supplémentaires que vous pouvez vous amuser à tester :

- - - -

L'auteur a aussi décrit certains de ses favoris accompagnés de copies d'écrans si vous avez envie de creuser davantage le sujet.

- -

Notez que certains de ces outils nécessitent l'installation préalable de npm, ainsi que nous l'avons fait pour Prettier.

- -

Résumé

- -

Nous voilà parvenus au terme de cette brève revue du terminal ou ligne de commande. Dans la suite, nous allons nous pencher plus en détail sur les package managers, et sur les possibilités qu'ils nous offrent.

- -

{{PreviousMenuNext("Learn/Tools_and_testing/Understanding_client-side_tools/Overview","Learn/Tools_and_testing/Understanding_client-side_tools/Package_management", "Learn/Tools_and_testing/Understanding_client-side_tools")}}

- -

Dans ce module

- - -- cgit v1.2.3-54-g00ecf