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

92

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)?

Dave Mankoff
la source
3
Ceux-ci sont appelés attributs "expando" - si vous voulez en savoir plus sur eux.
Jason Bunting
2
AFAIK, les attributs expando sont définis lors de l'exécution à l'aide de javascript. Ils ne font pas partie du XHTML lui
Philippe Leybaert

Réponses:

50

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).

paupière
la source
2
J'ai tendance à suivre cette solution maintenant - même si elle n'est pas conforme aux normes.
Tom Ritter
1
J'ai toujours évité cela, car cela ne valide pas. Mais maintenant que j'y pense, tout entasser dans un attribut class = "" (comme les métadonnées jquery) n'est pas forcément mieux. Y a-t-il des inconvénients pratiques et réels à cette méthode dans <HTML5 land? Fondamentalement, quels problèmes vont se poser maintenant? On dirait que ce n'est pas idéal, mais qu'il n'a aucun effet secondaire auquel je puisse penser.
rocketmonkeys
@Rocketmonkeys Je ne suis pas sûr, mais je pense que l'utilisation de données dans un attribut de classe peut forcer le navigateur à essayer d'appliquer des règles css non définies à un élément, cela peut causer des problèmes ou des problèmes de performances. Encore une fois, je ne suis pas sûr.
Vitim.us
@ Vitim.us, s'il y avait un tel impact sur les performances, ce serait négligeable. Les navigateurs sont assez efficaces pour ce genre de choses; le succès pour appliquer réellement les styles serait plus grand. Et rappelez-vous, les classes ne sont pas quelque chose d'inventé dans le but de styliser, ce sont juste des données d'élément comme tout autre attribut. N'importe quel attribut peut être utilisé dans un sélecteur, donc s'il y a une telle performance, il s'appliquerait littéralement à n'importe quel attribut (y compris le data-préfixe) que vous ajoutez à l'élément.
paupière
@eyelidlessness c'est un bon argument, je dois être d'accord, même si j'utilise plutôt correctement la structure de données dans Javascript, j'ai trouvé dans certains cas que l'utilisation de l'attribut de données convient. J'évite jquery comme dit Rocketmonkeys. Je dois vraiment arrêter de déranger les gens à propos des micro-optimisations.
Vitim.us
27

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.

Maine
la source
9

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).

ibz
la source
4

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.

jskulski
la source
4

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.

Chapiteau
la source
2

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()
Ioan Alexandru Cucu
la source
1
Oui, mais la meilleure façon est d'utiliser: <input type="hidden" title="article_id" value="5" />. Puisque la classe est quelque chose pour CSS, donner en fait un code invalide si la classe n'est pas dans les informations de style. Même si JS ou CSS est désactivé, les données resteront masquées.
Yeti
1
@Yeti, la classe n'est pas quelque chose pour CSS ni invalide si elle n'apparaît pas dans les styles. Ce ne sont que des données sur l'élément, comme tout autre attribut. L'association avec CSS est qu'il s'agit d'un sélecteur bien pris en charge.
paupière
0

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.

Matt Parkins
la source
-1

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.

Vendeurs Mitchel
la source
10
La route SPAN est cependant une mauvaise utilisation de la balise. Il peut répondre aux normes de validation, mais il ne répond pas aux normes sémantiques.
ceejayoz le
-1

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?


la source
7
L'attribut rel décrit la relation entre la page actuelle et la ressource liée. Ce n'est pas un attribut générique «Stockez les données que vous aimez». C'est donc horrible.
Quentin
1
Est-ce que les navigateurs actuels prennent en charge cela? - Qu'y a-t-il à soutenir? Les navigateurs peuvent déjà tolérer du code non conforme. Étant donné que cela fait partie du nouveau HTML5, il n'y a rien à craindre d'ajouter l'attribut data-comme vous ajouteriez n'importe quel autre attribut personnalisé.
Slave