Repository: TypeScript
Issue: lib.dom.d.ts: HTMLInputElement::type should be more specific than just 'string'
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker.

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ, especially the "Common Feature Requests" section: https://github.com/Microsoft/TypeScript/wiki/FAQ

-->

## Search Terms

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

- HTMLInputElement type
- HTML input type
- input type
	- this one returned thousands of unrelated results, so admittedly I didn't go through them all

## Suggestion

<!-- A summary of what you'd like to see added or changed -->

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](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#%3Cinput%3E_types)). I would like to change this property to be a union of string literals that expresses this set of strings.

## Use Cases

<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

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

<!-- Show how this would be used and what the behavior would be -->

```typescript
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.
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).