Deux éléments HTML avec le même attribut id: Quelle est leur gravité?

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?

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 getElementByIdfonction à renvoyer lorsque plusieurs éléments correspondants sont trouvés. Devrait-il:

• renvoyer une erreur?
• retourner le premier élément correspondant?
• retourner le dernier élément correspondant?
• renvoyer un ensemble d'éléments correspondants?
• ne retourne rien?

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.

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.

Est-il si mal que ca?

1. Ça me fait pleurer
2. C'est invalide
3. De nombreuses bibliothèques javascript ne fonctionneront pas comme prévu
4. Cela rend votre code déroutant

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.

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:

Vous écrivez que les navigateurs sont trop accommodants comme si c'était une mauvaise chose

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

Dans Scripting: getElementByIDne renverra que le premier match. En CSS: #idaffectera 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