W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2004

[whatwg] Comments to Web Forms 2.0 downloaded 2004-09-18 (HTML email)

From: Ian Hickson <ian@hixie.ch>
Date: Sun, 21 Nov 2004 19:09:24 +0000 (UTC)
Message-ID: <Pine.LNX.4.61.0411211843530.18516@dhalsim.dreamhost.com>
On Mon, 20 Sep 2004, Mattias Waldau wrote:
> 
> I read the working draft and have some comments. I classified the 
> comments in Major, Medium, and Minor.

Thank you! Sorry for the delay in responding to your comments.


> Before you disgard the Major ones I would really like to have a chance 
> to argue for them. I would say that they are essential if you would like 
> to use Web Forms 2.0 for more advanced forms.

Please do feel free to respond to this reply.


> ALL CONTROLS THAT SUPPORT DISABLED SHOULD SUPPORT READONLY (MAJOR)
> 
> Readonly checkboxes, drop-down menus, buttons etc are needed if you want 
> to be able to present the user with a receipt that looks exactly like 
> the webpage he/she filled in. For an example see 
> http://www.exceleverywhere.com/test/webforms2/webforms2.htm, where you 
> get a receipt after pressing submit. Normally this webpage would be 
> emailed to you. Note that the webpage is stripped from all logic, the 
> QTY-field is readonly, however, we cannot prevent the user from 
> checking/unchecking the Express Shipping checkbox.

This is poor UI.

Text controls are the only controls that have an understandable 
manipulable-but-not-editable state. If any other control, such as a 
checkbox, looked available but wasn't changeable, that would be a nasty 
black eye to someone's mental model of how that kind of control worked.

It would be like trying to use a lightswitch that someone had secretly 
disassembled, glued stuck from the inside, and reassembled. But making 
such a control look unavailable would imply that it wasn't *relevant*, 
which wouldn't be true either.

If I was designing such a Web app, I'd use words like "yes" and "no" for 
receipts, rather than checkboxes or pictures of checkboxes. That'd (1) 
avoid the last problem above, (2) be more legally unambiguous, and (3) be 
easier to convey by phone, e-mail etc. And having your receipt look too 
much like the original form is a recipe for confusion anyway.

This is the accepted way of doing this in native interfaces as well, for 
example the in "Summary" pane in OS X's Print dialog, which displays all 
the current settings together for posterity/diagnostics using "yes" and 
"no", not read-only widgets.

For prettier results you could use Unicode characters like U+2611 or 
U+2714.

(With apologies to mpt, who originally wrote most of the above.)


> Workarounds and why they are not good enough:
> 
>  1. Use JavaScript to restore the old value. This solution will not 
>     work when sent as email, since all email readers block JavaScript
> 
>  2. Using images for checkboxes etc in the receipt. Problem: Where 
>     should the images be stored? Should they be part of the emailed?

I don't read HTML mail. What would you do in a plain text e-mail? You 
would just write "yes", or "no", or similar. Do that for the receipt too.


> CONTROLS WITH NEGATIVE TABINDEX SHOULD BE IGNORED DURING TABBING (MAJOR)
> 
> Internet Explorer has a very nice feature, controls with negative 
> TABINDEX are skipped during tabbing. Without this feature, tab-wrap 
> around, ie. When you have reached the bottom-most control, you jump to 
> the first control will not work. Instead you tab through a lot of 
> uninteresting controls.

Added to Web Apps:

   http://whatwg.org/specs/web-apps/current-work/#negative-tabindex


> IT SHOULD BE POSSIBLE TO USE ENTER TO NAVIGATE THROUGH FIELDS (MAJOR)
> 
> All software except browser just Enter to jump to the next control.

This does not appear to be the case. In particular, All the dialogs I use 
in the software I have makes the Enter key close the dialog box, by 
implying a click on the default button.


> For some reason web form uses tab only and Enter means submit. This 
> might seem to be a small thing, but I know from personal experience that 
> this is a showstopper form some companies.
> 
> Therefor it would be nice to if Enter could be used for navigation.

It is possible to obtain this behaviour using event handlers that trap the 
key event and transfer focus instead of submitting the form.


> AUTOCOMPLETE SHOULD APPLY TO ALL INPUT CONTROLS (MEDIUM)
> 
> It seems that autocomplete doesn't apply to radio buttons and 
> checkboxes, why? If I entered data and the browser remembers them, it 
> should remember all of them.

The autocomplete attribute does not indicate that the UA should remember 
the value -- it only indicates that the UA should _not_ remember the 
value. The default is for it to remember the value. For radio buttons and 
check boxes, the lack of this attribute means that you can't turn off the 
autocomplete behaviour.


> OUTPUT-FIELDS SHOULD BE PART OF A SUBMIT (MINOR)
> 
> According to 5.1 an OUTPUT is not an successful control and will 
> therefor not be part of a submit. Is this correct?

Yes.


> If so, I think this is a bad idea. If you look at 
> http://www.exceleverywhere.com/test/webforms2/webforms2.htm, the total 
> fields are typically coontrols that should have been OUTPUT. However, if 
> this is an order form, it is important for the merchant to know what 
> total was presented to the user. Therefor, calculated values need also 
> be send by the submit. (This doesn't mean that the merchant should trust 
> the values since the webpage can have been manipulated.)

Such values can be submitted using <input type="hidden">. The reason to 
not make <output> controls submit is that it reduces the differences 
between the submissions done by WF2-compliant UAs and by earlier UAs.


> DO OUTPUT-FIELDS HAVE A TABINDEX? (MINOR)
> 
> If not, they need to have it. If you have very long forms, and the 
> bottom part is a big presentation of calculated values, you need to be 
> able to scroll down. The best way is to set a tabstop and one of the 
> OUTPUT-controls.

All controls (and indeed all elements) have the tabindex attribute now.


> IT SHOULD BE POSSIBLE TO PREVENT ENTER FROM SUBMITTING DATA (MINOR)
> 
> An office worker uses the Enter key thousand of times per day. Therefor, 
> preventing Enter from doing something very drastical like submitting 
> should be possible.

This is possible by using event listeners.

Thanks for your input!

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 21 November 2004 11:09:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:20 UTC