Pourquoi est-il une mauvaise pratique de l'utilisation des liens avec le javascript: “protocole”?

Dans les années 1990, il y avait une façon de mettre du code Javascript directement dans <a> href attributs, comme ceci:

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

Et puis tout à coup, j'ai arrêté de 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 le seul but est de déclencher un code Javascript, et n'a pas de réel href cible, pourquoi est-il encouragé à utiliser les onclick de la propriété au lieu de la href propriété?

  • il n'est pas obsolète.. juste une mauvaise pratique.. comme c'est à l'aide de l'attribut onclick .. recherche pour unobtrusive javascript et progressive enhancement pour les meilleures pratiques.
  • quelle est la différence entre une "mauvaise pratique" et "obsolète", alors?
  • obsolète signifie que ces caractéristiques sont susceptibles de ne pas être pris en charge dans l'avenir..
  • bon alors, fixe le titre.
  • Je dirais même envisager la mauvaise habitude (ou de la pratique?) pour utiliser un <a> balise pour prétendre que c'est un lien vers une page, quand il est seulement un "déclencheur pour JS action" vraiment. Je voudrais examiner à l'aide de <span class="js-trigger">Press me</span> & découpler pertinentes du code javascript en le mettant à l'intérieur d'un distinct fichier JS.
InformationsquelleAutor zneak | 2010-03-19
  1. 51

    Le contexte d'exécution est différente, pour voir cela, essayez ces liens à la place:

    <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ée dans le contexte global, et non pas comme une méthode de l'élément, qui est généralement ce que vous voulez. Dans la plupart des cas, vous êtes en train de faire quelque chose avec ou par rapport à l'élément que vous avez agi sur, mieux à exécuter dans ce contexte.

    Aussi, c'est juste beaucoup plus propre, mais je ne voudrais pas utiliser de script en ligne à tous. Découvrez tous les cadres de la manipulation de ces choses dans une beaucoup plus propre chemin. Exemple en jQuery:

    $('a').click(function() { alert(this.tagName); });
    • juste une clarification rapide lorsque vous appelez javascript:ce à partir de l'attribut href, c'est une référence à la fenêtre de l'objet DOM.
    • Merci pour expliquer la différence suggérant une meilleure façon.
    • Je trouve intéressant que l'accent de la réponse que la communauté des faveurs - et qui a été sélectionné - met l'accent sur les inconvénients que l'utilisation de la javascript: protocole crée pour le développeur, par opposition à son impact sur la qualité des livrables... me fait penser à l'ascenseur de test; codinghorror.com/blog/2007/09/...
    • Cela a aussi l'avantage d'être dans un externes et des fichiers mis en cache, pas téléchargé en tant que partie de la page à chaque tour...je dirais pour de nombreuses raisons, il est préférable, tant pour la qualité et la commodité pour le développeur.
    • Craver - c'est vrai... j'étais songeur tout autant sur le phrasé que le contenu; il se sent à moi comme ça se présente comme une note de bas de page/après-coup. Pas à dire je suis en désaccord avec l'un de vos points 🙂
    InformationsquelleAutor Nick Craver
  2. 18

    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 code JavaScript dans un fichier JS externe afin de séparer la logique et le code de la véritable balisage

    La raison pour cela est qu'il crée un code plus facile à maintenir et à déboguer, et il favorise également les standards du web et de l'accessibilité. Pensez-y comme ça: à la Recherche à votre exemple, si vous aviez des centaines de liens comme ça sur une page et le besoin de changer de la alert comportement pour une autre fonction à l'aide de JS externe références, vous feriez seulement besoin de changer une seule liaison d'événements dans un fichier JS plutôt que de copier et coller un tas de code ou de faire un rechercher-remplacer.

    InformationsquelleAutor Levi Hackwith
  3. 10

    Deux raisons:

    1. Mauvais code de pratique:

      Le HREF de la balise est pour indiquer qu'il est une référence de lien hypertexte vers un autre emplacement. En utilisant le même tag pour une fonction javascript qui n'est pas réellement l'utilisateur n'importe où est la mauvaise programmation de la pratique.

    2. SEO problèmes:

      Je pense que les robots d'indexation utiliser la balise HREF ramper à travers le site web & lien toutes les pièces reliées. Par la mise en javascript, nous briser cette fonctionnalité.

    3. Pauses accessibilité:

      Je pense que certains lecteurs d'écran ne sera pas en mesure d'exécuter le javascript & pourrait ne pas savoir comment traiter avec le javascript alors qu'ils s'attendent à un lien hypertexte. L'utilisateur s'attend à voir un lien dans la barre d'état du navigateur sur le vol stationnaire de la liaison alors qu'ils vont voir une chaîne de caractères comme: "javascript:" qui pourrait les confondre etc.

    4. Vous êtes encore dans les années 1990:

      Le courant de conseils est à votre javascript dans un autre fichier & se mélange pas avec le HTML de la page, comme cela a été fait dans les années 1990.

    HTH.

    • Je ne crois pas que le RÉFÉRENCEMENT est un argument valable, car ils sont très bien en mesure de savoir quels liens ils peuvent suivre et à qui ils ne peuvent pas. Je vais acheter votre argument à propos de les lecteurs d'écran (je m'étais sûr de l'amour d'entendre une voix d'ordinateur lire à haute voix de code Javascript), mais la barre de statut chose semble exagéré pour moi.
    • perhaphs je devrais remplacer la barre d'état commentaire de "confondre" à "peut irriter". Par expérience personnelle, j'aime Maj+clic ou Ctrl+clic sur les liens pour les ouvrir dans une nouvelle fenêtre quand je ne veux pas prendre le courant de page & quand que les pauses, je veux aller trouver le développeur qui l'a cassé à la première place 🙂
    • +1 pour le mauvais code de pratique, de href de la balise n'ont pas été créés pour indiquer le déclenchement d'un code JS.
    InformationsquelleAutor Sunny
  4. 6

    J'ai ouvert beaucoup de liens dans de nouveaux onglets - seulement pour voir javascript:void(). Si vous me gêner, ainsi que vous-même (parce que Google va voir la même chose).

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

    • Des langues mixtes ne sont pas bien pris en charge
      par la plupart des IDEs et des validateurs.
      Intégration CSS et JS dans les pages HTML
      (ou n'importe quoi d'autre d'ailleurs)
      assez bien détruit les possibilités de
      ont le langage intégré vérifié l'exactitude de l'
      de manière statique. Parfois, l'incorporation de la langue ainsi.
      (PHP ou ASP document n'est pas valide HTML.)
      Vous ne voulez pas la syntaxe
      les erreurs ou les incohérences de montrer
      seulement au moment de l'exécution.
    • Une autre raison est d'avoir un nettoyeur de séparation entre
      le genre de choses que vous devez
      préciser: HTML pour le contenu, CSS pour
      mise en page, JS général pendant plus de mise en page
      et le look-and-feel. Ce n'est pas la carte
      one to one: vous voulez généralement à appliquer
      en page de l'ensemble de la catégories de
      éléments de contenu (donc CSS) et de regarder et de se sentir ainsi
      (par conséquent, jQuery). Ils peuvent être modifiés à différentes
      fois que le contenu, les éléments sont modifiés (en fait
      le contenu est souvent généré à la volée) et par
      différentes personnes. Il est donc logique de les garder dans
      documents séparés ainsi.
    • A voté majoritairement pour le premier point. Essayez d'ouvrir un lien dans un nouvel onglet pour voir javascript:void(0) dans la barre d'adresse de lecteurs m' fou.
    • J'ai été plus de parler de code Javascript qui n'affecte que l'appel de la page. Je n'aime pas à voir javascript:void(0) soit.
    InformationsquelleAutor reinierpost
  5. 4

    Réponse courte: Javascript en ligne est mauvais pour les raisons que CSS est mauvais.

    InformationsquelleAutor leepowers
  6. 4

    À l'aide de la javascript: protocole concerne l'accessibilité, et aussi mal comment SEO friendly votre page.

    Prendre note que HTML signifie Hypter Texte quelque chose de quelque chose... Hyper Texte dénote texte avec des liens et des références, qui est un élément ancre <a> est utilisé pour.

    Lorsque vous utilisez le javascript: "protocole" vous êtes une utilisation abusive de l'élément d'ancrage. Puisque vous êtes une utilisation abusive de l' <a> élément, des choses comme le Google Bot et le lecteur d'Écran Jaws auront du mal à "comprendre" votre page, car ils ne se soucient pas beaucoup sur votre JS, mais attention beaucoup sur l'Hyper Texte ML, en prenant note de l'ancre hrefs.

    Il affecte également la convivialité de votre page quand un utilisateur qui n'ont pas JavaScript activé visite votre page, vous êtes la rupture de la fonctionnalité attendue et le comportement des liens pour les utilisateurs. Il ressemblera à un lien, mais il ne veut pas agir comme un lien, car il utilise la javascript protocole.

    Vous pourriez penser, "mais combien de personnes ont désactivé JavaScript aujourd'hui?", mais j'aime l'expression de cette idée, de plus le long des lignes de "Combien de clients potentiels suis-je prêt à détourner tout simplement parce que d'une case à cocher dans les paramètres de son navigateur?"

    Il se résume à la façon dont href est un attribut HTML, et en tant que tel, il appartient à votre site d'information, pas son comportement. Le JavaScript définit le comportement, mais vos ne voulez jamais à interférer avec les données/informations. L'incarnation de cette idée serait que le fichier JavaScript externe; ne pas utiliser onclick comme un attribut, mais plutôt comme un gestionnaire d'événement dans votre fichier JavaScript.

    • C'est Hypertext Markup Language. Cela étant dit, je suis en désaccord avec à peu près tout dans votre message, à l'exception du dernier paragraphe. Donc, je vais expliquer pourquoi dans les deux autres commentaires.
    • Pour le SEO argument, c'est seulement la gestion du protocole. Je suis sûr que les moteurs de recherche à savoir si un lien est un lien HTTP ou pas, et à l'aide d'un protocole inconnu n'est certainement pas à mélanger en permanence. Je suis tout à fait sûr à l'aide d'un mailto: lien sur ma page pas de faire de Google déteste ma page juste parce qu'il ne peut pas le suivre.
    • En outre, lorsqu'un lien est uniquement utilisé pour déclencher un script, vous serez toujours en abuser <a>, puisque vous pour pour mettre une autre href. Et dans ces cas, n'est-ce pas plus convivial vers Javascript désactivé Samu, pour utiliser le javascript: protocole? Il va juste pour ne rien faire au lieu de, disons, déplacer vers le haut de la page, en supposant que les indépendants-mais-il est nécessaire d'ancrage est #. (C'est évidemment en supposant que le lien n'est rien de plus que de déclencher une action Javascript.)
    • Je sais ce que le ML stand pour; le "quelque chose" avait pour but de montrer que dans le cadre de ma réponse le HT a été le plus important 😉 les Gens ont tendance à se concentrer sur la ML de plus que le HT. Comme pour le RÉFÉRENCEMENT, vous avez raison; Google ne sera pas la haine de votre page, mais il ne le fera pas comme il soit; vous êtes en lui donnant des informations, il ne peut que jeter. Pourquoi s'embêter? Quant à votre argument à propos d'être plus convivial, je vais aussi me daisy chain certains commentaires!
    • Je m'excuse que c'est un peu dur, mais à l'aide de la javascript: protocole se sent comme à la lazy manière de réaliser ce genre de convivialité pour les utilisateurs sans JS. J'ai aussi l'impression que vous êtes très fortement associée à l'utilisation de <a> avec un href comme l'élément, l'utilisateur doit cliquer sur, et par conséquent penser qu'un utilisateur pourrait obtenir un relevé de doigt de curseur pour cet élément. Ainsi, un utilisateur sans JS serait de la souris au-dessus de votre élément, voir le doigt pointé de penser "je peut interagir avec ce" cliquez dessus, puis rien ne se passe...
    • ... si vous êtes inquiet au sujet de saut à supprimer le href et cible un cursor:pointer propriété CSS de l'élément. De cette façon, votre ancre de ne pas aller n'importe où (comme le haut de la page) et a toujours un doigt pointu. Votre JS-moins de l'utilisateur de ne pas sauter ou quoi que ce soit d'autre sur la page lorsqu'il clique sur l'ancre. Mieux encore, lorsque vous définissez votre onclick dans un JS externe, appliquer un class attribut à l'élément, à qui votre cursor propriété est ciblée, de sorte que votre JS-moins de l'utilisateur ne reçoit rien de suggérer qu'il devrait la peine de cliquer sur ce à tous! (enregistrer les mots "cliquer ici", heheheh)

    InformationsquelleAutor Richard JP Le Guen
  7. 3

    Le pire problème est probablement que ça casse fonctionnalité attendue.

    Par exemple, comme d'autres l'ont souligné, ouvrir dans une nouvelle fenêtre/onglet = lien mort = ennuyé confusion des utilisateurs.

    J'essaie toujours d'utiliser onclick au lieu de cela, et ajouter quelque chose à l'URL de hachage de la page pour indiquer que la fonction souhaitée pour déclencher et d'ajouter une case à pageload pour vérifier le hash et de déclencher la fonction.

    Cette façon, vous obtenez le même comportement pour les clics, un nouvel onglet/fenêtre et même de marquer l'/liens envoyés, et les choses ne sont pas farfelus si JS est désactivé.

    En d'autres termes, quelque chose comme ceci (très simplifié):

    Pour le lien:

    onclick = "doStuff()"

href = "#dostuff"

    Pour la page:

    onLoad = if(hash="dostuff") doStuff();
    InformationsquelleAutor MatsSvensson
  8. 2

    Aussi, tant que nous parlons de la dépréciation et de la sémantique, il est probablement intéressant de souligner que " </a> "ne signifie pas "cliquable" -, il signifie "l'ancre", et implique un lien vers une autre page. Donc, il serait logique d'utiliser cette balise pour passer à une autre " vue " dans votre application, mais de ne pas effectuer de calcul. Le fait que vous n'avez pas une URL dans votre attribut href devrait être un signe que vous ne devriez pas être à l'aide d'une balise d'ancrage.

    Vous pouvez, en alternance, d'attribuer un événement click d'action pour presque n'importe quel élément html - peut-être un <h1>, un <img>, ou un <p> serait plus approprié? En tout cas, comme d'autres personnes l'ont mentionné, ajouter un autre attribut (un 'id' peut-être) que le javascript peut être utilisé comme un "hook" (document.getElementById) pour se rendre à l'élément et affecter un onclick. De cette façon, vous pouvez garder votre contenu (HTML) de la présentation (CSS) et l'interactivité (JavaScript) sont séparées. Et le monde ne finira pas.

    • Peut-être <span> serait plus approprié que <h1> car il est sémantiquement vide de sens. Mais j'ai eu l'idée.
    InformationsquelleAutor matt lohkamp
  9. 2

    Je ont généralement une page d'atterrissage appelé "EnableJavascript.htm" qui a un gros message en disant "Javascript doit être activé pour que cette fonction". Puis-je configurer mon ancrage des balises comme ceci...

    <a href="EnableJavascript.htm" onclick="funcName(); return false;">

    De cette façon, le point d'ancrage est légitime de destination qui sera remplacée par l'option Javascript de votre fonctionnalité autant que possible. Cela va dégrader gracieusement. Bien que, maintenant, un jour, de manière générale, j'construire des sites web avec complète fonctionnalités avant de me décider à saupoudrer un peu de Javascript dans le mélange (ce qui élimine la nécessité pour les ancres de ce genre).

    Utilisant l'attribut onclick directement dans le balisage est un tout autre sujet, mais je vous recommande une approche discrète avec une librairie comme jQuery.

    InformationsquelleAutor Josh Stodola
  10. 1

    Je pense que cela a à voir avec ce que l'utilisateur voit dans la barre d'état. En général les applications devraient être construits pour le basculement dans le cas où le javascript n'est pas activé mais ce n'est pas toujours le cas.

    Avec tout le spam qui se passe, les gens sont plus intelligents et lorsqu'un e-mail look "suspect" de plus en plus de gens sont à la recherche à la barre d'état pour voir où le lien sera effectivement prendre.

    N'oubliez pas d'ajouter "return false;" à la fin de votre lien pour que la page ne veut pas sauter vers le haut sur l'utilisateur (sauf si c'est le comportement que vous cherchez).

    InformationsquelleAutor RDL