W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

Re: Form submission participation (was Re: Goals for Shadow DOM review)

From: Charles Pritchard <chuck@jumis.com>
Date: Thu, 20 Feb 2014 14:19:26 -0800
Message-Id: <7AB11B5F-2056-4E4B-8664-0CA906754B42@jumis.com>
Cc: "www-tag@w3.org" <www-tag@w3.org>, "public-webapps@w3.org" <public-webapps@w3.org>
To: "public-webapps@w3.org" <public-webapps@w3.org>

> On Feb 20, 2014, at 2: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

Sounds like a great idea; can that kind of thinking also be applied to HTMLMediaElement interfaces  for custom video/audio handling with play/pause buttons?

There are some tricks with streams but it'd be really nice to be able to essentially use <video controls> with custom elements backed by media sources like SVG and Canvas.

Not to derail the conversation... I think you're absolutely on the right track.

Received on Thursday, 20 February 2014 22:19:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:22 UTC