Re: Form submission participation (was Re: Goals for Shadow DOM review)
On Thu, Feb 20, 2014 at 10:51 PM, Domenic Denicola wrote: > I wonder if the existing `FormData` objects have something to say here? Could > we use them? Are they constructible yet? (Are the constructors as easy to use > as the syntaxes you propose?) Presumably the spec for those encapsulates most > of the complexities involved here already. I recommend reading it, it's not too long: http://xhr.spec.whatwg.org/#interface-formdata -- http://annevankesteren.nl/
Re: Form submission participation (was Re: Goals for Shadow DOM review)
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 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 or
>> , 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
>
Re: Form submission participation (was Re: Goals for Shadow DOM review)
On Feb 21, 2014, at 2:12 PM, Edward O'Connor wrote: > Ryosuke wrote: > >> What if we added "formparticipant" boolean content attribute and fired >> "formdata" event during form submission to serialize data? >> >> This way, we can add more events like "validate" to support more >> features of builtin form elements. > > Hmm, right, validation. In the model I have in my head, there are > roughly two kinds of custom form participants: custom form controls > (probably implemented with custom elements & other web components > features) and "application state" (JS objects with no corresponding DOM > presence but that nevertheless should be submittable). > > Suppose in the first case we add a nonconfigurable boolean property to > Element. The engine inspects this property to determine validity, and > it's the responsibility of the component to keep the property up to > date. That way, we don't have to invoke userland JS when performing form > validation or when resolving :valid/:invalid style rules. Right. We may want to move "willValidate", "validity", "validationMessage", "checkValidity()", "reportValidity()" and "setCustomValidity(DOMString error)" IDL attributes from HTMLInputElement to HTMLElement, and make ValidityState's IDL attributes settable on HTMLElement or add a method to update validity states. > In the second case, I think we can just punt completely—form > participants that aren't Elements don't participate in validation, only > submission. Because it's the application's responsibility for > maintaining its own state, there's no sensible visual location in the > document to display a validation error, and no no-application-specific > way for the user to resolve the issue. Right. Since HTML spec already assumes some UI to exist to show validation messages for builtin form controls, I don't think it makes sense for UA to validate form data not associated with any element in the document. - R. Niwa
Re: Form submission participation (was Re: Goals for Shadow DOM review)
On Feb 21, 2014, at 2:28 PM, Ian Hickson wrote:
> On Fri, 21 Feb 2014, Maciej Stachowiak wrote:
>>
>> I'd guess most sophisticated webapps do not use attribute-based event
>> handlers (as opposed to addEventListener), so they would not get this
>> convenient scoping benefit.
>
> That's not clear to me. I mean, certainly today, with div soup, they
> don't. But that's at least partly because there's no sane way to do it
> when your markup isn't really declarative in any useful sense.
>
> When you have Web components that let you get the effect you want while
> sticking to a terse markup language, it becomes much more feasible to
> return to using inline event handlers.
Might be, but I'm not sure you can center a design on a hypothetical future
change in web developer behavior.
>
>> If you're looking at an out-of-line function, then your comparison is:
>>
>> this.a.value = process(value)
>> this.querySelector("#a").value = process(value)
>>
>> which is a less dramatic difference.
>
> It's a pretty compelling difference, IMHO.
>
>
>> Also, the short version gives you the risk of namespace conflicts with
>> the built-in methods and properties of form.
>
> You can do this instead if that feels like a real risk:
>
> this.elements.a.value = process(value)
Which is hardly an upgrade at all over:
this.querySelector("#a").value = process(value)
Cheers,
Maciej
Re: Form submission participation (was Re: Goals for Shadow DOM review)
On Fri, 21 Feb 2014, Maciej Stachowiak wrote:
>
> I'd guess most sophisticated webapps do not use attribute-based event
> handlers (as opposed to addEventListener), so they would not get this
> convenient scoping benefit.
That's not clear to me. I mean, certainly today, with div soup, they
don't. But that's at least partly because there's no sane way to do it
when your markup isn't really declarative in any useful sense.
When you have Web components that let you get the effect you want while
sticking to a terse markup language, it becomes much more feasible to
return to using inline event handlers.
> If you're looking at an out-of-line function, then your comparison is:
>
> this.a.value = process(value)
> this.querySelector("#a").value = process(value)
>
> which is a less dramatic difference.
It's a pretty compelling difference, IMHO.
> Also, the short version gives you the risk of namespace conflicts with
> the built-in methods and properties of form.
You can do this instead if that feels like a real risk:
this.elements.a.value = process(value)
...but in practice I think it's a pretty minimal risk.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Form submission participation (was Re: Goals for Shadow DOM review)
On Fri, Feb 21, 2014 at 2:28 PM, Ian Hickson wrote: > On Fri, 21 Feb 2014, Maciej Stachowiak wrote: >> >> I'd guess most sophisticated webapps do not use attribute-based event >> handlers (as opposed to addEventListener), so they would not get this >> convenient scoping benefit. > > That's not clear to me. I mean, certainly today, with div soup, they > don't. But that's at least partly because there's no sane way to do it > when your markup isn't really declarative in any useful sense. > > When you have Web components that let you get the effect you want while > sticking to a terse markup language, it becomes much more feasible to > return to using inline event handlers. Also the fact that a lot of markup is generated on the server also makes it less interesting to stick the code in the markup. Code generating code is messy and error prone. Also, code in attributes tend to mainly be readable when the code is *really* short. In your example you end up calling out into an external process function. However it could well be less code to avoid the process() function entirely and just have all the processing inline. But that likely will require putting the whole thing outside of an attribute. Other reasons are that the scope chaining for code in attributes, and especially in attributes of form controls, makes the code more error prone. It means that your code risks breaking any time that we add new properties to elements. Finally increased interest in using CSP and preventing XSS has increased incentive to put code outside the markup. I'm certainly not opposed creating something with proxy-like syntax, at least if we check that that's something that developers are really asking for and that implementations are interested in implementing (this thread calls both into question). However I think .elements is still a bad API due to its live-ness and due to not including all form controls. And if we get rid of the liveness that makes it much more possible to use the type of API I drafted. We'd simply have getParticipants() return something that has proxy behavior. / Jonas
Re: Form submission participation (was Re: Goals for Shadow DOM review)
Hi, Ryosuke wrote: > What if we added "formparticipant" boolean content attribute and fired > "formdata" event during form submission to serialize data? > > This way, we can add more events like "validate" to support more > features of builtin form elements. Hmm, right, validation. In the model I have in my head, there are roughly two kinds of custom form participants: custom form controls (probably implemented with custom elements & other web components features) and "application state" (JS objects with no corresponding DOM presence but that nevertheless should be submittable). Suppose in the first case we add a nonconfigurable boolean property to Element. The engine inspects this property to determine validity, and it's the responsibility of the component to keep the property up to date. That way, we don't have to invoke userland JS when performing form validation or when resolving :valid/:invalid style rules. In the second case, I think we can just punt completely—form participants that aren't Elements don't participate in validation, only submission. Because it's the application's responsibility for maintaining its own state, there's no sensible visual location in the document to display a validation error, and no no-application-specific way for the user to resolve the issue. Thoughts? Ted
RE: Form submission participation (was Re: Goals for Shadow DOM review)
From: Ryosuke Niwa > What if we added "formparticipant" boolean content attribute and fired > "formdata" event during form submission to serialize data? I don't understand the virtue of this inverted model, where controls are responsible for listening to their containing form and reacting to it. The original proposal, of the form just asking the control for information via methods, seems much more sensible. It matches how I think of parent-child relationships.
Re: Form submission participation (was Re: Goals for Shadow DOM review)
On Feb 20, 2014, at 2:39 PM, Jonas Sicking wrote:
> On Thu, Feb 20, 2014 at 2:09 PM, Edward O'Connor 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 or
>>> , 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?
>
> Something like this seems awesome! I like that the .addParticipant
> function can enable random JS objects to participate in submission. A
> couple of comments though:
>
>
> I'm not sure if we should return a dictionary or an array. Keep in
> mind that a form control can have multiple values. This is something
> used by both and . Also keep in mind
> that order matters as many servers are sensitive to order.
>
> So we could either do `return { x: [5, 6, 7] }` where enumeration
> order determines submission order, or we could do `return [["x", 5],
> ["x", 6], ["x", 7]]`.
>
> Or, given that normally a single form control only has a single name
> and 0 to many values, we could do `return { name: "x", value: [5, 6,
> 7] }`.
>
>
> The other thing is that it would be great if elements that wanted to
> participate in submission didn't have to manually call addParticipant.
> This could be done by having the element attempt check for a
> .formData property on any descendant that was added, and add any
> elements that has such a property as a participant automatically.
>
> We could even make the built-in form controls like and
> have a .formData() function which returns data in whatever
> format we decide is the right one.
What if we added "formparticipant" boolean content attribute and fired
"formdata" event during form submission to serialize data?
This way, we can add more events like "validate" to support more features of
builtin form elements.
- R. Niwa
Re: Form submission participation (was Re: Goals for Shadow DOM review)
On Feb 21, 2014, at 11:04 AM, Ian Hickson wrote:
> On Thu, 20 Feb 2014, Jonas Sicking wrote:
>> On Thu, Feb 20, 2014 at 2:51 PM, Edward O'Connor wrote:
>>>
>>> Yeah, I think we just say that [form.elements] is the legacy feature
>>> that only exposes built-in controls. form.getParticipants() works for
>>> me.
>>
>> Agreed. [form.elements] is pretty crappy anyway in that it's live and
>> that it doesn't include elements for webcompat
>> reasons (stemming from an old Netscape bug :))
>
> I actually think form.elements is more important than form submission, as
> far as custom form controls go.
>
> Pages with custom form controls are highly likely, I would guess, to be
> interactive apps that don't have any unscripted form submission. I would
> expect lots of XHR, WebSockets, and the like. However, scripts are hugely
> simplified by form.elements. Instead of having to grab things by ID, you
> can just name them, for example. This is even more true for event handlers
> on form controls, which have the form in the scope chain. For example, one
> of the big reasons for adding was that it makes it easier to
> update text -- instead of:
>
> oninput="document.getElementById('a').textContent = process(value)"
>
> ...you can write:
>
> oninput="a.value = process(value)"
I'd guess most sophisticated webapps do not use attribute-based event handlers
(as opposed to addEventListener), so they would not get this convenient scoping
benefit. If you're looking at an out-of-line function, then your comparison is:
this.a.value = process(value)
this.querySelector("#a").value = process(value)
which is a less dramatic difference. Also, the short version gives you the risk
of namespace conflicts with the built-in methods and properties of form.
Regards,
Maciej
Re: Form submission participation (was Re: Goals for Shadow DOM review)
On Feb 20, 2014, at 2:51 PM, Edward O'Connor wrote: >> We could even make the built-in form controls like and >> have a .formData() function which returns data in whatever >> format we decide is the right one. > > Right. toFormData() or the like, parallel to toJSON(). 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? - R. Niwa
Re: Form submission participation (was Re: Goals for Shadow DOM review)
On Thu, 20 Feb 2014, Jonas Sicking wrote:
> On Thu, Feb 20, 2014 at 2:51 PM, Edward O'Connor wrote:
> >
> > Yeah, I think we just say that [form.elements] is the legacy feature
> > that only exposes built-in controls. form.getParticipants() works for
> > me.
>
> Agreed. [form.elements] is pretty crappy anyway in that it's live and
> that it doesn't include elements for webcompat
> reasons (stemming from an old Netscape bug :))
I actually think form.elements is more important than form submission, as
far as custom form controls go.
Pages with custom form controls are highly likely, I would guess, to be
interactive apps that don't have any unscripted form submission. I would
expect lots of XHR, WebSockets, and the like. However, scripts are hugely
simplified by form.elements. Instead of having to grab things by ID, you
can just name them, for example. This is even more true for event handlers
on form controls, which have the form in the scope chain. For example, one
of the big reasons for adding was that it makes it easier to
update text -- instead of:
oninput="document.getElementById('a').textContent = process(value)"
...you can write:
oninput="a.value = process(value)"
More concretely:
00:00 – 24:00
...or:
+
=
Similarly, in a script block you can get form controls by name from forms
gotten by name:
document.forms.main.elements.result.value = 'Hello World';
document.forms.npc.elements.char.value = getRandomName();
This gives you a much more intuitive way of figuring out what's going on.
You can tell what form the controls are from, and the name just fits into
the code without appearing to involve string manipulation, the way that
getElementById() or querySelector() would.
(The last four examples above are all from the HTML spec.)
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Form submission participation (was Re: Goals for Shadow DOM review)
On Thu, Feb 20, 2014 at 2:51 PM, Edward O'Connor wrote:
>> This could be done by having the element attempt check for a
>> .formData property on any descendant that was added, and add any
>> elements that has such a property as a participant automatically.
>
> That doesn't handle this case:
>
>
>
> I'd like a way to declaratively say that that contenteditable
> participates with name foo.
>
> The obvious thing would be to literally add name=foo, but that doesn't
> work because of
>
>
>
> so we'd need a different attribute name. participant=foo or something.
Is it really going to be a common case to want to submit a
contenteditable declaratively? I feel like in most cases using
contenteditable requires writing heaps of javascript. In part because
contenteditable implementations generally sucks and there's been a
historical lack of specs, but also because in many cases you don't
want a freeform HTML editor, but rather an editor of some other data
model that your page contains.
For example the contenteditable i'm typing in right now in gmail
attempts to implement en email editor, not a generic HTML editor.
In these cases you'd likely also want to submit something other than
the serialization of the markup in the contenteditable element.
However, if we do want to allow script-less form submission of
contentediable then I think having a "participant=foo" attribute would
work. We could define that when that attribute is set .formData goes
from returning null to returning a function. It's a bit weird but it'd
work. I assume that the function would return something like { name:
this.participant, value: this.innerHTML }?
>> The only tricky part is that form.controls is a live array. I don't
>> see a way of making form.controls contain custom elements without
>> synchronously running getters whenever an element is added as a
>> descendant of a , which is not something we want to do. But live
>> arrays are evil anyway so we can probably just ignore integration with
>> that and instead add a form.getParticipants() function which returns a
>> non-live array of all participants.
>
> Yeah, I think we just say that form.controls is the legacy feature that
> only exposes built-in controls. form.getParticipants() works for me.
Agreed. form.controls is pretty crappy anyway in that it's live and
that it doesn't include elements for webcompat
reasons (stemming from an old Netscape bug :))
/ Jonas
RE: Form submission participation (was Re: Goals for Shadow DOM review)
From: Jonas Sicking > I'm not sure if we should return a dictionary or an array. Keep in mind that > a form control can have multiple values. This is something used by both > and . Also keep in mind that order matters > as many servers are sensitive to order. I wonder if the existing `FormData` objects have something to say here? Could we use them? Are they constructible yet? (Are the constructors as easy to use as the syntaxes you propose?) Presumably the spec for those encapsulates most of the complexities involved here already. > The other thing is that it would be great if elements that wanted to > participate in submission didn't have to manually call addParticipant. This > could be done by having the element attempt check for a .formData > property on any descendant that was added, and add any elements that has such > a property as a participant automatically. I really like this idea and the subsequent paragraphs in which you flesh it out. Makes great sense to me.
Re: Form submission participation (was Re: Goals for Shadow DOM review)
Hi Jonas, You wrote: > I'm not sure if we should return a dictionary or an array. Yeah, it should be an array. > The other thing is that it would be great if elements that wanted to > participate in submission didn't have to manually call addParticipant. Yes. > This could be done by having the element attempt check for a > .formData property on any descendant that was added, and add any > elements that has such a property as a participant automatically. That doesn't handle this case: I'd like a way to declaratively say that that contenteditable participates with name foo. The obvious thing would be to literally add name=foo, but that doesn't work because of so we'd need a different attribute name. participant=foo or something. > We could even make the built-in form controls like and > have a .formData() function which returns data in whatever > format we decide is the right one. Right. toFormData() or the like, parallel to toJSON(). > The only tricky part is that form.controls is a live array. I don't > see a way of making form.controls contain custom elements without > synchronously running getters whenever an element is added as a > descendant of a , which is not something we want to do. But live > arrays are evil anyway so we can probably just ignore integration with > that and instead add a form.getParticipants() function which returns a > non-live array of all participants. Yeah, I think we just say that form.controls is the legacy feature that only exposes built-in controls. form.getParticipants() works for me. Ted
Re: Form submission participation (was Re: Goals for Shadow DOM review)
On Thu, Feb 20, 2014 at 2:09 PM, Edward O'Connor 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 or
>> , 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?
Something like this seems awesome! I like that the .addParticipant
function can enable random JS objects to participate in submission. A
couple of comments though:
I'm not sure if we should return a dictionary or an array. Keep in
mind that a form control can have multiple values. This is something
used by both and . Also keep in mind
that order matters as many servers are sensitive to order.
So we could either do `return { x: [5, 6, 7] }` where enumeration
order determines submission order, or we could do `return [["x", 5],
["x", 6], ["x", 7]]`.
Or, given that normally a single form control only has a single name
and 0 to many values, we could do `return { name: "x", value: [5, 6,
7] }`.
The other thing is that it would be great if elements that wanted to
participate in submission didn't have to manually call addParticipant.
This could be done by having the element attempt check for a
.formData property on any descendant that was added, and add any
elements that has such a property as a participant automatically.
We could even make the built-in form controls like and
have a .formData() function which returns data in whatever
format we decide is the right one.
This way custom elements could very easily and automatically
participate in submission by simply declaring a .formData property.
The only tricky part is that form.controls is a live array. I don't
see a way of making form.controls contain custom elements without
synchronously running getters whenever an element is added as a
descendant of a , which is not something we want to do. But live
arrays are evil anyway so we can probably just ignore integration with
that and instead add a form.getParticipants() function which returns a
non-live array of all participants.
/ Jonas
Re: Form submission participation (was Re: Goals for Shadow DOM review)
> On Feb 20, 2014, at 2:09 PM, Edward O'Connor 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 or
>> , 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 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.
-Charles
Form submission participation (was Re: Goals for Shadow DOM review)
+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 or
> , 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
