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.

Beginne in lib.dom.d.ts bei der HTMLInputElement.type-Eigenschaft und prüfe die im Issue und auf MDN vorgeschlagenen gültigen input type-Werte. Sieh dir die bereitgestellten TypeScript-Zuweisungsbeispiele an, um das beabsichtigte Verhalten der Typprüfung festzulegen. Als abgeschlossen gilt die Aufgabe, wenn ungültige Zeichenfolgen abgelehnt werden, gültige Werte wie 'text' weiterhin akzeptiert werden und die Auswirkungen der Breaking Change berücksichtigt sind.