Various "terms defined by this specification" are miscapitalized

[domenic]

This is partially a Bikeshed issue, and it's completely editorial, so not very important. Anyway...

https://heycam.github.io/webidl/#index-defined-elsewhere shows everything lowercased. This is because all of these are classified as "dfn"-type terms.

• Many of them should be "abstract-op"
• Probably the built-in constructors like %Promise% and should be "interface"?
• No idea what @@toStringTag and friends should be (not attributes, since they aren't "for" anything)
• No idea what %ObjProto_values% and friends should be (maybe a "method" for %Object%??)
• No idea what %ArrayPrototype% and friends should be (not an interface... it's an object)
• Several of the terms reference "ECMAScript" which should not be lowercased, but they are still probably "dfn"

@tabatkins any ideas here?

[tabatkins]

All the IDL types are for, well, IDL; many of the ES-spec concepts should map there, but it may be awkward or incomplete. Happy to expand the set of definition types to help handle this, as I do want ES specs to have an okay time with the reference database. I'm not really sure what all these concepts are, as I'm not fluent in ES-speak.

Several of the terms reference "ECMAScript" which should not be lowercased, but they are still probably "dfn"

Unfortunately I don't have a way to handle "parts of this term should have specific capitalization, but the rest shouldn't". At least the casing only changes in the indexes, where it can be attributed to a stylistic effect?

[domenic]

I wonder if we could come up with a term type like "JS object" or "programming language value" or similar that would encompass my "no idea" bullets. If we wanted to be more specific, I guess they would be: symbol (or property name?), function, and object.

For the ECMAScript issue, maybe hard-code in a list of proper names? Or just provide an override like data-dfn-dont-override-lt-case. Meh.

[tabatkins]

Problem is that I do want to override the casing, just not for one specific part of the phrase. I dont' want it to uppercase the first word of "conventions of the ECMAScript specification" just because you started a sentence with it in your prose, for example.

Hmm, I could add a "casing hint" attribute that dictates how the letters are to be treated. Like, for "conventions of the ECMAScript specification", the original dfn could provide `casing-hint="........... .. ... AAAAAaaaaa ............." indicating that all the dots are "dont' care", and the upper/lowercase letters are "must be upper/lowercase". By requiring word length and whitespace to match up correctly (and fatal-erroring if they don't), I can make it less likely that it'll drift if you change the wording.

I can also just always proper-case the word "ECMAScript". That's pretty unambiguous.

[domenic]

This is blocked on speced/bikeshed#861