Form Participation API

[tkent-google]

Bonjour TAG,

I'm requesting a TAG review of:

• Name: Form Participation API
• Specification URL: No specification pull requests yet. This will be a part of HTML.
• Explainer, Requirements Doc, or Example code: https://docs.google.com/document/d/1JO8puctCSpW-ZYGU8lF-h4FWRIDQNDVexzHoOQ2iQmY/edit?usp=sharing
• Tests: Not yet.
• Primary contacts: @tkent-google

Further details (optional):

• Relevant time constraints or deadlines: None. But we'd like to have feedback in a few months.
• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• I have reviewed the TAG's API Design Principles

You should also know that...

We understand the proposal doesn't follow "3.2. Events are for notification" and "3.3. Favor asynchronous events" in the Design Principles.

We'd prefer the TAG provide feedback as (please select one):

• open issues in our Github repo for each point of feedback
• open a single issue in our Github repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

[travisleithead]

Hey! Had a chance to take a preliminary look at this... Of the two major features introduced, the event part seems pretty nice; the custom elements integration part raises a lot of major questions. Just focusing on the event part:

Q: formdata event is fired last in sequence. This means validation has been done previously. As developers will want to add their own data into the form submission (via formData), would they want to have that data validated? Assuming if programmatically added, then data can be synchronously validated.

Q: 'formdata' is synchronous (https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#form-submission-algorithm) which means that it will be possible to submit another form (or the same form) from within the form submission steps with this event. This could lead to problems, and should probably be protected. (Possible options include changing the form submission steps to go in-parallel after firing the submit event and queue the formdata event, or limit re-entrancy by adding a form-submit-in-progress flag or similar.

[tkent-google]

Thank you for the comment.

Q: formdata event is fired last in sequence. ...

I assume developers rarely want to validate data for formdata event because the data is not user-editable. The situation is same as <input type=hidden>, which is not capable for validation.

Adding formData IDL attribute to submit event, instead of adding new formdata event, would make it possible to cancel form submission by validating such data and preventDefault(). However it isn't an option because new FormData(form) should collect data and it doesn't submit submit event.

I'd like to start with the current design. If many developers want to cancel form submission in formdata event handlers, we can make the event cancelable later.

Q: 'formdata' is synchronous ...

Yeah, form submission in formdata event handlers would make infinite loop. I'll add a flag to avoid re-entrancy.

[tkent-google]

I updated the document.

• Reflect the second Q in the Travis's comment
• Updated a way to obtain ElementInternals instance to follow TPAC 2018 discussion and the following discussion.

[tkent-google]

I'd like to start to merge the proposal to the HTML specification. Are there any feedbacks?

[markcellus]

Is there any reason why the proposal is in a Google doc? And not in a markdown file inside of a pull request?
I'd like to make suggestions/comments on certain lines of the proposal in github that are preserved rather than buried in a Google document. I'd also prefer if my comments were not associated with my google account.

[tkent-google]

@mkay581 You can add comments to the doc without your Google account.

The proposal was initially reviewed in Google, and the TAG review process doesn't ask to provide proposals in markdown as pull requests. So I have no reason to change the form of the proposal.

[markcellus]

Sure. But these types of subtle inconveniences are what I believe keeps the open-source community fragmented. You don't (and probably shouldn't) need a hard authoritative rule just to make things convenient for the community.

Having it in github makes things like this easier to request comments on both before and after this is potentially considered. Having it in a separate document doesn't keep it versioned under github after this has been reviewed. And I don't see there being any dedicated Github repo for this proposal.

Anonymous Comments on a google doc (without logging in) doesn't give me any type of notifications on version changes or other comments. If changes can be made to it in Google and nobody is aware, it just defeats the whole purpose of this being an open community-involved process.

[tkent-google]

Specification PRs:
* Event-based form participation: whatwg/html#4239 (merged)
* ElementInternals part of form-associated custom elements: whatwg/html#4324
* Remaining of form-associated custom elements: whatwg/html#4383 (This contains the above one)

[dbaron]

While I don't think it's a big deal, I'd note that I think the answers to the first two questions in the Security and Privacy self-review are a little suspicious -- users frequently do put personally-identifiable information or high-value data into form controls. But I don't think this proposal is substantially changing the characteristics that the web already has given its existing form controls, so I don't immediately see anything to worry about.

[lknik]

Discussing it at Reykjavik F2F.

[tkent-google]

@lknik
What's the outcome of the discussion?

[lknik]

@tkent-google did you answer @dbaron somewhere?

[tkent-google]

did you answer @dbaron somewhere?

No, I didn't.

@dbaron's comment is right. The self-review was probably incorrect. However, it doesn't affect this API proposal. PII handling with this proposal is same of existing form control elements, and JavaScript code can get PII which users put into fields.

[hober]

Hi, @tkent-google!

We briefly discussed this on our telcon tonight. Overall, we like the shape of the API and don't have any particular concerns to raise that haven't already come up. Thanks for bringing this to our attention!