Date: Mon, 3 Mar 1997 16:12:44 -0500 Message-Id: <199703032112.QAA08869@churchy.gnu.ai.mit.edu> From: "nemo/Joel N. Weber II" <email@example.com> to: firstname.lastname@example.org, email@example.com cc: firstname.lastname@example.org Subject: HTML forms These comments are regarding the `Design Issues for HTML Forms'; the draft is at http://www.w3.org/pub/WWW/TR/WD-forms-970203 The name `accesskey' seems unintuitive to me. I'd prefer something that doesn't look like a name invented by marketing people. `key' and `shortcut' and `hotkey' and `keystroke' are all names that I would consider an improvement over `accesskey'. I'm not exactly sure what the keybindings under Windows are, but I have a feeling using the command key on the Mac is going to cause problems. IIRC, command-q is normally used to quit an application program. With this proposal, it will be possible for the creator of a page to remap command-q. That seems completely wrong to me. Probably the Right Thing would be to either use the key without a modifier when the focus is not assigned to an input field; or possibly allow the use of the control key. The draft completely ignores the existance of X11. The browser I'm writing probably will only support X11. Of course, X doesn't really have a standardized keyboard layout. The X terminal I use at school is a Sun; the X terminal I use at home is a PC. Probably control would be the perfect modifier for the hotkey feature; but I will probably allow the user to reconfigure it. I suggest that the spec merely suggest whatever keys are choosen as possibilities. I'm not convinced that TabIndex is ever really nessisary. I can certainlly claim that it's a style issue, not a content issue. I also cannot see why it would be desirable to rearrange the items. Always using the same default order would be more intuitive for the end user. The Title attribute is fine with me. Though the sample shows more of Microsoft marketing people appealing to idiots: <IMG SRC=main.gif TITLE="Click where you want to go"> So I'm not sure whether I'll implement that. But it doesn't look too bad. I can't really understand the disabled attribute, because I don't see any examples. Conditionally enabling and disabling depending on the state of other controls would make sense. But I don't think the current proposal provides any conditionalism. The label proposal makes sense to me; except that putting the accesskey on the label and not the object it describes makes no sense to me at all. To cite the example from the draft: <TABLE><TR><TD> <LABEL FOR=USER ACCESSKEY=U>User Name</LABEL> </TD><TD> <INPUT TYPE=TEXT NAME=USERNAME ID=USER></TD> </TR> </TABLE> I would change it to <TABLE><TR><TD> <LABEL FOR=USER>User Name</LABEL> </TD><TD> <INPUT TYPE=TEXT NAME=USERNAME ID=USER ACCESSKEY=U></TD> </TR> </TABLE> (though I would like to use some name other than accesskey here too) fieldset mostly looks good. However, when a fieldset contains a group of mutually exclusive radio buttons, the accesskey should toggle between them. I don't think the current draft will cause that to happen. The stuff described for phase 1 appears to not cause problems with backwards compatibility. The stuff in phase 2 will, I suppose. Is any active work being done on it? Is there any consise descritption of all of the forms features? All I've find is documentation of what Mosaic supports, as well as this draft.