Il suffit de parcourir le code source de Google Maps. Dans leur en-tête, ils ont 2 divs avec id = "search", l'un contient l'autre, ainsi que l'attribut jstrack = "1". Il y a un formulaire qui les sépare comme ceci:
<div id="search" jstrack="1">
<form action="/maps" id="...rest isn't important">
...
<div id="search">...
Depuis que c'est Google, je suppose que ce n'est pas une erreur.
Alors, à quel point peut-il vraiment être contraire à cette règle? Tant que vous faites attention dans votre sélection de css et de dom, pourquoi ne pas réutiliser les identifiants comme les classes? Est-ce que quelqu'un le fait exprès, et si oui, pourquoi?
programming-practices
html
specifications
Danludwig
la source
la source
Réponses:
Spécification dit unique
La spécification HTML 4.01 indique que l'ID doit être unique pour l'ensemble du document.
La spécification HTML 5 dit la même chose mais en d’autres termes. Il dit que l'ID doit être unique dans sa sous - arborescence de base , qui est fondamentalement le document si on en lit la définition .
Éviter la duplication
Mais comme les rendus HTML sont très indulgents en matière de rendu HTML, ils permettent les identifiants en double. Cela devrait être évité autant que possible et strictement évité lors de l'accès programmé à des éléments par des identifiants en JavaScript. Je ne suis pas sûr de la
getElementById
fonction à renvoyer lorsque plusieurs éléments correspondants sont trouvés. Devrait-il:Mais même si les navigateurs fonctionnent de manière fiable de nos jours, personne ne peut garantir ce comportement à l'avenir, car cela va à l'encontre des spécifications. C'est pourquoi je vous recommande de ne jamais dupliquer les identifiants dans le même document.
la source
undefined
). C'est rarement une bonne idée de s'appuyer sur un comportement indéfini.data-
attribut est pratique pour quand on peut être tenté d'attribuer le même ID à plusieurs choses. Cela vous permet d'avoir plusieurs identifiants différents avec undata-something
attribut commun en commun. Néanmoins, tous les navigateurs que je connais ignorent les attributs inconnus, ils sont donc probablement protégés dans presque tous les navigateurs modernes sans support HTML complet.data
attributs. Et ils sont également pris en charge directement par jQuery dès que vous faites simplement référence àdata-something="123"
attribut with$(elem).data("something")
.id="search"
.Vous avez demandé "comment mauvais". Donc, pour étoffer dehors @ RobertKoritnik (tout à fait exact) répondre un peu ...
Ce code est incorrect. Incorrect ne vient pas en nuances de gris. Ce code enfreint la norme et est donc incorrect. Cela échouerait dans la vérification de validation, et cela devrait être le cas
Cela dit, aucun navigateur actuellement sur le marché ne s'en plaindrait ou n'aurait de problème avec cela. Les navigateurs auraient le droit de se plaindre à ce sujet, mais aucune de leurs versions actuelles ne le fait actuellement. Ce qui ne veut pas dire que les versions futures pourraient ne pas traiter ce code de manière inappropriée.
Votre comportement en essayant d'utiliser cet ID en tant que sélecteur, en css ou en javascript, est indiscutable et varie probablement d'un navigateur à l'autre. Je suppose qu'une étude pourrait être faite pour voir comment chaque navigateur réagit à cela. Je pense que dans le meilleur des cas, il le traiterait comme "class =" et en sélectionnerait la liste. Cela risquerait de confondre les bibliothèques JavaScript. Si j’étais l'auteur de jQuery, j'aurais peut-être optimisé le code de mon sélecteur afin que, si vous me présentez avec un sélecteur commençant par "#", j'attends un seul objet, et obtenir un cette liste pourrait me casser complètement.)
Il peut également sélectionner le premier, ou éventuellement le dernier, ou n'en sélectionner aucun, ou bloquer complètement le navigateur. Pas moyen de le savoir sans l'essayer.
"Quelle est la gravité" dépend alors entièrement de la rigueur avec laquelle un navigateur particulier applique la spécification HTML et de ce qu'il fait lorsqu'il est confronté à une violation de cette spécification.
EDIT: Je viens de tomber sur cela aujourd'hui. J'insère divers composants à partir de formulaires de recherche sur différents types d'entités afin de produire un très grand utilitaire de reporting tout-en-un pour ce site. Je charge les formulaires de recherche des pages distantes dans des div cachés et les insère dans mon générateur de rapport lorsque le type d’entité approprié est sélectionné comme source pour le rapport. Il existe donc une version cachée du formulaire et une version affichée dans le générateur de rapports. Le code JavaScript fourni avec, dans tous les cas, fait référence aux éléments par ID, dont il y a maintenant DEUX sur la page - celui qui est caché et celui qui est affiché.
Ce que jQuery semble faire, c'est de me choisir le PREMIER, qui est dans tous les cas exactement celui que je ne veux pas.
Je travaille autour de cela en écrivant des sélecteurs pour spécifier la région de la page dans laquelle je veux obtenir mon champ (par exemple: $ ('# containerDiv #specificElement')). Mais il y a une réponse à votre question: jQuery sur Chrome se comporte vraiment de manière particulière lorsqu'il est confronté à cette violation des spécifications.
la source
Est-il si mal que ca?
L’expérience montre que getElementById dans les principaux navigateurs renvoie le premier élément correspondant du document. Mais cela ne sera peut-être pas toujours le cas à l'avenir.
Lorsque jQuery reçoit un identifiant, par exemple #foo, il utilise getElementById et imite ce comportement. Si vous devez contourner ce problème (c'est triste), vous pouvez utiliser $ (" * #foo") pour convaincre jQuery d'utiliser getElementsByTagName et renvoyer une liste de tous les éléments correspondants.
Je dois souvent écrire du code pour d'autres sites et je dois contourner ce problème. Dans un monde juste, je n'aurais pas besoin de repenser les fonctions pour commencer par vérifier si un identifiant est unique. Les identifiants doivent toujours être uniques. Le monde est cruel et c'est pourquoi je pleure.
la source
Vous pouvez faire beaucoup de choses - mais cela ne veut pas dire que vous devriez le faire.
En tant que programmeur (en général), nous construisons notre vie en étant précis et en suivant les règles - voici une règle simple à suivre, assez fondamentale pour ce que nous faisons - nous aimons (dépendons) des identifiants uniques dans une portée donnée ...
Casser la règle est une chose que nous pouvons faire parce que les navigateurs sont beaucoup trop accommodants - mais, en réalité, nous en serions tous mieux si les navigateurs demandaient strictement à un code HTML bien formé et valide. été remboursé!
Alors, est-ce vraiment si mauvais? En tant que programmeur, comment pouvez-vous même demander? C'est un crime contre la civilisation (-:
Addenda:
Parce que c’est - nous ne parlons pas de règles compliquées, nous parlons essentiellement de rendre les choses bien formées et d’appliquer par ailleurs des règles qui peuvent être testées mécaniquement et qui, à leur tour, facilitent le traitement mécanique du résultat. Si les navigateurs avaient été stricts, les outils se seraient très rapidement adaptés pour le supporter - ce n’était pas le cas, certains dans la mesure où ils exploitent cet échec à la place. Pensez simplement à cela - le courrier électronique aurait été un moyen beaucoup plus agréable si MS et Netscape ne l'avaient pas foiré en autorisant le langage HTML illimité alors qu'un "langage de balisage de courrier électronique" bien moins complexe, avec prise en charge explicite du texte cité, nous aurait fourni un outil bien meilleur ... mais ce navire a navigué et de même nous pouvons 'aurait dû ) mais nous ne pouvons pas
la source
Dans Scripting:
getElementByID
ne renverra que le premier match. En CSS:#id
affectera TOUS les éléments portant cet ID. Le rendu du navigateur n'aura aucun effet.C'est le comportement de la norme W3C. Ce n’est pas possible, c’est celui qui est défini.
https://dom.spec.whatwg.org/#interface-nonelementparentnode
la source
getElementById
pourrait parfaitement renvoyer n'importe quel élément, ou même un objet nul. L'effet CSS peut concerner n'importe quel élément, aucun ou tous les éléments. Ou le navigateur pourrait planter. En dehors de la norme, le comportement n'est pas défini