Open chris-morgan opened 4 years ago
I expect it's to allow a space-separated set of IDs to exist, but I don't really recall any attribute which has that.
Yeah, the parallel with class
is the only thing I’ve been able to surface or think of, and a few times I’ve introduced invisible empty elements for the purpose of multiple anchors in the same place; allowing a set of IDs would be nice. But in practice, browsers all treat the space as part of the ID, so I suppose that ship has long sailed.
Well, this is a conformance requirement, not a processing requirement. If there was a set of IDs pointer attribute it would never be able to match your ID with space, so flagging it as non-conforming seems helpful. That a non-set ID pointer attribute can still match it doesn't really matter for that, I think.
I expect it's to allow a space-separated set of IDs to exist, but I don't really recall any attribute which has that.
In HTML itself, there are three:
…and ARIA adds several more:
Thanks Mike! I think that settles that. I suppose we could add a note to the id
attribute description.
Ah, I understand now. Yes, this makes sense, thanks for the conveyed wisdom!
Concerning the
id
attribute, the spec says:A few times over the years I've investigated, but never come across any explanation or justification.
This rule feels arbitrary, and IDs with spaces seem to work just fine regardless of this decree. (I tested them with
#foo\ bar
in CSS and as a navigation fragment, and it worked fine in all of IE11, Firefox and Chrome; I’ve tested U+0020 only.)Is there any reason for this restriction, or could it reasonably be dropped from the spec?