[whatwg] Web Forms 2.0 comments

[Ian Hickson]

On Thu, 10 Jun 2004, Sander wrote:
>
> 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]. [... ]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.

   How much liquid would you like? (Quarter-litre increments)
   <input type="number" min="0.25" precision="float"
    oninput=" setCustomValidity((4 * value) % 1 == 0 ? null
            : 'The number provided is not in quarter-litre increments')">l


> 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">)

As in,

   How much liquid would you like? (Quarter-litre increments)
   <input type="number" min="0.25" precision="0.25">l

...? But then how would you do irregular steps? I guess we could do this.
I'm just worried about the slippery slope.

I've added your idea for now.


> 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?

Same as "number", probably.


> 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'?

Because I don't want to select how many widgets I want to buy using a
slider. Or enter my IP address using a slider.


> 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."

There's definitely a semantic difference between an exact number (e.g.  a
price or IP address) and a number whose exact value doesn't matter so much
(e.g. a sound volume or brightness value).


> <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).

Good point.


> *grins* Okay, admittedly somewhat shaky ground there, but I do think the
> tabindex usecase needs a solution.

I don't think your proposed solution is the best one. ;-)

How about some sort of attribute that says that "all the children of this
element are in their own local tab universe"?

I'll think about this.


> 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.)

Ouch, good point, a template might well include user-entered data that
might match that string. For that matter a script might contain [foo]
which happens to be the ID of the template.

I'm somewhat reluctant to just say "only do these attributes" since
there's bound to be use cases where you need to do it that haven't been
covered. Like, in fact, value (there are some interesting use cases that
involve only using it in value, instead of name, and some cases where
you would want to affect the scripts).

Any other ideas for solving this?


> 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.)

Not sure what you meant by this.


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

Editorial comments are welcome but be aware that I'm likely to ignore any
that aren't of great benefit to the spec. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'