[whatwg] Web Forms 2.0 Feedback

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.  
> I want to be able to be able to simulate user actions in javascript even 
> 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.:

   image.click(2, 5);

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 
> 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.

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> 
> element.

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.

Why?

> 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 
them.


> 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 
> 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.

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
> implication, or the actual datalist element (if set via javascript).

The problem with semicolon-delimitted values is that they do not provide 
an easy way to include semicolons, titles, separate values and submission 
values, etc.


> 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.

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.

Thanks, fixed.


> 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 
pages.


> 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 
> give). 

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.   `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 29 August 2004 15:11:44 UTC