Skip to content
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

Add <form> element #1440

Merged
merged 6 commits into from
Aug 14, 2024
Merged

Add <form> element #1440

merged 6 commits into from
Aug 14, 2024

Conversation

petele
Copy link
Collaborator

@petele petele commented Jul 16, 2024

Used compute_from: html.elements.form

@github-actions github-actions bot added the feature definition Creating or defining new features or groups of features. label Jul 16, 2024
@foolip
Copy link
Collaborator

foolip commented Jul 18, 2024

This is a bit similar to <table> in that it's a collection of elements, but unlike <table> some of the elements can be used outside of <form>, like <button>.

@petele if we called this "Forms" like "Tables", are there any additional bits you think should be included, that don't make sense as standalone features?

Also paging @captainbrosset @ddbeck for thoughts on feature organization.

@petele
Copy link
Collaborator Author

petele commented Jul 18, 2024

I'll advocate for creating a separate feature for each of the <form> related elements.

  • It would be a large feature with 11 elements, and many APIs included (leaving out <button>, including <form>)
  • Most of the features landed at the very early, but some are significantly later, for example <datalist> which is Chrome 69. If there's a new form element in the future, it'll need its own entry.
  • We may want to split <input> into the different types of input it supports, eg search, date, password, etc
  • <button> would logically go in here, but can be used outside forms, so it would be in an awkward place
  • We are already tagging these as group: forms

@ddbeck
Copy link
Collaborator

ddbeck commented Jul 19, 2024

What about splitting the difference a little bit? I could imagine some sort foundational Forms feature consisting of a really, really stripped down thing:

  • html.elements.form and descendants
  • api.HTMLFormElement and descendants
  • html.elements.input.type_text
  • html.elements.input.type_submit

It'd be part of the forms group, but it'd let us be free to handle the various input types as separate features.

@petele
Copy link
Collaborator Author

petele commented Jul 19, 2024

I'm not yet convinced combining them is the way to go. Including some keys but not others feels very arbitrary, and adds complexity about where someone might find something. Is it in the core Form feature, or is it in the element?

Copy link
Collaborator

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

This looks good. Safari showing DOM API support before the element itself is a bit weird. I filed mdn/browser-compat-data#24135 as an experiment. Hoping that Florian et al. have some feedback on whether I/we should be doing that routinely.

@ddbeck
Copy link
Collaborator

ddbeck commented Aug 14, 2024

Also, for posterity: I haven't changed my mind exactly on the organization here, but I do feel like we might compose a feature, as suggested in #971. I think it'll be easier to sort out when we have all of the forms stuff complete.

@ddbeck ddbeck merged commit 75bb737 into web-platform-dx:main Aug 14, 2024
3 checks passed
@petele petele deleted the elem-form branch August 14, 2024 18:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature definition Creating or defining new features or groups of features.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants