Do these types belong to HTMLAttributes?

[iivvaannxx]

• Check if updating to the latest Preact version resolves the issue

Describe the bug
Looking at these type declarations, I can see some attributes inside the HTMLAttributes interface that are commented as 'Standard HTML Attributes' but many of them aren't standard at all.

In my particular case I spent a lot of time trying to setup a type with Typescript that used HTMLAttributes for a couple of elements (HTMLInputElement and HTMLTextAreaElement) which discriminated attributes from one or another depending on a prop value. I was expecting the rows attribute to be present only on the HTMLTextAreaElement and not in the HTMLInputElement because rows is a native element of a textarea and not of an input. I assumed this and slammed my head onto a wall when I figured out that the attribute rows wasn't being discriminated because it was present as a 'standard' element in the general HTMLAttributes interface.

Is it intended to be like this because something that I am missing? (I am not very familiar with preact). Every other major framework (including React, Astro and Svelte) don't include this 'standard' attribute.

To Reproduce

I don't think an actual minimal repo isn't necessary in this case, but I have this example of the Typescript Playground which tries to grab the 'rows' attribute from an input element using both the react typings and the preact ones. While the preact ones are resolved, the react ones are not (as I would expect).

Expected behavior

The 'rows' key of the HTMLAttributes<HTMLInputElement> should not be resolved (how it happens with the react types).

[rschristian]

I can see some attributes inside the HTMLAttributes interface that are commented as 'Standard HTML Attributes' but many of them aren't standard at all.

"Standard HTML Attributes", as opposed to Non-standard Attributes, RDFa Attributes, Microdata Attributes, etc., not attributes that exist on every single element type.

I think our types are significantly simpler than most other frameworks, though yes, this does mean you can add attributes anywhere you want (as you could with HTML). We might be open to being stricter if someone wanted to work on that?

[iivvaannxx]

I agree with you that the types are simpler than most other frameworks, but in my opinion, allowing HTML tags that are not actually native in an element (even though you could in HTML) is a little counter-intuitive, at least if you expect Typescript to flag an error (like if you come from another framework where this actually happens).

As a developer is, of course, my duty to ensure the correct attributes are set and everything works as it should, but it’s definitely nice having a “guard” in case I miss something, or if I am developing something which will be used by someone else which may not know this.

I am not very familiar with the library, but if the only required thing is to write the correct types for each native HTML tag, I could definitely take that as soon as I have a little of time. Shouldn’t be very difficult.