Unpredicted behavior of using non-unique IDs

When people are saying that using identical id's for different DOM elements is wrong, I totally agree. I mean, there is no even something to discuss.

But what is actually meant by the phrase "if you will have several eponymous ids on the page, that doesn't guaranteed to work"?

What actually does not guaranteed to work? We can treat ID as a regular attribute, thus, we can find all divs that document.querySelectorAll('[id="container"]'). Accessing through getAttribute/setAttribute should work as well. If we are trying to fetch an element via document.getElementById - well, I haven't tested, but most probably selector engine will return first element it find traversing the tree. I can imagine this can not be guaranteed. What else?

CSS will work pretty fine - #container {background-color: "red"} will paint with red all found containers (or am I wrong). Can somebody show me where in standard spec such behaviour is not guaranteed?

So, what is a开发者_运维问答ctually not guaranteed? Once again, I do acknowledge the fact that using same IDs is wrong. Neither do I want discuss perfomance issues of applying id-heavy css rules. The question is about something which is quite similar to what C/C++ programmers call "unpredicted behavior".

UPD: If it sounds hard or even stupid for you, then well, just provide an examples of unpredictable ID related behavior in specific browser. At least, as for me, it is more useful answer than "well, anything is not guaranteed, how can not you get it!".

An implementation would be within the spec if it refused completely to work with documents that contain duplicate ids, or ignored the multiply-used id in all of the elements that claim it, or returned a random of the elements from getElementById. It could even be a different random element in each call.

Can somebody show me where in standard spec such behaviour is not guaranteed?

That's not how it works. If it's not guaranteed, then everywhere in the spec is where it's not guaranteed. It's only guaranteed if somewhere in the spec there's an explicit guarantee you can point to. Otherwise, there's no guarantee in the spec, which means that it's not guaranteed.

The spec says that ID's are supposed to be unique.

That means that the browser itself has no obligation to implement code that can support multiple non-unquie IDs. It can assume when it builds the DOM model that ids are unique and are usable as keys. They may work in some browsers, today. But maybe tomorrow they won't. Just because they happen to function in the browsers you have tested, doesn't mean they will in future versions, or they behave as such in a different non-repeatable manner.

Maybe the first time you load a page on a monday document.getElementById might return the first element, if it's after 5pm on a tuesday and it's on an SSL site, then maybe document.getElementById throws an exception. Maybe a new release of firefox doesn't apply css attributes to anything past the first occurance of the id. Who knows. The browser developers don't have to care, that is what "not guaranteed to work" means.

Here is a jsfiddle showing some selector quirks: http://jsfiddle.net/DmEmJ/

Quoth the spec:

id = name [CS]
This attribute assigns a name to an element. This name must be unique in a document.

If you want a non-unique handle, use classes. That's what they are for.