-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Extract HTML <datalist>
input type subfeatures
#28189
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs). |
360ac12
to
3d54188
Compare
There was a problem hiding this 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.
There was a problem hiding this 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?
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 Edit: That said, if you prefer that I delete the duplicates, I can drop them. |
I would like a second opinion if the duplication makes sense. Maybe @ddbeck? |
There was a problem hiding this 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." |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
Summary
Extracts HTML
<datalist>
input type subfeatures, and duplicates these belowhtml.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.