Pourquoi est-ce une mauvaise pratique d'utiliser des liens avec le javascript : "protocole" ?

Question

Dans les années 1990, la mode était de mettre le code Javascript directement dans <a> attributs href, comme ceci :

<a href="javascript:alert('Hello world!')">Press me!</a>

Et puis soudain, je me suis arrêté pour le voir. Ils ont tous été remplacés par des choses comme :

<a href="#" onclick="alert('Hello world!')">Press me!</a>

Pour un lien dont l'unique but est de déclencher du code Javascript, et qui n'a pas de réel href pourquoi est-il encouragé d'utiliser le onclick au lieu de la propriété href la propriété ?

Answer 1

Le contexte d'exécution est différent, pour le voir, essayez plutôt ces liens :

<a href="javascript:alert(this.tagName)">Press me!</a> <!-- result: undefined -->
<a href="#" onclick="alert(this.tagName)">Press me!</a> <!-- result: A -->

javascript: est exécuté dans le contexte global, et non comme une méthode de l'élément, ce qui est généralement ce que vous voulez. Dans la plupart des cas, vous faites quelque chose avec ou en relation avec l'élément sur lequel vous avez agi, mieux vaut l'exécuter dans ce contexte.

De plus, c'est beaucoup plus propre, même si je n'utiliserais pas du tout le script en ligne. Regardez n'importe quel framework pour gérer ces choses d'une manière beaucoup plus propre. Exemple dans jQuery :

$('a').click(function() { alert(this.tagName); });

Answer 2

En fait, les deux méthodes sont considérées comme obsolètes. Les développeurs sont plutôt encouragés à séparer tout le JavaScript dans un fichier JS externe afin de séparer la logique et le code du véritable balisage.

• http://www.alistapart.com/articles/behavioralseparation
• http://en.wikipedia.org/wiki/Unobtrusive_JavaScript

La raison en est que cela crée un code plus facile à maintenir et à déboguer, et que cela favorise également les normes et l'accessibilité du Web. Pensez-y de la manière suivante : Si vous reprenez votre exemple, que se passerait-il si vous aviez des centaines de liens de ce type sur une page et que vous deviez modifier le code de l'élément alert pour une autre fonction utilisant des références JS externes, il suffirait de modifier une seule liaison d'événement dans un fichier JS, au lieu de copier et coller un tas de code à plusieurs reprises ou de procéder à une recherche et un remplacement.

Answer 3

Pour plusieurs raisons :

1. Mauvaise pratique du code :
   La balise HREF sert à indiquer qu'il existe un lien hypertexte vers un autre emplacement. Utiliser la même balise pour une fonction javascript qui n'emmène pas l'utilisateur quelque part est une mauvaise pratique de programmation.

2. Problèmes de référencement :
   Je pense que les robots d'exploration utilisent la balise HREF pour parcourir le site Web et relier toutes les parties connectées. En mettant du javascript, on casse cette fonctionnalité.

3. Brise l'accessibilité :
   Je pense que certains lecteurs d'écran ne seront pas en mesure d'exécuter le javascript et ne sauront peut-être pas comment traiter le javascript alors qu'ils attendent un hyperlien. L'utilisateur s'attendra à voir un lien dans la barre d'état du navigateur au survol du lien alors qu'il verra une chaîne comme : "javascript :", ce qui pourrait le perturber, etc.

4. Vous êtes encore dans les années 1990 :
   Le conseil le plus courant est de placer votre javascript dans un fichier séparé et de ne pas le mélanger avec le HTML de la page comme cela se faisait dans les années 1990.

HTH.

Answer 4

J'ouvre des tas de liens dans de nouveaux onglets - pour ne voir que javascript:void(). Vous m'ennuyez donc, ainsi que vous-même (car Google verra la même chose).

Une autre raison (également mentionnée par d'autres) est que les différentes langues devraient être séparées dans des documents différents. Pourquoi ? Eh bien,

• Les langages mixtes ne sont pas bien supportés par la plupart des IDE et des validateurs. Intégrer des CSS et des JS dans des pages HTML (ou n'importe quoi d'autre d'ailleurs) détruit à peu près toutes les possibilités de de faire vérifier l'exactitude du langage incorporé de manière statique. Parfois, le langage embarqué aussi. (Un document PHP ou ASP n'est pas du HTML valide). Vous ne voulez pas que des erreurs de syntaxe syntaxe ou des incohérences n'apparaissent qu'au moment de l'exécution.
• Une autre raison est d'avoir une séparation plus nette entre les types de choses que vous devez spécifier : HTML pour le contenu, CSS pour la mise en page, JS généralement pour plus de mise en page et l'aspect et la convivialité. Ces éléments ne correspondent pas une à une : vous voulez généralement appliquer la mise en page à l'ensemble catégories de éléments de contenu (d'où CSS) et de l'aspect et de la convivialité (d'où jQuery). (d'où jQuery). Ils peuvent être modifiés à des moments différents que les éléments de contenu (en fait, le contenu est souvent généré à la volée). le contenu est souvent généré à la volée) et par différentes personnes. différentes personnes. Il est donc logique de les conserver dans documents séparés.

Answer 5

Réponse courte : Le Javascript en ligne est mauvais pour les mêmes raisons que le CSS en ligne.