Et si les attributs HTML personnalisés ne sont pas des XHTML valides?
Je sais que c'est la raison pour laquelle certaines personnes ne les approuvent pas, mais est-ce vraiment important? Je pense que la puissance qu'ils fournissent, en interagissant avec JavaScript et en stockant et en envoyant des informations depuis et vers le serveur, l'emporte sur le problème de validation. Suis-je en train de manquer quelque chose? Quelles sont les ramifications du HTML "invalide"? Et une DTD personnalisée ne les résoudrait-elle pas de toute façon?
La ramification est que w3c apparaît dans 2, 5, 10 ans et crée un attribut du même nom. Votre page est maintenant cassée.
HTML5 va fournir un type d'attribut de données pour les attributs personnalisés légaux (comme data-myattr = "foo"), alors vous pourriez peut-être commencer à l'utiliser maintenant et être raisonnablement à l'abri des futures collisions de noms.
Enfin, vous ignorez peut-être que la logique personnalisée est le rationnel derrière l'attribut class. Bien qu'il soit généralement considéré comme un attribut de style, il s'agit en réalité d'un moyen légal de définir des méta-propriétés personnalisées sur un élément. Malheureusement, vous êtes essentiellement limité aux propriétés booléennes, c'est pourquoi HTML5 ajoute le préfixe de données.
BTW, par "essentiellement booléen", je veux dire en principe. En réalité, rien ne vous empêche d'utiliser un séparateur dans le nom de votre classe pour définir des valeurs personnalisées ainsi que des attributs.
class="document docId.56 permissions.RW"
Oui, vous pouvez légalement ajouter des attributs personnalisés en utilisant des "données".
Par exemple:
<div id="testDiv" data-myData="just testing"></div>
Après cela, utilisez simplement la dernière version de jquery pour faire quelque chose comme:
alert($('#testDiv').data('myData'))
ou pour définir un attribut de données:
$('#testDiv').data('myData', 'new custom data')
Et puisque jQuery fonctionne dans presque tous les navigateurs, vous ne devriez avoir aucun problème;)
mise à jour
- data-myData peut être converti en data-mydata dans certains navigateurs, en ce qui concerne le moteur javascript. Mieux vaut le garder en minuscules tout le long.
La validation n'est pas une fin en soi, mais un outil à utiliser pour détecter rapidement les erreurs et réduire le nombre de problèmes de rendu et de comportement mystérieux auxquels vos pages Web peuvent être confrontées lorsqu'elles sont utilisées sur plusieurs types de navigateur.
L'ajout d'attributs personnalisés n'affectera ni l'un ni l'autre de ces problèmes maintenant, et il est peu probable que cela se produise à l'avenir, mais comme ils ne valident pas, cela signifie que lorsque vous venez d'évaluer la sortie d'une validation de votre page, vous devrez choisissez soigneusement entre les problèmes de validation qui importent et ceux qui ne le sont pas. Chaque fois que vous changez de page et revalidez, vous devez répéter cette opération. Si votre page est entièrement validée, vous obtenez un message Nice PASS vert et vous pouvez passer à la prochaine étape du test ou au prochain changement à effectuer.
J'ai vu des gens obsédés par la validation faire des choses bien pires/étranges que d'utiliser un simple attribut personnalisé:
<base href="http://example.com/" /><!--[if IE]></base><![endif]-->
À mon avis, les attributs personnalisés n'ont pas vraiment d'importance. Comme d'autres disent, il peut être bon de faire attention aux futurs ajouts d'attributs dans les normes. Mais maintenant, nous avons des attributs data- * en HTML5, nous sommes donc enregistrés.
Ce qui compte vraiment, c'est que vous ayez des balises correctement imbriquées et des valeurs d'attribut correctement citées.
J'utilise même des noms de balises personnalisés (ceux introduits par HTML5, comme l'en-tête, le pied de page, etc.), mais ceux-ci ont des problèmes dans IE.
Soit dit en passant, je trouve souvent ironiquement comment tous ces fanatiques de validation s'inclinent devant les astuces intelligentes de Google, comme les téléchargements iframe.
Au lieu d'utiliser des attributs personnalisés, vous pouvez associer vos éléments HTML aux attributs à l'aide de JSON:
var customAttributes = { 'Id1': { 'custAttrib1': '', ... }, ... };
Et pour les ramifications, voir réponse de SpliFF .
Le stockage de plusieurs valeurs dans l'attribut class n'est pas une encapsulation de code correcte et juste une façon compliquée de faire les choses. Prenez par exemple un rotateur publicitaire personnalisé qui utilise jquery. C'est beaucoup plus propre sur la page à faire
<div class="left blue imagerotator" AdsImagesDir="images/ads/" startWithImage="0" endWithImage="10" rotatorTimerSeconds="3" />
et laissez un simple code jquery faire le travail à partir d'ici. N'importe quel développeur ou concepteur Web peut désormais travailler sur le rotateur publicitaire et modifier ses valeurs lorsque cela lui est demandé sans trop tarder.
Revenir au projet un an plus tard ou en entrer un nouveau où le développeur précédent s'est séparé et est allé sur une île quelque part dans le Pacifique peut être un enfer essayer de comprendre les intentions lorsque le code est écrit de manière cryptée peu claire comme ceci:
<div class="left blue imagerotator dir:images-ads endwith:10 t:3 tf:yes" />
Lorsque nous écrivons du code en c # et dans d'autres langages, nous n'écrivons pas de code en plaçant toutes les propriétés personnalisées dans une propriété en tant que chaîne délimitée par des espaces et nous devrons analyser cette chaîne chaque fois que nous devons y accéder ou y écrire. Pensez à la prochaine personne qui travaillera sur votre code.
Le truc avec la validation, c'est qu'aujourd'hui cela n'a peut-être pas d'importance, mais vous ne pouvez pas savoir si ça va avoir de l'importance demain (et, selon la loi de Murphy, cela aura de l'importance demain).
Il est préférable de choisir une alternative pérenne. S'ils n'existent pas ( ils le font dans ce cas particulier ), le chemin à parcourir est d'inventer une alternative à l'épreuve du temps.
L'utilisation d'attributs personnalisés est probablement inoffensive, mais pourquoi choisir une solution potentiellement dangereuse simplement parce que vous pensez (vous ne pouvez jamais être sûr) qu'elle ne causera aucun dommage?. Il pourrait être utile d'en discuter davantage si l'alternative à l'épreuve du temps était trop coûteuse ou trop lourde, mais ce n'est certainement pas le cas.
Vieille discussion mais néanmoins; à mon avis, le html étant un langage de balisage et non de programmation, il doit toujours être interprété avec clémence pour les "erreurs" de balisage. Un navigateur est parfaitement capable de le faire. Je ne pense pas que cela changera et devrait changer. Par conséquent, le seul critère pratique important est que votre code HTML soit affiché correctement par la plupart des navigateurs et continuera de le faire dans, disons, quelques années. Passé ce délai, votre code HTML sera probablement repensé de toute façon.
Juste pour ajouter mon ingrédient au mélange, la validation est également importante lorsque vous devez créer du contenu qui peut/pourrait être post-traité à l'aide d'outils automatisés. Si votre contenu est valide, vous pouvez convertir plus facilement le balisage d'un format à un autre. Par exemple, faire du XHTML en XML valide avec un schéma spécifique est beaucoup plus facile lors de l'analyse des données que vous connaissez et que vous pouvez vérifier pour suivre un format prévisible.
Par exemple, j'ai BESOIN que mon contenu soit XHTML valide, car il est très souvent converti en XML pour divers travaux, puis reconverti sans perte de données ni résultats de rendu inattendus.
Eh bien, cela dépend de votre client/patron/etc. ont-ils besoin que ce soit une validation XHTML?
Certaines personnes disent qu'il existe de nombreuses solutions de contournement - et selon le scénario, elles peuvent très bien fonctionner. Cela inclut l'ajout de classes, l'exploitation de l'attribut rel et quelqu'un qui a même écrit son propre analyseur pour extraire JSON des commentaires HTML.
HTML5 fournit un moyen standard de le faire, préfixez vos attributs personnalisés avec "data-". Je recommanderais de le faire maintenant de toute façon, car il est possible que vous utilisiez un attribut qui sera utilisé en cours de route en XHTML standard.
Validation
Vous ne devriez pas avoir besoin d'attributs personnalisés pour fournir la validation. Une meilleure approche serait d'ajouter la validation basée sur les champs de la tâche réelle.
Attribuez un sens à l'aide de classes. J'ai des noms de classe comme:
date(Dates)Zip(code postal)area(Zones)ssn(numéro de sécurité sociale)
Exemple de balisage:
<input class="date" name="date" value="2011-08-09" />
Exemple javascript (avec jQuery):
$('.date').validate(); // use your custom function/framework etc here.
Si vous avez besoin de validateurs spéciaux pour un certain scénario ou vous inventez simplement de nouvelles classes (ou utilisez sélecteurs ) pour votre cas spécial:
Exemple pour vérifier si deux mots de passe correspondent:
<input id="password" />
<input id="password-confirm" />
if($('#password').val() != $('#password-confirm').val())
{
// do something if the passwords don't match
}
(Cette approche fonctionne parfaitement avec la validation jQuery et le framework mvc .net et probablement d'autres aussi)
Bonus: vous pouvez attribuer plusieurs classes séparées par un espace class = "ssn custom-one custom-two"
Envoi d'informations "depuis et vers le serveur"
Si vous devez renvoyer des données, utilisez <input type="hidden" />. Ils fonctionnent hors de la boîte.
(Assurez-vous de ne pas transmettre de données sensibles avec des entrées cachées car elles peuvent être modifiées par l'utilisateur sans presque aucun effort)
L'utilisation de code HTML non standard peut faire en sorte que le navigateur affiche la page en "mode excentrique", auquel cas certaines autres parties de la page peuvent s'afficher différemment, et d'autres choses comme le positionnement peuvent être légèrement différentes. Cependant, l'utilisation d'une DTD personnalisée peut contourner ce problème.
Jquery .html (balisage) ne fonctionne pas si balisage n'est pas valide.
Parce qu'ils ne sont pas standard, vous n'avez aucune idée de ce qui pourrait arriver, ni maintenant, ni à l'avenir. Comme d'autres l'ont dit, le W3C pourrait commencer à utiliser ces mêmes noms à l'avenir. Mais ce qui est encore plus dangereux, c'est que vous ne savez pas ce que les développeurs de "browser xxx" ont fait lorsqu'ils les rencontrent.
Peut-être que la page est rendue en mode excentrique, peut-être que la page ne s'affiche pas à tous sur un navigateur mobile obscur, peut-être que le navigateur fuira de la mémoire, peut-être qu'un antivirus s'étouffera sur votre page, etc., etc.
Je sais que suivre religieusement les normes peut sembler du snobisme. Cependant, une fois que vous avez rencontré des problèmes parce que vous ne les suivez pas, vous avez tendance à arrêter de penser comme ça. Cependant, il est généralement trop tard et vous devez démarrer votre application à partir de zéro avec un cadre différent ...
Je pense que les développeurs valident juste pour valider, mais il y a quelque chose à dire pour le fait qu'il garde le balisage propre. Cependant, parce que chaque navigateur (avertissement d'exagération!) Affiche tout différemment, il n'y a vraiment pas de norme. Nous essayons de suivre les normes car cela nous donne l'impression d'avoir au moins une certaine direction. Certaines personnes soutiennent que le maintien du code standard permettra d'éviter des problèmes et des conflits à l'avenir. Mon avis: viser que personne n'implémente les normes correctement et complètement aujourd'hui de toute façon, pourrait aussi bien supposer que tout votre code échouera finalement. Si cela fonctionne, cela fonctionne, utilisez-le, sauf si c'est désordonné ou si vous essayez simplement d'ignorer les normes pour le coller au W3C ou quelque chose. Je pense qu'il est important de se rappeler que les normes sont mises en œuvre très lentement, le web a-t-il beaucoup changé en 5 ans. Je suis sûr que quiconque aura des années de préavis lorsqu'il devra résoudre un conflit potentiel. Aucune raison de planifier la compatibilité des normes à l'avenir lorsque vous ne pouvez même pas compter sur les normes d'aujourd'hui.
Oh j'ai presque oublié, si votre code ne valide pas 10 chatons mourront. Êtes-vous un tueur de chaton?