[whatwg] Web Forms 2.0 comments

[Sander]

Hello all,

Unrelated to the main content of this message, perhaps it would be
worthwhile for the whatwg to state more clearly how the deliverables
are expected to be used, as not everyone seems to have the same idea on
this (or perhaps I am merely misunderstanding some of the messages sent
to this list up to this point).

As I understand it, the goal of the whatwg is to produce a final version
of the Web Forms 2.0 specification (+ related other specifications),
with the solid intent of having these implemented in Mozilla, Opera
(and Safari?) _in short order_, and at the same time to provide a set
of .htc files for web developers to include (in the same way as
stylesheets or javascript files are now included) in the websites
making use of the specified technologies, thereby assuring that the
vast majority of users will be able to benefit from these new
technologies almost overnight. (This is basically what has been said a
few times already, but I think it would be worthwhile plastering it in
a bold font on the front page or something. Or clearing up my confusion
if I'm wrong here.) :)



I have been impressed by how obviously right most of the proposed new
form controls are ever since I read the first (then) XForms Basic
draft, and now dedicating some more time to trying to find fault with
any of it, that's even more the case. 

Still, I have at least a few recommendations for changing the Web Forms
2.0 draft. The first is on the subject of the precision attribute.

Currently, the draft doesn't seem to allow (if I missed it, please
correct me) for selecting a numerical value with the least significant
figure as a multiple of a base value other than one. It's easy to
specify that allowed values will be [3, 4, 5, .., 10], or [0.51, 0.52,
0.53, .., 0.78], but almost impossible to do the same for [15, 20, 25,
.., 50] or [0.25, 0.5, 0.75, .., 5.0]. Select-boxes or validating
textual input still seem to be the only solutions, just as they are
right now (validating could perhaps be done with "pattern", but at the
cost of throwing away the semantics implied by "number" or "range"),
and this is not a very userfriendly solution (particularly when the
exact value does not matter to the end-user, but does matter further
upstream). Use-cases here could be found in "amount of posts per page"
for message boards, or ordering a liquid with the smallest container
size being 0.25 liters.

I therefore propose extending the precision attribute as currently
specified by also allowing a numerical value, any numerical value,
which would act as a "step" between possible numerical values to be
selected by the element. (Alternatively some other attribute could be
used for this, for example "step" or "increment", but it seems to me
the goal of this attribute would be the same as that of "precision" as
it currently exists, and therefore should be the same, plus additional
conflicts would arise in cases such as <input type="number"
precision="integer" step="0.5">)

The proposed numerical precision should start stepping up at the "min"
value. If no "min" value is specified, but a "max" value is, then it
should step down from the "max" value. If neither "min" nor "max" is
specified it should step up and down from 0.


Sideways related to this extension to precision, I have started
questioning the "range" input type. How would this act (aka, display)
without "min" and "max" values? And why shouldn't user agents display
input type="number" elements with "min" and "max" values (suitably
close together so that fine-grained control by the user remains
possible) as 'sliders'? The semantic value of this element seems
dubious, with it seemingly being included merely to force "display:
slider" on an element, despite section 9's claim of "UAs, in the
absence of such advanced styling information, may render form controls
described in this draft as they wish."
I propose dropping range and perhaps instead recommending that (lacking
styling hints to the contrary) user agents display all type="number"
input elements, with min and max values less than x steps apart, as
'sliders'.


The repeating form controls model is probably my favorite part of this
draft, and I will start using it at least in the CMSs for websites I
control as soon as Mozilla supports it, but I also see some semi-large
problems.
The one of these that I have reasonably clear for myself is... hmm, I
think the upcoming torturous sentence might be better replaced with an
example. Consider:

<div id="children" repeat="template">
<label for="ln_[children]">Last Name</label><input type="text"
id="ln_[children] name="lastname_[children]" tabindex="2">
<label for="fn_[children]">First Name</label><input type="text"
id="fn_[children] name="firstname_[children]" tabindex="1">
</div>
<repeat>
<repeat>
<repeat>

Replicating this template will completely mess up the tabbing, confusing
the user to no end (while the tabindex was added to _help_ the user do
input in the expected 'regular' order).
A first simple solution would be tabindex="[children]1", but this will
still lead to problems when the "index" attribute (or numerical
"repeat" attribute) has been set, or when move-up and/or move-down are
executed.
What I think is needed is a 'unique' incrementing index following the
DOM-order of all repetition blocks (unique for the page, not for the
template, so as to deal with nested templates; separate from the
already specified unique index for the template, which for good reasons
should never change). So when the third repetition element is moved-up,
this index becomes 2, while the index of the second repetition element
becomes 3. Syntax could be something like {DOMORDER}. Outside of usage
in the tabindex, I can also see this second index being useful
(included as "value" for a hidden input element) in conveying the final
order of elements in a more easily parseable way than simply the order
of elements in the submission, and possibly in min, max and precision
attributes in those rare cases where acceptable input depends on the
number of previous 'rows' in a form.
*grins* Okay, admittedly somewhat shaky ground there, but I do think the
tabindex usecase needs a solution.


Going right against the ideas for other useful ways to use this other
index, I think the parsing of [ID] (and, if included, {DOMORDER})
should be limited to just the "for", "headers", "id", "name" and
"template" attributes (and maybe also "cite", "href" and "src"), or at
least to exclude the "value" attribute. I am aware of more than one
clumsily coded web application which utilizes multiple screens and
stores the received values from the previous screen in the value of a
hidden input element. It is quite imaginable for such received input to
include text between square brackets which would match the id of a
repetition template, with obviously disastrous results. Although this
problem is mitigated by most such hidden inputs _probably_ not being
included in repetition templates, I can still imagine use cases where
this can happen. (Multiple search engine submission forms being one of
them.)


More on repetition: I find the existence of the <repeat> element next to
the repeat attribute with numerical value to be confusing. I suggest
dropping the latter. (Comparing against an older draft, I vaguely
suspect this already being the plan, with the necessary editing simply
not having been done yet.)

On which subject: Hixie, are you interested in editorial comments on the
Web Forms draft yet, or is it still too early for that?

Thanks for your attention, I hope my comments will be useful, 
Sander