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 mos
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. S
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 bui
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 c
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
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 cle
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
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
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
>>> , i
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()
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 gette
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 prett
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:
>
>
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 `FormDa
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 th
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
> 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 seem
17 matches
Mail list logo
