refactor: Avoid breaking change for ARIA element types #4882
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Revert of #4876
All of the per-element types (
AnchorHTMLAttributes
,AreaHTMLAttributes
, etc) via core & compat are now interfaces again (as they are in React), with the new accessible types exported & hooked up toIntrinsicElements
so that users still get correct ARIA type checking. Users will now need to augment theAccessible
-prefixed types for a few elements, which may be a surprise & needs documentation for sure, but I think that's a better tradeoff; more people will import element types to extend or consume than will need to augment (say) all anchor tags globally.I spent so much time working on those aria roles & reading the spec that I suppose I overestimated/forgot how many elements in total need discriminated unions and can be represented properly, which turns out to be only
<a>
,<area>
,<img>
,<input>
, and<select>
. In my head there were a lot more 😅