[whatwg] Web Forms 2.0 Feedback

[Csaba Gabor]

First, I'd like to thank you for your response.  It's rare that I
encounter anyone that can even appreciate these points.  And your
succinct direct addressing of the issues is also appreciated.
You've (implied or) asked for clarification on a few issues
(points 1, 2, 4, 5, 8), hence my response (interspersed on those
points.

In addition, there's one other point that I'd mention even though
it doesn't have to do with forms (but at least I'll get it off my
chest).  That is, that I'd like to see a height specifiable in
terms of number of lines of text.  It's always struck me as strange
that this isn't standard.  For example, I might want all my TD
elements to display at most two lines of text.  I could try to set
this in terms of em but if there is a font change (or a size change
in opera, say), I am sunk.  It's such a natural unit - why isn't it
this part of the CSS standard?

Sincerely,
Csaba Gabor

--- Ian Hickson <ian at hixie.ch> wrote:

> Date: Sun, 29 Aug 2004 22:11:44 +0000 (UTC)
> From: Ian Hickson <ian at hixie.ch>
> To: csaba at alum.mit.edu
> CC: whatwg at whatwg.org
> Subject: Re: [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.

Perfect:
arbitraryHTMLElement.click(xLocalObjectOffset, yLocalObjectOffset)
one issue: I would think that the elemtent's onClick should be run.
Does this conflict with any current behaviour?

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

No.  Don't get me wrong.  I'll be overjoyed if you mandate that the event
information contain local offsets (per IE), but what I really want is to
be able to see the action string of the form just before it gets submitted.
The image example was just a motivation.  Let me expand on it and provide
one other example.

One idea (that eventually works) to have the browser do the work for me
in terms of calculating local coordinates on where an image is clicked is
to send the form data to an IFRAME.  So if the action attribute of the
form is "javascript:writeIframeDocHere//" then the IFRAME is happily written
and will sing and dance for me (no security issues, I think, at least on
IE).  But the Iframe won't be aware of its "newest" src.  Ultimately, this
makes sense because it's not necessarily the case that there is a unique
"newest" src, since the Iframe might be getting written in pieces (grammar?).
It's not the Iframe's document who can know how it got there - rather
it is the author of that Iframe, the form itself.  This basic idea works,
but not with javascript: (html: seems to works, but there are a few issues
there which are not clear to me.  I'd prefer to use your new data: construct)

I've written a VB application that hooks into IE and exercises it (the app
is stimulating it as if it was a user (for the most part)).  Since it's
running locally, security issues can be overcome (non trivially, I might
add), and I can examine most of what is happening dynamically.  However,
if I click a submit button what the form looks like when the submit was
pressed is not necessarily what it will look like when it gets submitted
(names might change, elements might get added).  I might not be interested
in the intermediate stages - only in the final result.  Shouldn't the UA
provide a means to access this?

Hmmm, strikes me that your new data construct will actually provide me
what I want.  Direct the output embedded within a mini page to an iframe
(so please make sure standards specify no security restrictions since
it's coming from parent), include an onLoad, and we can direct the captured
information anywhere we want.  Nifty.

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

Please see response to next point 

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

I must have missed something.  I know it's possible to put in an
accessKey.  But how is it possible to underline a character on an
input button such as
<input type=submit value="Click me">
?

> 
> > 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'm not asking for removal (now).  I'm asking for deprecation,
making for cleaner pages in the future.  For example, <font>
is allowed, but deprecated.  Eventually it may go away.
 
> > 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?

OK, this is philosophy, but it may have its place.

Variety is great because it makes the world a more interesting
place.  Who can argue with more ways to do things?  And yet,
variety has a very real cost.  The more variety there is, as a
general rule, the more overhead there is.  One symbol per word
provides much more variety than a simple 26 letter alphabet,
but studies have shown that children take more time, on average,
to learn the larger symbol set.  How about the variety of Sony
vs Betamax?  Or what about the order of bytes in making up a 32
bit word?  There is variety there among the platforms - a huge
waste of brainpower, time, and resources.

Or, to take an example that hits home, what about the variety
(and I'm talking about their HTML / DOM implementations) that
we find in recent UAs (IE, Opera, Mozilla)?  Clearly not
good since there is a huge amount of effort (on the part of
programmers) that goes into compensating for the differences.

Variety is great at the "end user" level where it amounts to
art or experimentation.  When it comes to standards, however,
variety generally indicates inefficiency (or bloat).  If there
is more than one way to do something, one of those ways should
be more efficient.  If, on the other hand, the different
approaches are approximately the same, then it's usually a
good indication that there is either an inefficiency
in the design or inefficiency in (externally) dealing with
it (this latter is why these standards are being recommended,
no?).

To apply this abstract philosophy to this specific issue, the
bloat in the different ways of doing things is an indication
of a problem (the inefficiency) of the model.  In particular,
forms are really a grouping of elements (variables that will)
get submitted to a server.  Most input elements (and SELECT,
etc.) are ways of setting these variables.  Buttons, links,
input images, etc. are ways of directing the browser either
to submit a form or, more generally, perform an arbitrary
action.  Thus, these elements, should have a display (innerHTML)
component (image or text) and an action component (this action
component could include being an image map or submitting the
variables of a specific form).  Specifically, buttons are
essentially links.  And what advantage does <input type=image ...>
offer?

Till now, the dichotomy between form and non form elements
could possibly justify creating two classes of these types of
"submission" elements.  However, as we adopt the model that
a form is just a grouping for a bunch of elements that will
be submitted, the notion of separating the "submission" elements
becomes obsolete and needs clarification.

The inefficiency will be that without a move toward clarification
and simplification, the bloat of the old model will be around
to haunt us for a LONG, LONG time.  That's why I recommend the
notion of deprecating those variants that are not necessary
such as (<input type=image...>) and (<input type=submit...>)
and (<input type=button...>) and (<input type=reset...>).

Furthermore, a link (A) element is essentially a form with no
variables.  Really, what it can do that the button can't do is
to allow the new page to be opened in a new window.  How come
a right button click can't do that with a button?  So BUTTON
elements should allow forms to point to new pages on user
request (right click), and BUTTON should support
<button type=link ...> with a means for specifying the
destination URL (the action of the implied form).  This
type of element implies (I think) a shortcut for specify the
action of the implied form and the format for its innerHTML
(since it's a link).

I don't know if this is/can be done cleanly, but we're going
to be living with the current model for a while.  But it might
make sense to at least start moving towards a cleaner tomorrow.
Otherwise we'll have to keep saying, "we're stuck with it."

Sorry for the long diatribe, and it's late, but this came about
from my experiences with that VB program I referred to.
Everyone is doing submission actions differently, without
advantage.  Awful.

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

Ultimately, I agree with you on this, but for the type of reasons outlined
in point 5.  This idea was more of a floater because I dislike the bulky
list structure (well what I really dislike is having to type it in).
So really, what I proposed was a shortcut.  The problem is, while a
single shortcut might be fine, each one represents a risk of biting
you (bloat).  So, while the semicolon list structure could be made to
work simply (by specifying the necessary object as a string  - I am doing
this fine in javascript, escapes and all) it carries overhead.

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

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com