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.

Received on Monday, 3 March 1997 16:13:19 UTC