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.

Inizia in lib.dom.d.ts dalla proprietà HTMLInputElement.type e verifica i valori validi di input type proposti nell'issue e su MDN. Esamina gli esempi di assegnazione TypeScript forniti per definire il comportamento previsto del controllo dei tipi. Il lavoro è completato quando le stringhe non valide vengono rifiutate, i valori validi come 'text' continuano a essere accettati e vengono affrontate le implicazioni del breaking change.