Dos elementos HTML con el mismo atributo de identificación: ¿Qué tan grave es realmente?

111

Simplemente navegando por el código fuente de google maps. En su encabezado, tienen 2 divs con id="buscar" uno contiene el otro, y también tiene el atributo jstrack="1". Hay una forma que los separa como tal:

<div id="search" jstrack="1">
    <form action="/maps" id="...rest isn't important">
        ...
        <div id="search">...

Ya que esto es google, asumo que no es un error.

Entonces, ¿qué tan malo puede ser violar esta regla? Mientras tengas cuidado en tu selección de css y dom, ¿por qué no reutilizar las clases de id? ¿Alguien lo hace a propósito, y si es así, por qué?

    
pregunta danludwig 27.12.2011 - 18:23

5 respuestas

133

La especificación dice ÚNICO

especificación HTML 4.01 dice que ID debe ser único en todo el documento.

especificación HTML 5 dice lo mismo pero en otras palabras. Dice que ID debe ser único en su home subárbol , que es básicamente el documento si lee la definición de él .

Evita la duplicación

Pero dado que los representadores de HTML son muy tolerantes cuando se trata de la representación HTML, permiten identificaciones duplicadas. Esto debe evitarse si es posible y se evita estrictamente cuando se accede mediante programación a los elementos mediante ID en JavaScript. ¿No estoy seguro de qué función getElementById debería devolver cuando se encuentran varios elementos coincidentes? En caso de que:

  • devolver un error?
  • devolver el primer elemento coincidente?
  • devolver el último elemento coincidente?
  • devolver un conjunto de elementos coincidentes?
  • no devolver nada?

Pero incluso si los navegadores funcionan de manera confiable en estos días, nadie puede garantizar este comportamiento en el futuro ya que esto está en contra de la especificación. Por eso le recomiendo que nunca duplique las ID en el mismo documento.

    
respondido por el Robert Koritnik 27.12.2011 - 18:29
29

Has preguntado "qué mal". Así que para desarrollar un poco la respuesta de @KorkKoritnik (totalmente precisa) ...

Ese código es incorrecto. Incorrecto no viene en tonos de gris. Este código viola el estándar y por lo tanto es incorrecto. Fallaría la verificación de validación, y debería.

Dicho esto, ningún navegador actualmente en el mercado se quejaría de ello, o tendría algún problema con él. Los navegadores estarían dentro de sus derechos para quejarse, pero ninguna de las versiones actuales de ninguno de ellos lo hace actualmente. Lo que no significa que las versiones futuras no traten mal este código.

Su comportamiento al intentar usar esa ID como un selector, ya sea en css o javascript, no se puede adivinar y probablemente varía de un navegador a otro. Supongo que se podría hacer un estudio para ver cómo reacciona cada navegador a eso. Creo que en el mejor de los casos, lo trataría como "class=", y seleccionaría la lista de ellos. (Eso podría confundir las bibliotecas de JavaScript, sin embargo, si yo fuera el autor de jQuery, podría haber optimizado mi código de selector para que si vienes a mí con un selector que comienza con "#", espero un solo objeto y obtengamos un la lista me puede llenar completamente.

También puede seleccionar el primero, o posiblemente el último, o no seleccionar ninguno de ellos, o bloquear el navegador por completo. No hay forma de saberlo sin probarlo.

"Qué tan malo" depende completamente de cómo estrictamente un navegador particular implementa la especificación HTML, y lo que hace cuando se enfrenta a una violación de esa especificación.

EDITAR: Me acabo de encontrar esto hoy. Estoy incorporando varios componentes de formularios de búsqueda en diversos tipos de entidades para producir una gran utilidad de informes todo en uno para este sitio, estoy cargando los formularios de búsqueda de páginas remotas en divs ocultos y los coloco en mi generador de informes cuando se selecciona el tipo de entidad apropiado como la fuente para el informe. Así que hay una versión oculta del formulario y una versión que se muestra en el generador de informes. El JavaScript que vino con, en todos los casos, se refiere a los elementos por ID, de los cuales ahora hay DOS en la página: el oculto y el que se muestra.

Lo que parece estar haciendo jQuery es seleccionarme el PRIMER, que en todos los casos es exactamente el que NO quiero.

Estoy trabajando alrededor de esto escribiendo selectores para especificar la región de la página en la que quiero que aparezca mi campo (es decir: $ ('# containerDiv #specificElement')). Pero hay una respuesta a tu pregunta: jQuery en Chrome definitivamente se comporta de una manera particular cuando se enfrenta a esta violación de especificaciones.

    
respondido por el Dan Ray 27.12.2011 - 19:18
20

¿Qué tan malo es realmente?

  1. Me hace llorar
  2. Es inválido
  3. Muchas bibliotecas de javascript no funcionarán como se esperaba
  4. Hace que tu código sea confuso

La experiencia dice que getElementById en los principales navegadores devolverá el primer elemento coincidente en el documento. Pero esto puede no ser siempre el caso en el futuro.

Cuando a jQuery se le asigna un ID, por ejemplo, #foo, usa getElementById e imita ese comportamiento. Si tienes que solucionar esto (es triste), puedes usar $ (" * #foo") que convencerá a jQuery de usar getElementsByTagName y devolver una lista de todos los elementos coincidentes.

A menudo tengo que escribir código para otros sitios, y tengo que solucionar esto. En un mundo justo, no tendría que rediseñar las funciones para comenzar comprobando si una ID es única. Las identificaciones siempre deben ser únicas. El mundo es cruel y por eso lloro.

    
respondido por el ColBeseder 04.09.2012 - 11:27
8

Usted puede hacer muchas cosas, pero eso no significa que deba hacerlo.

Como programadores (en general) construimos nuestras vidas siendo precisos y siguiendo las reglas. Aquí hay una regla que es simple de seguir, que es bastante fundamental para lo que hacemos: nos gusta (depende de) identificadores únicos dentro de un alcance dado ...

Romper la regla es algo que podemos hacer porque el navegador es demasiado cómodo, pero en realidad todos estaríamos mejor si los navegadores fueran estrictos en cuanto a la necesidad de un HTML bien formado y válido, la pequeña cantidad de dolor que habría causado hace tiempo que han sido reembolsados!

Entonces, ¿es realmente tan malo? Como programador, ¿cómo puedes siquiera preguntar? Es un crimen contra la civilización (-:

Anexo:

  

Escribes que los navegadores son demasiado complacientes como si fuera algo malo

Sí, porque lo es: no estamos hablando de reglas complicadas, estamos hablando sustancialmente de hacer las cosas bien formadas y de lo contrario aplicar reglas que pueden probarse mecánicamente y que a su vez hacen que sea más fácil para el resultado Procesado mecánicamente. Si los navegadores hubieran sido estrictos, entonces las herramientas se habrían adaptado muy rápidamente para admitir eso; no fue así como lo hicieron, algunos en la medida en que explotan esa falla. Solo piense en esto: el correo electrónico hubiera sido un medio mucho mejor si MS y Netscape no lo hubieran arruinado al permitir HTML sin restricciones cuando un "lenguaje de marcado de correo electrónico" mucho menos complejo con soporte explícito para el texto citado nos hubiera dado una herramienta mucho mejor ... pero ese barco zarpó y, de manera similar, no podemos cerrar la puerta del establo en lo que permiten los navegadores ( deberíamos , HTML5 deberíamos tener ) pero no podemos

    
respondido por el Murph 27.12.2011 - 21:47
5

En las secuencias de comandos: getElementByID solo devolverá la primera coincidencia. En CSS: #id afectará a TODOS los elementos con ese ID. En Browser Render no tendrá ningún efecto.

Este es el comportamiento del estándar w3c. No es posible, es el definido de facto.

enlace

    
respondido por el Bart Calixto 27.12.2011 - 22:35

Lea otras preguntas en las etiquetas