[whatwg] Web Forms 2.0 Feedback
ian at hixie.ch
Sun Aug 29 15:11:44 PDT 2004
On Fri, 20 Aug 2004, Csaba Gabor wrote:
> 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.
> if the browser does not have focus.
This sounds like what you are really requesting is a way for setting the
coordinate when you call click(), so you would do, e.g.:
Is that right? If so, that seems relatively simple to add.
> 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
> 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
> 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.
If what you want is a way to tell the coordinate where the image was
clicked, it's probably a lot easier for us to support just that
specifically (by, for instance, providing this information in an event),
than it would be for you to extract the information from the submission.
Is that what you really want?
> 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>
Hierachical menus will be available in Web Apps 1.0.
> 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?
That is already possible.
> 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?
I suggest you bring up issues specific to particular UAs directly with
that UA vendor. (On phones in particular it probably makes no sense to
forbid multi-key shortcuts.)
> 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.
There are pages that use each of those, so we can't really remove any of
> 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.
I don't really understand what is wrong with the variety?
> 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
> 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
For various security reasons, it is unlikely that we will add ways of
querying the file form data before submission.
> 7. I've never understood why UAs render SELECT elements always on top.
> Can't we say/do something about that?
Newer UAs do this correctly.
> 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
The problem with semicolon-delimitted values is that they do not provide
an easy way to include semicolons, titles, separate values and submission
> 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
Actually I believe the spec does say that the "label" attribute is to be
used if the <option> elements are empty.
> 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.
Because that wouldn't be backwards-compatible and would break existing
> 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.
This was considered but isn't backwards-compatible.
> 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?
Because in both cases, the spec is merely reflecting de-facto implemented
behaviour in existing user agents, sadly.
> 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?
This is currently being considered and might well be allowed.
> 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
Oops, good point!
> It should also be pointed out the IE 6 does not support the examples.
This goes for most of the spec. In fact most browsers support very little
of this spec right now.
Thanks for your input! It is very much appreciated.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg