Simplemente navega por el código fuente de google maps. En su encabezado, tienen 2 divs con id = "search" uno contiene el otro, y también tiene el atributo jstrack = "1". Hay una forma que los separa así:
<div id="search" jstrack="1">
<form action="/maps" id="...rest isn't important">
...
<div id="search">...
Como se trata de Google, supongo que no es un error.
Entonces, ¿qué tan malo puede ser realmente violar esta regla? Siempre y cuando tenga cuidado en su selección de CSS y DOM, ¿por qué no reutilizar las clases como id? ¿Alguien hace esto a propósito, y si es así, por qué?
programming-practices
html
specifications
danludwig
fuente
fuente
Respuestas:
La especificación dice ÚNICO
La especificación HTML 4.01 dice que la ID debe ser única en todo el documento.
La especificación HTML 5 dice lo mismo pero en otras palabras. Dice que la ID debe ser única en su subárbol de inicio , que es básicamente el documento si leemos la definición del mismo .
Evitar duplicaciones
Pero dado que los renderizadores HTML son muy indulgentes cuando se trata de renderizar HTML, permiten identificaciones duplicadas. Esto debe evitarse si es posible y estrictamente evitado cuando se accede a elementos mediante programación mediante ID en JavaScript. No estoy seguro de qué
getElementById
función debería volver cuando se encuentran varios elementos coincidentes. Deberia:Pero incluso si los navegadores funcionan de manera confiable en estos días, nadie puede garantizar este comportamiento en el futuro ya que esto va en contra de las especificaciones. Es por eso que le recomiendo que nunca duplique ID dentro del mismo documento.
fuente
undefined
). Rara vez es una buena idea confiar en un comportamiento indefinido.data-
atributo es útil para cuando uno se siente tentado a asignar varias cosas a la misma ID. Esto le permite tener muchas ID diferentes con undata-something
atributo común en común. Aún así, todos los navegadores que conozco ignoran los atributos desconocidos, por lo que probablemente estén seguros en casi todos los navegadores modernos que carecen de soporte HTML completo.data
atributos. Y también son compatibles directamente con jQuery cuando simplemente hace referencia aldata-something="123"
atributo con$(elem).data("something")
.id="search"
.Usted preguntó "qué tan malo". Así que para dar un poco de respuesta a Robertbertoritnik (completamente 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 o tendría algún problema. Los navegadores tendrían derecho a quejarse al respecto, 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 tratar de usar esa ID como selector, ya sea en CSS o JavaScript, es incuestionable 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 "clase =" y seleccionaría la lista de ellos. (Sin embargo, eso podría confundir a las bibliotecas de JavaScript; 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 obtengo un la lista podría molestarme por completo).
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 entonces de cuán estrictamente un navegador en particular implemente la especificación HTML y lo que haga cuando se enfrente a una violación de esa especificación.
EDITAR: Acabo de encontrar esto hoy. Extraigo varios componentes de los formularios de búsqueda en varios tipos de entidades para producir una gran utilidad de informes todo en uno para este sitio, estoy cargando los formularios de búsqueda de las páginas remotas en divs ocultos y los inserto en mi generador de informes cuando se selecciona el tipo de entidad apropiado como la fuente del informe. Entonces, hay una versión oculta del formulario y una versión que se muestra en el generador de informes. El JavaScript que viene con, en todos los casos, se refiere a 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 PRIMERO, que en todos los casos es exactamente el que NO quiero.
Estoy trabajando en esto escribiendo selectores para especificar la región de la página en la que quiero obtener mi campo (es decir: $ ('# containerDiv #specificElement')). Pero hay una respuesta a su pregunta: jQuery en Chrome definitivamente se comporta de una manera particular cuando se enfrenta a esta violación de especificaciones.
fuente
¿Qué tan grave es en realidad?
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 jQuery recibe una identificación, por ejemplo, #foo, usa getElementById e imita ese comportamiento. Si tiene que solucionar esto (es triste), puede 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.
fuente
Usted puede hacer muchas cosas - pero eso no significa que usted debe.
Como programador (en términos generales) 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 gustan (dependemos) de identificadores únicos dentro de un alcance dado ...
Romper la regla es algo que podemos hacer porque el navegador es demasiado servicial, pero en realidad todos estaríamos mejor si los navegadores fueran estrictos sobre la necesidad de HTML bien formado y válido, la pequeña cantidad de dolor que habría causado habría pasado mucho tiempo ha sido pagado!
Entonces, ¿es realmente tan malo? Como programador, ¿cómo puedes preguntar? Es un crimen contra la civilización (-:
Apéndice:
Lo hago, porque es así: no estamos hablando de reglas complicadas, estamos hablando sustancialmente de hacer que las cosas estén bien formadas y de otra manera aplicar reglas que puedan probarse mecánicamente y que a su vez faciliten que el resultado se procese mecánicamente. Si los navegadores hubieran sido estrictos, entonces las herramientas se habrían adaptado muy rápidamente para soportar eso; no fue así, no lo hicieron, algunos en la medida en que explotan esa falla. Solo piense en esto: el correo electrónico habría sido un medio mucho mejor si MS y Netscape no lo hubieran estropeado 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 navegó y de manera similar podemos 'debería tener ) pero no podemos
fuente
En Scripting:
getElementByID
solo devolverá la primera coincidencia. En CSS:#id
afectará a TODOS los elementos con esa ID. En el navegador, el renderizado no tendrá ningún efecto.Este es el comportamiento del estándar w3c. No es posible, es el hecho definido.
https://dom.spec.whatwg.org/#interface-nonelementparentnode
fuente
getElementById
podría devolver perfectamente cualquier elemento, o incluso un objeto nulo. El efecto CSS podría estar en cualquier elemento, o en ninguno o en todos. O el navegador podría fallar. Fuera del estándar, el comportamiento no