getElementById should not return the first but no element if id exists multiple times

[kkmuffme]

What is the issue with the DOM Standard?

https://dom.spec.whatwg.org/#concept-id

An element can have an associated unique identifier (ID)
This specification makes ID a concept of the DOM and allows for only one per element, given by an id attribute.

But then:
https://dom.spec.whatwg.org/#dom-nonelementparentnode-getelementbyid

The getElementById(elementId) method steps are to return the first element

While there are historical reasons (= fixing people's mistakes) for this, this behavior is inconsistent and can have massive side-effects, since it's asserted that it's unique. However, this uniqueness is purely stated, but contradicts practical behavior, since there is not a single function/method that complies with this uniqueness, is there?

Therefore either
a) remove the "unique" from the spec for id - then what's the point of "id" to begin with? It's essentially identical to class and obsolete.
or
b) enforce the "unique" for the id in getElementById - if there are multiple elements with the same ID, it should not return the first, but no elements (since null is already reserved for no elements found, it could possibly return false in that case)
While this is going to hurt a lot initially, I think this would be the right thing to do, since that's how it works everywhere else too. Inserting a non-unique ID into a database? You get an error.

Why that matters?
The uniqueness property allows skipping certain validations that are necessary for non-unique elements. e.g. you provide a button to copy something to the user's clipboard. Since the docs state that IDs are unique, you can be sure it actually copied what you wanted - except that's obviously wrong, since something else could have used the same ID somewhere in the document before your id, and the user would have copied something completely different

[keithamus]

Thanks for the issue @kkmuffme.

This change would not be web compatible (it would break a ton of existing code) and so would be very unlikely to get implementer interest.

[annevk]

It's reasonable to attempt to clarify the standard as suggested under A (though perhaps not exactly in that manner). We don't have to entertain B as that's indeed not possible.

[WebReflection]

not sure I am adding anything, but IDs have a meaning in SVG namespaces too where these can be embedded into the document and conflict with outer IDs without having an outer-scope understanding of what's going on.

Accordingly, I agree there should be some warning around IDs used on the web because Shadow DOM (out of <template> declarations), SVG, and who knows what else could have similar names so that it should never guarantee, if the ID is not unique, that it returns the mentioned element, encouraging developers to use better querySelector CSS constraints when such expectation is desired.

True that getElementById is the widest used API that worked for 20+ years and that cannot, and should not (imho), be changed by any mean.