Dois elementos HTML com o mesmo atributo de ID: quão ruim é realmente?

Basta navegar no código fonte do google maps. No cabeçalho, eles têm 2 divs com id = "search", um contém o outro e também tem o atributo jstrack = "1". Existe um formulário que os separa assim:

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

Como esse é o google, suponho que não seja um erro.

Então, quão ruim pode ser realmente violar essa regra? Contanto que você tenha cuidado na seleção de css e dom, por que não reutilizar as ids como classes? Alguém faz isso de propósito e, se sim, por quê?

Especificação diz UNIQUE

A especificação HTML 4.01 diz que o ID deve ser único em todo o documento.

A especificação do HTML 5 diz a mesma coisa, mas em outras palavras. Ele diz que o ID deve ser único em sua subárvore inicial , que é basicamente o documento se lermos a definição dele .

Evitar duplicação

Porém, como os renderizadores de HTML são muito tolerantes no que diz respeito à renderização de HTML, eles permitem IDs duplicados. Isso deve ser evitado se possível e estritamente evitado ao acessar elementos de programação por IDs em JavaScript. Não tenho certeza de qual getElementByIdfunção deve retornar quando vários elementos correspondentes são encontrados? Deveria:

• retornou um erro?
• retornar o primeiro elemento correspondente?
• retornar o último elemento correspondente?
• retornar um conjunto de elementos correspondentes?
• retornar nada?

Mas, mesmo que os navegadores funcionem de maneira confiável atualmente, ninguém poderá garantir esse comportamento no futuro, pois isso é contra a especificação. É por isso que eu recomendo que você nunca duplique IDs no mesmo documento.

Você perguntou "quão ruim". Então, para esclarecer um pouco a resposta (inteiramente precisa) de RobertKoritnik ...

Esse código está incorreto. Incorreto não vem em tons de cinza. Este código viola o padrão e, portanto, está incorreto. Falharia na verificação da validação, e deveria.

Dito isto, nenhum navegador atualmente no mercado reclamaria ou teria qualquer problema com ele. Os navegadores teriam o direito de reclamar, mas nenhuma das versões atuais de nenhum deles o faz atualmente. O que não significa que versões futuras podem não tratar mal esse código.

Seu comportamento ao tentar usar esse ID como seletor, tanto em css quanto em javascript, é inquestionável e provavelmente varia de navegador para navegador. Suponho que um estudo possa ser feito para ver como cada navegador reage a isso. Eu acho que, na melhor das hipóteses, trataria isso como "class =" e selecione a lista deles. (Porém, isso pode confundir as bibliotecas JavaScript - se eu fosse o autor do jQuery, poderia ter otimizado meu código do seletor para que, se você me encontrar com um seletor começando com "#", espere um único objeto e obtenha um A lista pode estar completamente diferente.)

Ele também pode selecionar o primeiro, ou possivelmente o último, ou não selecionar nenhum deles, ou travar completamente o navegador. Não há como saber sem tentar.

"Quão ruim" depende inteiramente de quão rigorosamente um navegador específico implementa a especificação HTML e o que ele faz quando confrontado com uma violação dessa especificação.

EDIT: Acabei de me deparar com isso hoje. Estou usando vários componentes de formulários de pesquisa em vários tipos de entidades para produzir um grande utilitário de relatórios completo para este site. Estou carregando os formulários de pesquisa das páginas remotas em divs ocultos e colocando-os no meu gerador de relatórios quando o tipo de entidade apropriado é selecionado como a origem do relatório. Portanto, há uma versão oculta do formulário e uma versão exibida no gerador de relatórios. O JavaScript que acompanha o produto, em todos os casos, refere-se a elementos por ID, dos quais agora existem DOIS na página - o oculto e o exibido.

O que o jQuery parece estar fazendo é me escolher o PRIMEIRO, que em todos os casos é exatamente o que NÃO QUERO.

Estou trabalhando nisso, escrevendo seletores para especificar a região da página em que quero obter meu campo (por exemplo: $ ('# containerDiv #specificElement')). Mas há uma resposta para sua pergunta: o jQuery no Chrome definitivamente se comporta de uma maneira particular quando confrontado com essa violação de especificação.

Quão ruim é realmente?

1. Me faz chorar
2. É inválido
3. Muitas bibliotecas javascript não funcionarão conforme o esperado
4. Isso torna seu código confuso

A experiência diz que getElementById nos principais navegadores retornará o primeiro elemento correspondente no documento. Mas isso nem sempre pode ser o caso no futuro.

Quando o jQuery recebe um ID, por exemplo, #foo, ele usa getElementById e imita esse comportamento. Se você precisar solucionar isso (isso é triste), poderá usar $ (" * #foo") que convencerá o jQuery a usar getElementsByTagName e retornará uma lista de todos os elementos correspondentes.

Muitas vezes tenho que escrever código para outros sites e preciso contornar isso. Em um mundo justo, eu não precisaria reprojetar funções para começar verificando se um ID é único. Os IDs devem sempre ser exclusivos. O mundo é cruel e é por isso que eu choro.

Você pode fazer muitas coisas - mas isso não significa que você deveria.

Como programador (de um modo geral), construímos nossas vidas sendo precisas e seguindo as regras - eis uma regra simples de seguir, que é bastante fundamental para o que fazemos - gostamos (dependemos de) de identificadores exclusivos dentro de um determinado escopo ...

Quebrar a regra é algo que podemos fazer porque o navegador é muito flexível - mas, na verdade, estaríamos melhor se os navegadores fossem rigorosos quanto à necessidade de HTML bem formado e válido, a pequena quantidade de dor que isso causaria teria durado muito tempo. foi pago!

Então, é realmente tão ruim assim? Como programador, como você pode perguntar? É um crime contra a civilização (-:

Termo aditivo:

Você escreve que os navegadores são muito flexíveis, como se fosse uma coisa ruim

Sim, porque é - não estamos falando de regras complicadas, estamos falando substancialmente de tornar as coisas bem formadas e de aplicar regras que podem ser testadas mecanicamente e que, por sua vez, facilitam o processamento mecânico do resultado. Se os navegadores fossem rigorosos, as ferramentas teriam se adaptado muito rapidamente para dar suporte a isso - não foi o que fizeram, algumas na medida em que exploram essa falha. Apenas pense nisto: o email teria sido um meio muito melhor se a MS e o Netscape não o tivessem estragado ao permitir HTML irrestrito quando uma "linguagem de marcação de email" muito menos complexa com suporte explícito ao texto citado nos daria uma ferramenta muito melhor ... mas esse navio navegou e da mesma forma que podemos 'deveria ter ) mas não podemos

Em Script: getElementByIDretornará apenas a primeira correspondência. Em CSS: #idafetará TODOS os elementos com esse ID. Na renderização do navegador, não terá nenhum efeito.

Este é o comportamento do padrão w3c. Não é possível, é o fato definido.

https://dom.spec.whatwg.org/#interface-nonelementparentnode