Attributs non Standard sur les balises HTML. Bonne Chose? Mauvaise Chose? Vos Pensées?
HTML (ou peut-être juste XHTML?) est relativement strict en ce qui concerne les attributs non standard sur les tags. S'ils ne font pas partie de la spécification, alors votre code est considéré comme non conforme.
les attributs Non standard peuvent être assez utiles pour transmettre des méta-données à Javascript. Par exemple, si un lien est supposé afficher une popup, vous pouvez définir le nom de la fenêtre dans un attribut:
<a href="#null" class="popup" title="See the Popup!"
popup_title="Title for My Popup">click me</a>
alternativement, vous pouvez stocker le titre pour le popup dans un élément caché, comme une portée:
<style>
.popup .title { display: none; }
</style>
<a href="#null" title="See the Popup!" class="popup">
click me
<span class="title">Title for My Popup</span>
</a>
je suis toutefois tiraillé quant à laquelle devrait être une méthode préférée. La première méthode est plus concise et, je suppose, ne touche pas aux moteurs de recherche et aux lecteurs d'écran autant. Inversement, la deuxième option rend le stockage de grandes quantités de données plus facile et est donc plus polyvalent. Il est également conforme aux normes.
je suis curieux de savoir ce que ces communautés pensent. Comment gérez-vous un ce genre de situation? La simplicité de la première méthode l'emportent sur les inconvénients potentiels (si il y en a)?
9 réponses
je suis un grand fan de la solution HTML 5 proposée (attributs préfixés data- ). Edit: j'ajouterais qu'il y a probablement de meilleurs exemples pour l'utilisation d'attributs personnalisés. Par exemple, les données qu'une application personnalisée utilisera et qui n'ont pas d'équivalent dans les attributs standard (p. ex. personnalisation pour les gestionnaires d'événements basés sur quelque chose qui ne peut pas nécessairement être exprimé dans un nom de classe ou un id).
les attributs personnalisés offrent un moyen pratique de transporter des données supplémentaires du côté du client. Dojo Toolkit le fait régulièrement et il a été souligné ( Debunking Dojo Toolkit Myths ) que:
les attributs personnalisés ont toujours été valide HTML, ils ne valident tout simplement pas lorsqu'il est testé contre une DTD. [...] Le La spécification HTML stipule que toute attribut non reconnu doit être ignoré par le moteur de rendu HTML dans agents utilisateurs, et dojo en option profite de cela pour améliorer facilité de développement.
une autre option serait de définir quelque chose comme ceci en Javascript:
<script type="text/javascript">
var link_titles = {link1: "Title 1", link2: "Title 2"};
</script>
alors vous pouvez utiliser ceci plus tard dans votre code Javascript, en supposant que votre lien a un ID qui correspond à L'ID dans ce hashtable.
il n'a pas les désavantages des deux autres méthodes: aucun attribut non standard ni la Vilaine portée cachée.
l'inconvénient est qu'il pourrait un peu d'un surmenage pour des choses aussi simples que votre exemple. Mais pour des scénarios plus complexes, où vous avez plus de données à transmettre, c'est un bon choix. Surtout si l'on considère que les données sont passées sous JSON, de sorte que vous pouvez passer des objets complexes avec facilité.
aussi, vous gardez les données séparées du formatage, ce qui est une bonne chose pour la maintenabilité.
Vous pouvez même avoir quelque chose comme ceci (vous ne pouvez pas vraiment avec les autres méthodes):
var poi_types = {1: "City", 2: "Restaurant"};
var poi = {1: {lat: X, lng: Y, name: "Beijing", type: 1}, 2: {lat: A, lng: B, name: "Hatsune", type: 2}};
...
<a id="poi-2" href="/poi/2/">Hatsune</a>
et comme vous utilisez très probablement un langage de programmation côté serveur, cette table de hachage devrait être triviale pour générer dynamiquement (il suffit de la sérialiser à JSON et de la cracher dans la section en-tête de la page).
bien dans ce cas, la solution optimale est
<a href="#" alt="" title="Title of My Pop-up">click</a>
et en utilisant l'attribut title.
Parfois, je casse la spécification si j'en ai vraiment besoin. Mais rarement, et seulement pour de bonnes raisons.
EDIT: Je ne sais pas pourquoi le -1, mais je faisais remarquer que parfois vous pensez que vous avez besoin de briser la spécification, quand vous ne le faites pas.
pourquoi ne pas déclarer l'attribut popup_title dans une DTD personnalisée ? Cela résout le problème de la validation. Je le fais avec tous les éléments, attributs et valeurs non standards et merci cette validation me montre seulement de vrais problèmes avec mon code. Cela rend également les erreurs de navigateur moins possibles avec un tel HTML.
vous pouvez insérer des éléments d'entrée cachés à l'intérieur de l'élément d'ancrage
<a id="anchor_id">
<input type="hidden" class="articleid" value="5">
Link text here
</a>
, Alors vous pouvez facilement extraire les données par
$('#anchor_id .articleid').val()
ma solution à la fin était de cacher des données supplémentaires dans la balise id séparée par une sorte de délimiteur (un underscore est un espace, deux est la fin de cet arg), le second arg il y a un id:
<a href="#" class="article" id="Title_of_My_Pop-up__47">click</a>
Ugly, et il suppose que vous n'êtes pas déjà en utilisant l'étiquette d'identification pour quelque chose d'autre, mais il est conforme à travers chaque navigateur.
mon sentiment personnel dans votre exemple est que la route span est plus appropriée, car elle répond aux normes de la spécification XHTML. Cependant, je peux voir un argment pour les attributs personnalisés, mais je pense qu'ils ajoutent un niveau de confusion qui n'est pas nécessaire.
j'ai creusé mon cerveau pour ça aussi. J'aime la lisibilité de la non-attributs standard, mais je n'aime pas ce que ça va casser standard. L'exemple de portée cachée est conforme, mais il n'est pas très lisible. Qu'en est-il de ceci:
<a href="#" alt="" title="" rel="{popup_title:'Title of My Pop-up'}">click</a>
ici le code est très lisible, à cause de la notation de la paire clé/valeur de JSON. Vous pouvez dire que ce est méta-données qui appartient lien juste en le regardant. Le seul défaut que je peux voir à côté de détourner le " rel" attribut est que cela pourrait obtenir désordre pour les objets complexes. J'aime vraiment cette idée de" données - " attributs préfixés mentionnés ci-dessus. Faire tout les navigateurs actuels de soutien?
Voici autre chose à quoi penser. Quel impact le code non conforme a-t-il sur le référencement?