Skip to content

Conversation

caugner
Copy link
Contributor

@caugner caugner commented Oct 14, 2025

Summary

Extracts HTML <datalist> input type subfeatures, and duplicates these below html.input.elements.type_*.

Test results and supporting details

To review, look at "grouped by change" in this comment.

Related issues

Once landed, we can tackle the issues mentioned in #25723.

@caugner caugner requested a review from Elchi3 October 14, 2025 12:23
@github-actions github-actions bot added data:html Compat data for HTML elements. https://developer.mozilla.org/docs/Web/HTML size:l [PR only] 101-1000 LoC changed labels Oct 14, 2025
Copy link
Contributor

github-actions bot commented Oct 14, 2025

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

Copy link
Contributor Author

@caugner caugner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to myself: Missing spec URLs.

Copy link
Member

@Elchi3 Elchi3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and duplicates these below html.input.elements.type_*.

I'm not sure if this is needed, is it?

@caugner
Copy link
Contributor Author

caugner commented Oct 17, 2025

and duplicates these below html.input.elements.type_*.

I'm not sure if this is needed, is it?

I would argue that the duplication is helpful for web developers that are looking at the input types. Recently, we used a similar approach for CSS transition, and IIRC we have a few related cases where a BCD feature relates to two APIs features.

In this case, the duplication helped me ensure the data is correct.

I could imagine adding a requires property to link these subfeatures to each other, ensuring they are within the support version range both of their parent feature, and the linked "required" feature.

Edit: That said, if you prefer that I delete the duplicates, I can drop them.

@caugner caugner requested a review from Elchi3 October 17, 2025 11:59
@Elchi3
Copy link
Member

Elchi3 commented Oct 17, 2025

I would like a second opinion if the duplication makes sense. Maybe @ddbeck?

Copy link
Contributor

@ddbeck ddbeck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't love the duplication, though I can kinda-sorta see a way of doing it that is more idiomatic:

The subfeatures of the html.elements.input.* features ought to be named list, representing support for the list attribute on that type. Since we treat the input types as if they were different elements, we can represent support for list as if it was an attribute unique to each input type (i.e., act as though <input type="color"> is <input-color>, then the subfeature is <input-color list="…">.

In this scenario, the duplication would be at the point of html.elements.datalist.input_type_*. Since <datalist> is the new thing, I think duplicating this data on html.elements.datalist makes sense as a convenience to MDN readers.

If we do this, I think there's a case to be made to remove html.elements.input.list as needless duplication (since it would be a duplicate of html.elements.input.text.list) and confusing (does it mean support for all types? At least one? Something else?).

(This makes me wish we had some sort of annotation in the data, something like canonical: "html.elements.input.color.list" on keys that duplicate other keys.)

"version_added": "4",
"version_removed": "110",
"partial_implementation": true,
"notes": "The `<datalist>` element will only create a dropdown for textual types, such as `text`, `search`, `url`, `tel`, `email` and `number`. The `date`, `time`, `range` and `color` types are not supported."
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not all of the types mentioned in the note are represented by the subfeatures. The PR title had me anticipating keys like this:

  • html.elements.datalist
  • html.elements.datalist.input_type_color
  • html.elements.datalist.input_type_date
  • html.elements.datalist.input_type_email
  • html.elements.datalist.input_type_number
  • html.elements.datalist.input_type_range
  • html.elements.datalist.input_type_search
  • html.elements.datalist.input_type_tel
  • html.elements.datalist.input_type_text
  • html.elements.datalist.input_type_time
  • html.elements.datalist.input_type_url

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR only extracts these four from existing data:

  • html.elements.datalist.input_type_color
  • html.elements.datalist.input_type_date
  • html.elements.datalist.input_type_range
  • html.elements.datalist.input_type_time

The current data suggests to me the following textual types were always supported:

  • html.elements.datalist.input_type_email
  • html.elements.datalist.input_type_number
  • html.elements.datalist.input_type_search
  • html.elements.datalist.input_type_tel
  • html.elements.datalist.input_type_text
  • html.elements.datalist.input_type_url

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

data:html Compat data for HTML elements. https://developer.mozilla.org/docs/Web/HTML size:l [PR only] 101-1000 LoC changed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants