There is also #3093 which adds a file for input attributes.
I thought that @wbamberg maybe has thoughts on how we want to arrange the global input attributes in bcd. If not, we can probably work this out together in the next few days or as a new task in the upcoming sprint. There are a few more "global" input attributes left to be done here.

Sure, I'm happy to wait for a discussion and decision on this. My addition is not exactly a critical piece of support info; just a nice to have really.

My thinking was that we would have a separate file for "global" input attributes (e.g. available on all input types), and then add support info for attributes that are only supported on specific info types into the JSON files for those types.

Of course, this doesn't mean we'd have to add explicit support info for all attributes; just ones that were added later and so don't fit the "Basic support" details.

So the current approach for this is that described in #1698 (comment), and has us treating different types of input elements as different entities, from a BCD perspective.

At the moment this gives us compat tables like:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/color#Browser_compatibility
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/range#Browser_compatibility
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#Browser_compatibility

The main reasons for this are:

• there are complex interdependencies between that BCD for "type" and the BCD for the other attributes. If we document them all in one table, we have to try to describe these, and it will not be pretty.
• people use the different input types are if they were different elements: they don't come saying "I want to make an input element" they say "I want a radio button". Presenting them with the info they need on that page seems better for usability.

Documenting compat for other attributes, even global ones, at the level of input instead of at the level of the individual types means people have to look in two places to get a complete picture of the compat story for a particular input element, and also seems to mean we might need to describe the interrelationships between this attribute and the type attribute.

But that's just my opinion :).

This all makes sense. So what should we do about global input attributes then? It sounds you are saying we'll have to duplicate the attribute support info across all the attributes. Which won't be any fun.

The linked comment #1698 (comment) talks about this:

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.)

So that recommends that we should only list attributes, including global ones, when we have something interesting to say about them, and otherwise treat them we covered by the "Basic support" data for that input type.

Just to correct my wording from before:

It sounds you are saying we'll have to duplicate the attribute support info across all the attributes

I meant "It sounds you are saying we'll have to duplicate the attribute support info across all the input types"

To answer Will's followup comment:

So that recommends that we should only list attributes, including global ones, when we have something interesting to say about them, and otherwise treat them we covered by the "Basic support" data for that input type.

OK, so in this case I believe we do have something interesting to say that isn't covered by Basic support. This still doesn't answer my question of where to put the data in such a case.

This should probably be placed at the top level¹ into html/elements/input.json.

¹ By that I mean html.elements.input as html.elements.input.x-moz-errormessage.

That would probably work for me. I'll wait for a second opinion from Will/Florian.

That works for me, too. The export "html.elements.input.x-moz-errormessage" is exactly what I would expect.
Just wondering if we're fine with the file name html/elements/input/input_attributes.json, or if we want html/elements/input/input.json or so.

I think input.json would be better, as this would allow the file to logically contain data points that aren't just covered by "Basic support", whether they concern attribute support or something else. I'm happy to change it.

One more question is whether we should add "Basic support" info at the input level? I agree with Will's statement about people wanting information on radio buttons or checkboxes, not "the input element", but at the same time it feels weird that the input page's compat table doesn't have a Basic support line, whereas pretty much every other one does.

Thanks @ExE-Boss ; I agree with this, and I think we should change the filename. I've done both.