Re: [whatwg] Form Controls Wish List

On 7/10/14, Domenic Denicola <domenic@domenicdenicola.com> wrote:
> 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.
>

The FAQ was not around when I first proposed form serialization in
2007. The term "Living Standard" which the FAQ describes did not exist
until after I argued to Ian Hickson, the case for not finishing HTML5,
when I argued that ("extensible design doesn't have a due date").


In response to the need for a compelling use case, the situation is as
Tobie pointed out: Serialize a form's successful controls as
name/value JSON to the server, and vice versa: to revive the form with
a server response.


Consider a private enterprise app with a form where the browser (1)
sends that form's data over the wire without reloading the page, and
(2) receives data from the server to populate form controls. In some
places, there is a nice 1:1 mapping of a json property name:value pair
to a form control name:value pair, but in other cases, it is necessary
to have an adapter in both in the serialization of the form and in the
repopulation of the form ("reviving"). For serialization, a
jsonReplacer is a function that is used for replacing gathered form
data, and a jsonReviver is a function used in repopulating form data
from the server.

Serialization could be an instance method of a form or a globally
accessible function.

So for the alternatives...

One alternative to form serialization is traditional form submission.
That works great. But today's apps use MVC Frameworks, and when
requirements dictate form submission without a page reload, then what?

One possibility might be to target the form an iframe. That can work.
But that limits the front end to query strings. The same problem holds
true form Image requests, which can work in the right context. And it
doesn't solve the problem of populating form values from the server so
if you need to do that, you'll have to write it.

If the backend is consuming and producing JSON and that is not going
to change for the application, then obviously, there is going to be a
lot of work on the front end. This is actually pretty common.

JSON can be built, while adding, removing, and modifying properties,
and then verified afterwards and then stringified to send the data the
server. The convenience of JSON outweighs the inconvenience of working
with forms, which might explain why so many applications do what I've
just described to be "pretty common".

That's what form serializers do. They're nothing new, but they're not standard.

Form serialization requires determining the successful form controls.
And to determine what successful controls are we have to look at HTML
4.01 and HTML5. Those specifications both state that disabled form
controls are not successful. And the problems implicit in my initial
post are (1) that "disabled" has a new, additional meaning in HTML 5
which is not easy to understand and (2) once understood, it is harder
yet to determine via the DOM. In other words, it's not easy to know if
a form control is "disabled" in the new sense of the word, because of
the FIELDSET disabled property.

The problem with FIELDSET being disabled with enabled controls is
partially my fault. I proposed that FIELDSET have a disabled property
and that it disable its nested controls. That proposal made it into
HTML5:

http://lists.w3.org/Archives/Public/public-html/2007Aug/0638.html

But the possibility of a control whose `disabled` property is false,
but is actually "disabled" in the new HTML 5 sense of the word is not
new; it has been the case of any OPTION inside a disabled OPTGROUP,
where the option.disabled is false, but the control can't be
interacted with by the user ("disabled" but not `disabled` (more on
this later)).

So now I'm following up, seven years later.

To serialize a form, the javascript will need to:

 1)  Figure out which controls are successful

 2)  Build a json string, possibly replacing user-specified keys with
the result of a user defined function.

 3)  Populate a form with values, from JSON, reviving those controls
with values created by a user-defined function.

There's no simple property check for knowing if a form control is
"disabled" in HTML5's third sense of the word. This makes step one
harder.

The application has to either (a) write a function to filter form
control values as it  accumulates them, or (b) accumulate everything
and the use the built-in function JSON.stringify(result, replacer). No
such option has for the form reviver; the application must use its own
function.

But take a step back; HTML5's third sense of the word "disabled" is
just confusing, as demonstrated above. It's confusing to have a
disabled control whose `disabled` property is false. At the very
least, HTML5 should use a term other than "disabled" to describe what
it wants. I think isEnabled is much better. What would it hurt to
expose `isEnabled` to the dom? I can think of two, and they're hardly
worth mentioning at this point. The benefit would be usefulness for
code that wants to determine if a form control is going to be
successful or not.

Browser vendors already must make the "actually disabled"
determination per HTML5. Exposing it to the DOM would as a readonly
property should not require much complexity.
-- 
Garrett
@xkit
ChordCycles.com
garretts.github.io

Received on Saturday, 12 July 2014 06:32:55 UTC