Attributs non standard sur les balises HTML. Bonne chose? Mauvaise chose? Tes pensées?

HTML (ou peut-être juste XHTML?) Est relativement strict en ce qui concerne les attributs non standard sur les balises. S'ils ne font pas partie de la spécification, votre code est considéré comme non conforme.

Les attributs non standard peuvent cependant être assez utiles pour transmettre des méta-données à Javascript. Par exemple, si un lien est censé afficher une popup, vous pouvez définir le nom de la popup 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 de la popup dans un élément caché, comme un span:

<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 cependant déchiré quant à la méthode à privilégier. La première méthode est plus concise et, je suppose, ne tourne pas autant avec les moteurs de recherche et les lecteurs d'écran. À l'inverse, la deuxième option facilite le stockage de grandes quantités de données et est donc plus polyvalente. Il est également conforme aux normes.

Je suis curieux de savoir ce que pensent ces communautés. Comment gérez-vous une telle situation? La simplicité de la première méthode l'emporte-t-elle sur les inconvénients potentiels (s'il y en a)?

Je suis un grand fan de la solution HTML 5 proposée ( data-attributs préfixés). Edit: J'ajouterais qu'il existe probablement de meilleurs exemples d'utilisation d'attributs personnalisés. Par exemple, les données qu'une application personnalisée utilisera qui n'ont pas d'analogue dans les attributs standard (par exemple, la personnalisation des gestionnaires d'événements basée 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é 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é du HTML valide, ils ne se valident tout simplement pas lorsqu'ils sont testés par rapport à une DTD. [...] La spécification HTML indique que tout attribut non reconnu doit être ignoré par le moteur de rendu HTML dans les agents utilisateurs, et Dojo en profite éventuellement pour améliorer la facilité de développement.

Une autre option serait de définir quelque chose comme ça en Javascript:

<script type="text/javascript">
var link_titles = {link1: "Title 1", link2: "Title 2"};
</script>

Ensuite, vous pouvez l'utiliser plus tard dans votre code Javascript, en supposant que votre lien a un ID qui correspond à l'ID dans cette table de hachage.

Il n'a pas les inconvénients des deux autres méthodes: pas d'attributs non standard ni la laideur cachée.

L'inconvénient est que cela pourrait un peu exagérer pour des choses aussi simples que votre exemple. Mais pour les scénarios plus complexes, où vous avez plus de données à transmettre, c'est un bon choix. Surtout compte tenu du fait que les données sont transmises au format JSON, vous pouvez donc passer facilement des objets complexes.

De plus, 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 ça (ce que vous ne pouvez pas vraiment faire 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 puisque vous utilisez très probablement un langage de programmation côté serveur, cette table de hachage devrait être facile à générer dynamiquement (il suffit de la sérialiser en JSON et de la cracher dans la section d'en-tête de la page).

Eh 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 brise les spécifications si j'en ai vraiment besoin. Mais rarement, et seulement pour une bonne raison.

EDIT: Je ne sais pas pourquoi le -1, mais je faisais remarquer que parfois vous pensez que vous devez casser les spécifications, alors que 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 fais cela avec tous les éléments, attributs et valeurs non standard et merci cette validation ne me montre que de vrais problèmes avec mon code. Cela rend également les erreurs de navigateur moins possibles avec un tel HTML.

Vous pouvez imbriquer des éléments d'entrée masqué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>

Ensuite, vous pouvez facilement extraire les données en

$('#anchor_id .articleid').val()

Ma solution à la fin était de cacher des données supplémentaires dans la balise id séparées par une sorte de délimiteur (un trait de soulignement est un espace, deux est la fin de cet argument), le second argument il y a un identifiant:

<a href="#" class="article" id="Title_of_My_Pop-up__47">click</a>

Moche, et cela suppose que vous n'utilisez pas déjà la balise d'identification pour autre chose, mais elle est compatible avec tous les navigateurs.

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.

Je me suis aussi creusé la tête à ce sujet. J'aime la lisibilité des attributs non standard, mais je n'aime pas que cela cassera la norme. L'exemple de span caché est conforme, mais il n'est pas très lisible. Et ça:

<a href="#" alt="" title="" rel="{popup_title:'Title of My Pop-up'}">click</a>

Ici, le code est très lisible, en raison de la notation de paire clé / valeur de JSON. Vous pouvez dire que ce sont des métadonnées qui appartiennent au lien simplement en le regardant. Le seul défaut que je peux voir à côté du détournement de l'attribut "rel" est que cela serait compliqué pour les objets complexes. J'aime vraiment cette idée d'attributs préfixés "données" mentionnée ci-dessus. Est-ce que les navigateurs actuels prennent en charge cela?

Voici autre chose à penser. Quel est l'impact du code non conforme sur le référencement?