[whatwg] Web Forms 2.0 Feedback

Hi,

    You have solicited my feedback at
http://www.whatwg.org/specs/web-forms/current-work/
so here it is.

1.  I want to be able to simulate clicking on an input element.
As far as I know, this is not currently possible.  For example,
If there is an input type=image element, when you click on it,
the coordinates relative to the image are transmitted to the
server.  It is possible to simulate a click on that element,
but the coordinates delivered in this case would be 0,0.  Can
you imagine that there are sites (I forget if it's Sprint or Verizon)
which actually test for that?!?  Anyway, there should be a way to
set a click position (e.g. attributes xDefault, yDefault)
if the submit of the form does not happen with a mouse.

More generally, this ability should be provided by the browser's
DOM.  I want to be able to be able to simulate user actions
in javascript even if the browser does not have focus.

2.  On the flip side, I would like to be able to capture what the
form submission is to be BEFORE IT HAPPENS (and be able to cancel it).
Using the same example as above, I want to be able to find the
"string" that is expected to be submitted to the server (via
javascript) and cancel the action.  In particular, I want to be
able to find out where the image was clicked before it goes to
the server (it's possible to do this via javascript, but messy
because non IE UAs implement mouse positions relative to the page).
The UA is doing this for me - don't hide this information.  If I
give a fake address such as wont:work then an error is displayed
showing the string to be submitted, but I can't get to it programatically.
Other tricks such as about:blank don't seem to work either.
I've just seen the data: protocol so maybe that will do the trick - I'll
test that out.  But, I'd still like a straightforward way to do this.

3.  I'd like hierachical menus (pop up menus).  Why can't an option
element take other relevant HTML elements?  This one could even degrade
somewhat nicely because non <option> elements within the top <select>
element could just be ignored resulting in one very long <select> element.
Example:
<select>
<option>Level 1</option>
<option>Level 1 -> 2<select>
                    <option>Level 2 -> 3<Select>
                                        <option><font color=red>Level 3A</font></option>
                                        <option accesskey=B>Level 3<u>B</u></option>
                                        </Select></option>
                    <option>Level 2</option>
                    </select></option>
</select>

4.  Does it make sense to have both an <input type=button/submit/reset...
and <button type=... element.  I think not.  It's time to start deprecating one.
But as long as <input type=button/... is still around, why not give it
an access key property and allow a letter on it to be underlined?
And for Pete's sake, have the spec say that access key properties must
be reachable in a single key combination.  What up with Opera's crippling
multi key ('/' + key) combination - who came up with that?

5.  One thing that bothers me is that there are so many ways to
plop a submit button on a page.  You could make a link with an image,
an <input type=submit onClick=...> element, an <input type=submit> element, a
<button type=submit>, <button type=button onClick=...>, <input type=image ...>,
<img ...>, image map, and probably I've left several out.  This smacks of bloat.
As I mentioned, one button type or another should be depracated.  In addition,
I'd suggest combining type=image with type=button, submit, ...
and start depracating.  You could have a special src=submit/button/reset value
You could have <button type=image src='...'>alternate text</button>
Anyway, you understand my point: cull.


6.  I appreciate the file size limitation being introduced.  This is trapable
in apache but really belonged on the client, too.  I'd like to be able to
get at this file size via javascript before the form goes out and possibly
cancel the submission or take other action depending on the value (for example,
the server might happily process small files for free, but require some sign
up / payment) for larger ones.  Again, clearly implementable server side, but
it's nice to minimize web traffic.

7.  I've never understood why UAs render SELECT elements always on top.
Can't we say/do something about that?

8.  I'm glad to see that we're finally getting around to allowing comboboxes
in HTML.  First, I would like to see list allow either a semicolon separated
list of values (possibly empty) allowing an anonymous datalist element by
implication, or the actual datalist element (if set via javascript).  Also,
you mention that the option elements in a datalist may be empty and you
also mention that the UA may fill in elements but you don't say how.  Wouldn't
it be reasonable to say that the UA may fill in empty option elements (and it
they're not filled in they're not shown).  That way the author can control
whether he wants the unspecified UAs assistance or not.  Also, for this type
of situation, it should be possible to actually find out how many values are
being displayed (as opposed to how many are allowed).  By the way, the
attributes table at the bottom of your document does not show the list
attribute for the input elements.

8b.  It seems to me that the line now becomes blurred about whether <select>
elements are really glorified input elements or whether input elements are
really a special case of select elements.  Why not go the full mile and unify
the two, and then make one deprecated.  In particular, a select element could
have a writeable attribute to make it into a combobox, and if it's got that
it should also take a type and a pattern attribute, etc.

9.  You state in section 2.7 that the first option of a single select element
is to be selected.  However, this is in opposition to what you allow for
radio buttons.  And yet, single selects are essentially the equivalent of
radio buttons, in a more compact form.  If you allow radio buttons to be
unselected, why not allow the single select element to be unselected, too?

10.  In section 2.15 you disallow multiple forms per element.  But given that
controls are becoming discociated from forms in a heirarchical sense, why
not allow multiple forms per element?

11.  The reference for the "data:" actions should be RFC 2397, and not 2387
as you currently show it (this also applies to the URL that you give).  It
should also be pointed out the IE 6 does not support the examples.

Frankly, I'd be overjoyed to see points 1-3 addressed.
The other points are minor by comparison for me.

Sincerely,
Csaba Gabor
web developer


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

Received on Friday, 20 August 2004 08:23:20 UTC