Re: [whatwg] Form Controls Wish List

Hi Garret,

I'd really encourage you to read the WHATWG FAQ. In particular, the part urging you to focus on presenting compelling use cases, instead of specific APIs or solutions. Many of your suggestions are not motivated by use cases, from what I can see, and in fact would actively harm developers by breaking backward compatibility with existing content.

With that in mind, after reading the FAQ, I'd urge you to come back with those of your requests that still remain in the form of use cases only, with *no* specific API proposals.

If this seems like a strange way of doing business, I can only say ... The FAQ explains it much better than me :)
________________________________
From: Garrett Smith<mailto:dhtmlkitchen@gmail.com>
Sent: ý2014-ý07-ý10 21:03
To: WHAT Working Group<mailto:whatwg@lists.whatwg.org>
Subject: [whatwg] Form Controls Wish List

Here's what I want.

1.       Form `dirty` property. Set to false, initially. Set to true
when the user has interacted with any of the form's controls to make
them dirty.

2.       HTMLFormControl. Why is there no HTMLFormControl interface? I
see HTMLFormControlsCollection but no HTMLFormControl. HTMLElement
doesn't cover HTMLSelectElement. I see a 'listed' category. Why no
interface defining HTMLFormControl?

3.       To determine if a form control is eligible for success (see
below) `HTMLFormControl.isEnabled`

4.       To get the value of a form's enabled controls as a string:
HTMLFormElement.serialize(type, callbackFunction). `type` can be
"json" or "query".

5.       Set the value of a form's controls using
HTMLForm.revive(object[, metaReviver])



(3) Disabled Fieldset
Disabling a fieldset disables its descendant controls but does not
change their disabled property. Thus, a disabled fieldset's descendant
controls won't succeed, however, its descendant controls' `disabled`
property can be true.



>From what I understand, the word "disabled" it appears in HTML5 is
overloaded to describe the following three different things:

1)      The form control's disabled `property` *

2)      The form control's disabled attribute (content attribute) **

3)      The form control's eligibility for success. ***


I propose changing one of these -- the last -- to the positive sense
-- isEnabled, and exposing that in the DOM. Because it's not so useful
to have a form whose disabled property is false but the form is
"disabled" due to being a descendant of a disabled fieldset.

The proposed form control `isEnabled` property determines if the
control is eligible for success. This property exists for the purpose
of handling the situation where a control's `disabled` property is
false and the control is a descendant of a disabled fieldset. In this
case, the control's `isEnabled` property and disabled property will
both be false and the control will not be eligible for success.

 *    http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#htmlinputelement
 **    http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-disabled
 ***    http://dev.w3.org/html5/spec-preview/attributes-common-to-form-controls.html#enabling-and-disabling-form-controls


"A form control is disabled if its disabled attribute is set, or if it
is a descendant of a fieldset element whose disabled attribute is
set..."

Disabling fieldsets is potentially quite useful; it just needs better
support and a better DOM api for nested controls.

That's my wishlist for forms.
--
Garrett
@xkit
ChordCycles.com
garretts.github.io

Received on Friday, 11 July 2014 04:17:11 UTC