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

On Feb 21, 2014, at 11:04 AM, Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 20 Feb 2014, Jonas Sicking wrote:
>> On Thu, Feb 20, 2014 at 2:51 PM, Edward O'Connor <eoconnor@apple.com> 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 <input type=image> 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 <output> 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

Received on Friday, 21 February 2014 21:11:05 UTC