- From: Joshua Peek <josh@joshpeek.com>
- Date: Sat, 22 Feb 2014 10:07:27 -0600
- To: public-webapps@w3.org
Overall this seems like a great direction. The most important use case
for me is using custom elements to implement new form controls.
Having custom elements included in form#elements seems pretty
essential. Most existing form serializers basically use form#elements,
input#name and input#.value. See jQuery's $.fn.serializeArray for an
example. Implementing form#elements with "participants" and a
element#formData convention seems like a good strategy.
> Do we really want a getter on element here? Isn’t it better to model it as elements listening to “submit” event on the associated form element and calling addParticipate in the event listener?
Attaching behavior to submit events is how developers implement this
kind of thing today. On submit, inject a bunch of hidden inputs with
your custom control's form data.
This has a few problems with integrating into custom validity checks
and reseting form state. The submit event can be canceled which most
library authors just tend to ignore.
To add to this, how do custom elements deal with "reset" and default
state? Like submit, the reset event can be canceled, so you can't
simply listen for reset events.
On Thu, Feb 20, 2014 at 4:09 PM, Edward O'Connor <eoconnor@apple.com> wrote:
> +public-webapps, -www-tag in replies to avoid cross-posting
>
> Hi,
>
> Domenic wrote, to www-tag:
>
>> [C]an shadow DOM be used to explain existing elements, like <video> or
>> <input type="range">, in terms of a lower-level primitive?
>>
>> As of now, it seems like it cannot, for two reasons:
>>
>> 1. Native elements have extra capabilities which are not granted by
>> shadow DOM, or by custom elements. For example, they can participate
>> in form submission.
>
> Authors need to be able to participate in form submission, but this is
> independent of Custom Elements.
>
> Web applications often maintain state in JS objects that have no direct
> DOM representation. Such applications may want such state to be
> submittable.
>
> Existing form elements map one field name to many values. People often
> build custom controls precisely because those controls hold more
> complex values that would be better represented as many names to many
> values. Subclassing existing form elements don't get you this.
>
> And inheriting from HTMLInputElement is insane (not because inheriting
> is insane, but because HTMLInputElement is insane), so that's not really
> how we want author-defined objects to become submittable.
>
> Given the above I don't think we should try to solve the "how authors
> can participate in form submission" problem by enabling the subclassing
> of existing form elements. Instead, we should define a protocol
> implementable by any JS object, which allows that JS object to expose
> names and values to the form validation and submission processes.
>
> Something like this:
>
> function Point(x, y) {
> this.x = x;
> this.y = y;
> }
> Point.prototype.formData = function() {
> return {
> "x": this.x,
> "y": this.y
> };
> }
>
> var theForm = document.querySelector("#my-form");
>
> var p = new Point(4,2);
>
> theForm.addParticipant(p);
> theForm.submit();
>
> This is obviously a super hand-wavy strawman and would need to be
> fleshed out. Thoughts?
>
>
> Ted
>
Received on Saturday, 22 February 2014 16:07:55 UTC