Intent to Implement: An event to enable arbitrary objects to provide form data

111 views
Skip to first unread message

TAMURA, Kent

unread,
Mar 25, 2018, 10:58:24 PM3/25/18
to blink-dev

Contact emails

tk...@chromium.org


Explainer

https://docs.google.com/document/d/1JO8puctCSpW-ZYGU8lF-h4FWRIDQNDVexzHoOQ2iQmY/edit?usp=sharing

This intent is about "Proposal A" part of the explainer.


Summary

Add a new event so that arbitrary objects can provide form data.


Motivation

- Avoid to add many <input type=hidden> to a form to pass application status

- Make submittable custom elements


Risks

Interoperability and Compatibility

The risk is low. This is a small addition to the forms area. This was discussed in WebComponents F2F in March 2018, and we agreed on the approach of Proposal A though we haven't agreed on the API details yet.


Edge: Not opposed

Firefox: Public support

Safari: Public support

Web developers: Positive

See https://www.w3.org/2018/03/05-webplat-minutes.html#item09


Ergonomics

This feature might be used with Custom Elements frequently.


Activation

Polyfill would be helpful.



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5662230242656256


Requesting approval to ship?

No.

--
TAMURA Kent
Software Engineer, Google





Ojan Vafai

unread,
Mar 26, 2018, 2:27:31 PM3/26/18
to TAMURA, Kent, blink-dev
Very exciting! There's a lot of demand for this. The API surface all makes sense to me with one bikeshedding nit. Usually event names are verbs, so you might want a different name than "formdata." Maybe something like "serialize" or "serializeform"? Serialize is kind of a long word though. :(

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqHBbSWZeWVcr6kOQHahsvee%2BCiqy1z9eYEaUNSWxDsz-A%40mail.gmail.com.

TAMURA, Kent

unread,
Mar 28, 2018, 11:49:22 PM3/28/18
to smaug, Ojan Vafai, blink-dev
Let's discuss the event name on the GitHub issue.

On Tue, Mar 27, 2018 at 3:56 AM smaug <sm...@welho.com> wrote:
I thought the idea was to call the event beforesubmit.
As the meeting minutes say
"RESOLUTION: expose beforeSubmit and formdata is low hanging fruit."



-Olli



On 03/26/2018 09:27 PM, Ojan Vafai wrote:
> Very exciting! There's a lot of demand for this. The API surface all makes sense to me with one bikeshedding nit. Usually event names are verbs, so
> you might want a different name than "formdata." Maybe something like "serialize" or "serializeform"? Serialize is kind of a long word though. :(
>
> On Sun, Mar 25, 2018 at 7:58 PM TAMURA, Kent <tk...@chromium.org <mailto:tk...@chromium.org>> wrote:
>
>     Contact emails
>

>
> --
> You received this message because you are subscribed to the Google Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

Daniel Bratell

unread,
Mar 29, 2018, 11:10:59 AM3/29/18
to smaug, TAMURA, Kent, Ojan Vafai, blink-dev
This idea seems like a really good thing!
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqEsHRtTjooZoOQj8t9K1iAS8TOx%3DozL6zXZSiVVVDm0bw%40mail.gmail.com.



--
/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

bat...@chromium.org

unread,
Apr 3, 2018, 5:28:25 AM4/3/18
to blink-dev, Mathieu Perreault
Hi.

Am Montag, 26. März 2018 04:58:24 UTC+2 schrieb Kent Tamura:

Contact emails

tk...@chromium.org


Explainer

https://docs.google.com/document/d/1JO8puctCSpW-ZYGU8lF-h4FWRIDQNDVexzHoOQ2iQmY/edit?usp=sharing

This intent is about "Proposal A" part of the explainer.


Summary

Add a new event so that arbitrary objects can provide form data.


Motivation

- Avoid to add many <input type=hidden> to a form to pass application status

- Make submittable custom elements


Risks

Interoperability and Compatibility

The risk is low. This is a small addition to the forms area. This was discussed in WebComponents F2F in March 2018, and we agreed on the approach of Proposal A though we haven't agreed on the API details yet.


Implementing this with only Part A makes me a bit nervous because it would make features like autofilling address data, credit card data, passwords, etc. more difficult / break them, right?

Can we make it a goal to encourage designs by libraries that do not break autofill?

TAMURA, Kent

unread,
Apr 3, 2018, 10:17:35 PM4/3/18
to Dominic Battré, blink-dev, ma...@chromium.org
I have no concrete plan to ship this feature yet.
Let's discuss how to make it Autofill-friendly out of this thread.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
Reply all
Reply to author
Forward
0 new messages