Square brackets and input names

Had a minor panic attack at the sudden thought that square brackets mightn't be legal in the name attribute of form inputs in (X)HTML, which -- given PHP's incredibly useful array syntax for forms¹ -- would've been an unqualified disaster. Five seconds of thought would've been reassurance enough, since, well, come on: the hue and cry from the standards evangelists would have shaken heaven itself.

But instead I turned to Google, which turned up all sorts of confirming misinformation and vaguely related, vaguely threatening documents. Generally also replies by people who knew what they were talking about, so it all worked out -- yes, they are perfectly legal -- it just took a while to get there.

RTFMDTD didn't help, at least initially. To someone who's never dug deep into SGML or XML, this is isn't especially intuitive:

<!ELEMENT input EMPTY>     <!-- form control -->
<!ATTLIST input
  %attrs;
  %focus;
  type        %InputType;    "text"
  name        CDATA          #IMPLIED
  value       CDATA          #IMPLIED

I'm not surprised that so many of the comments I googled up didn't understand it either. The actual specifications are (surprise!) specific, but opaque; if you try to work around them -- if you just search for "html input name square bracket", say -- you'll find all manner of irrelevancies.

HTML 4, for example, uses "name" in multiple contexts: most notably, various different elements have name attributes serving different purposes. Anchor elements use name to define a fragment identifier. Image maps have a name which is the target an image's usemap attribute. Images and forms could have a (deprecated) name for scripting purposes. Object params use it to "define the name of a run-time parameter". Form inputs use it to define the control name.

That isn't too important (though, of course, they'll contaminate searches for the word "name") until it comes to notices like this one on XHTML/HTML compatibility guidelines:

Further, since the set of legal values for attributes of type ID is much smaller than for those of type CDATA, the type of the name attribute has been changed to NMTOKEN. This attribute is constrained such that it can only have the same values as type ID, or as the Name production in XML 1.0 Section 2.3, production 5. Unfortunately, this constraint cannot be expressed in the XHTML 1.0 DTDs. Because of this change, care must be taken when converting existing HTML documents. The values of these attributes must be unique within the document, valid, and any references to these fragment identifiers (both internal and external) must be updated should the values be changed during conversion.

If taken out of context, it's easy to read as applying to all name attributes. From there, knowing that the name attribute could "only have the same value as type ID", the next step is to find the details of "type ID":

ID and NAME [there's that word "name" again!] tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").

No square brackets! Oh noes! Given the compatibility notice's mention that "this constraint cannot be expressed in the XHTML 1.0 DTDs", it's not unreasonable to further suppose that the validator's failure to issue warnings is an unfixable bug.

But, no. That wasn't talking about all names. id is an ID, yes, but input names are CDATA, and CDATA is perfectly happy with square brackets.