You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implicit submission allows things like pressing enter to automatically click a form's submit button.
In Chrome's current implementation of form-associated custom elements, pressing enter on a FACE will not trigger implicit submission. This is allowed by the spec, because the spec for implicit submission is quite vague. It kind of makes sense as a conservative default. We may want to tighten the spec to disallow any form of user-agent-provided implicit submission for FACE.
Web developers can get implicit submission behavior for their FACEs using code like
constTYPES_THAT_BLOCK=newSet(['text','search','url','tel','email','password','date','month','week','time','datetime-local','number']);this.addEventListener("keydown",e=>{if(e.keyCode===13){const{ form }=this.#internals;// Find the submit button// form.querySelector(':default') doesn't work due to 'form' content attribute.for(constcontrolofform.elements){if(control.matches(':default')){if(!control.disabled){control.click();}return;}}// If we reached here, there's no submit button.// See if there's a field that blocks implicit submission.if([..form.elements].find(el=>TYPES_THAT_BLOCK.has(el.type))===undefined){form.requestSubmit();}}});
This is not great:
It is a lot of boilerplate
It is easy to get wrong and miss some subtleties
It assumes implicit submission is done via the enter key, which is not guaranteed by the spec and may be different in different UAs.
The previous discussions were indicating that we should find a way to make it easy for web developers. There are two approaches.
One is an easymode that just lets you set a bit "make me implicitly submittable", e.g. this.#internals.implicitlySubmittable = true. Maybe we can also extend the list of elements that block implicit submission, with this.#internals.blocksImplicitSubmission = true.
The other is to improve the above code snippet by providing nicer building blocks. The result could be something like
this.addEventListener("requestimplicitsubmit",()=>{const{ form }=this.#internals;constbutton=form.defaultButton;if(button){if(!button.disabled){button.click();}}elseif(!form.implicitSubmissionBlocked){form.requestSubmit();}});
This version might still need this.#internals.blocksImplicitSubmission = true if we want to make that list extensible.
The text was updated successfully, but these errors were encountered:
See discussion starting around #187 (comment).
Implicit submission allows things like pressing enter to automatically click a form's submit button.
In Chrome's current implementation of form-associated custom elements, pressing enter on a FACE will not trigger implicit submission. This is allowed by the spec, because the spec for implicit submission is quite vague. It kind of makes sense as a conservative default. We may want to tighten the spec to disallow any form of user-agent-provided implicit submission for FACE.
Web developers can get implicit submission behavior for their FACEs using code like
This is not great:
The previous discussions were indicating that we should find a way to make it easy for web developers. There are two approaches.
One is an easymode that just lets you set a bit "make me implicitly submittable", e.g.
this.#internals.implicitlySubmittable = true
. Maybe we can also extend the list of elements that block implicit submission, withthis.#internals.blocksImplicitSubmission = true
.The other is to improve the above code snippet by providing nicer building blocks. The result could be something like
This version might still need
this.#internals.blocksImplicitSubmission = true
if we want to make that list extensible.The text was updated successfully, but these errors were encountered: