lib.dom.d.ts: HTMLInputElement::type should be more specific than just 'string'

Search Terms

• HTMLInputElement type
• HTML input type
• input type
  • this one returned thousands of unrelated results, so admittedly I didn't go through them all

Suggestion

In lib.dom.d.ts, HTMLInputElement::type is currently specified as a string, but its value can only legally be one of a known set of strings (specified on MDN). I would like to change this property to be a union of string literals that expresses this set of strings.

Use Cases

Currently, code which assumes string is assignable to HTMLInputElement.type is operating on a bad assumption which is not actually safe.
By restricting the allowed strings in this property, we get benefits including:

• The obvious benefit of strict typechecking so that developers don't have to worry about typos or other errors causing their input elements to revert back to type text
  • This also allows IDEs to fill in valid types for these developers.
• typeof HTMLInputElement.prototype.type (as HTMLInputElement outside of lib.dom.d.ts refers to the declared var rather than the interface) can be used as a way to express all valid types without needing to declare another type that may eventually become inconsistent or have some errors of its own (omissions, typos, etc)

Examples

const inputElement = document.createElement('input');
inputElement.type = 'cat'; // should be illegal
inputElement.type = 123456; // already illegal (not assignable to 'string')
inputElement.type = '123456'; // should be illegal
inputElement.type = 'text'; // should be legal

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code-
  • This would be a breaking change in existing TypeScript code, because any code which assumes that an arbitrary string is assignable to typeof HTMLInputElement.prototype.type is not actually making safe assumptions. Despite this, I am submitting this issue as both a record of the fact that the shortcoming exists, and to gather feedback on whether this is an acceptable level of breaking to implement it.
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

Start in lib.dom.d.ts at the HTMLInputElement.type property and review the proposed valid input type values from the issue and MDN. Check the provided TypeScript assignment examples to define the intended type-checking behavior. Done means invalid strings are rejected, valid values such as 'text' remain accepted, and the breaking-change implications are addressed.