This needs a thorough review before merging. In particular, we need to check that added support for some combination of values of type and other attributes are properly described.

I've been thinking a bit, and talking with @Elchi3 and @chrisdavidmills , about how we should represent <input> in the BCD.

Logically, what we're looking at with <input> is a single HTML element with multiple attributes, and complex interrelationships especially between the "type" attribute and various other attributes.

So for example, "pattern" is only available for certain values of "type". Also, the version in which "pattern" was supported is different depending on the specific value of "type" we're looking at - for example, Firefox supported "pattern" in "date" inputs only since 57, but supported it in "text" inputs much earlier.

The simplistic logical approach to this is to model it as a single element with multiple attributes:

input {
    accept {
    ...
    pattern {
    ...
    type {
    ....

...and then try to deal with the interrelationships.

But I don't think this is going to be very useful for our users. From the user's point of view, I feel like we should tend to represent things more or less as if the different <input> types are different entities, with their own compat tables. As a user, say I want to use a "range" input, I want to see a table that shows me the compat story for all the relevant attributes as they apply in the case of range.

This is because users don't go

I want to use the input element, what's the compat story?

They go

I want a checkbox, what's the compat story?

So I think we should model this in the data, like:

input {
    input-button {    // description: "type=\"button\"
        accesskey
        id
        name
        ...
    },
    ...
    input-number {     // description: "type=\"number\"
        ....
        max
        min
        step
        ....
    },
   ....
    input-range {     // description: "type=\"range\"
        ....
        max
        min
        list
        step
        ....
    },
...

(I guess we should split each type into its own file, but logically the tree would be like that.)

There are some drawbacks and questions about this. The obvious drawback is that the data will be quite big and repetitive.

The (related) question is whether we should explicitly enumerate all attributes, even ones whose compat story is the same as "Basic support". Or should we only enumerate ones whose compat story is different from the "Basic support" row? (I think probably we should not enumerate all attributes, but I'm not sure about this.)

But I think overall this kind of approach will be more useful for users.

I'll start making a PR along these lines, to see what it looks like.

We could add a dependency on #1799, which should minimise the amount of duplication where the support information is identical.

I’m closing this PR as HTML <input> is now being done in separate PRs by other contributors.

We should probably still have a PR for adding an input.json file so the input types have a parent?

Yes! Updated the check list at #911 to track the remaining work.