- From: Sander <whatwg@juima.org>
- Date: Thu, 10 Jun 2004 03:51:04 +0100
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
Received on Wednesday, 9 June 2004 19:51:04 UTC