[whatwg] Web Forms 2.0 Feedback
Csaba Gabor
csaba2000 at yahoo.com
Thu Mar 24 15:43:35 PST 2005
Ian (and Jim),
Ahem, thank for your *recent* response to my earlier
email. I was in the process of moving at the time and
so it sort of got buried. I accidentally ran across
your nicely done
http://www.whatwg.org/specs/web-forms/current-work/
and figured that I'd reply to your question (Ian) and give
feedback all at once (and sorry if you are receiving
two copies of this).
First, to answer your question about
> > > 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?
>
> We'd probably have to do whatever it is that currently happens with the
> click() method -- which I believe doesn't trigger the event handler.
>
> What was your use case for wanting the event handler to trigger?
1. I had asked for the ability to simulate a REAL click complete with
simulated coordinates. Here's my use case. I want to be able to take
a document and treat it as a black box and marshall it through its
paces. I actually built exactly this app two years ago(!) using VB(!!) and
a few windows APIs and IE 5.5. The only thing that I couldn't do was
to simulate a real click. The reason why it mattered was that when I
simulated a click on an image element a 0,0 coordinate got transmitted
and there are some websites which actually check that (improperly, if
you ask me, since I might be mouse challenged) but this is the one issue
I couldn't overcome in a reasonable way. I think that also explains
why I'd like to have the handlers fire. As a result, it never made it
to prime time, and all it did was go through all my online accounts
each night (simulating the entire sequence finding the appropriate
information and elements on the page) and pay them as necessary.
That's what it could do.
To say this another way: there is no reason for the document to be
physically visible to be able to work with it. As long as it's
virtually visible, everyone should be happy. But the mouse is a
real problem (I'm a Windows person), since it's hard to convince a
window on Win 2K/XP that it just got a mouse click somewhere if it
didn't really get it, even with Win APIs. It's probably possible but I
didn't figure it out back then. The right place for this, though, is
at the document level. Really, there's no inherent reason, is there,
not to have both mouseMove and mouseClick events be simulatable
(including passing the coordinates).
About the actual Web Forms 2.0 Working Draft of 21 Mar 2005:
2. Repetition model.
The Draft has a huge amount of space devoted to this,
but I haven't been able to think of a single compelling
argument for it. Most of the control enhancements such
as validation are conveniences, after all, but what they
have going for them is that they are very compact. This
repetition model is huge and messy and there are simple
javascript programming methods that allow you to do the
same thing. This developer's opinion is that I would
far rather roll my own and not even have the possibility
of using this construct.
3. About that form element.
A) I am very glad to see that you are disassociating it from
the object heirarchy and moving it to be an attribute
(or property) of control elements. That's good.
So now it's sort of a half in, half out kind of creature
(like the Map of an image map) that describes a behaviour,
but that's what happens when you mix behaviour with placement
and slowly turn a tree into a graph (at least it's still acyclic).
B) But I can't twist my mind about all this stuff with
allowing/not allowing block level contents inside DIVs
unless it's an odd numbered Tuesday of the month. Could
the document maybe provide some argument for this?
It states:
The children of a form element must be block-level elements, unless one of the ancestors of the
form element is an element other than div whose content model includes both block- and
inline-level content, in which case either block-level or inline-level content is allowed (but
not both). input elements of type hidden may be placed anywhere (both in inline contexts and
block contexts).
But isn't the ancestor of every form (in an html document)
a body element (which is not a div element)? And I'm pretty
sure I've put both inline and block content into body elements.
So now I can only have block or inline elements in my forms,
but not both (like I've gotten accustomed to doing)? What
happened to backwards compatibility and why should spec
developers even be concerned about this one? I just don't get it.
Though I should say that I've never understood the reason for
all the hullabaloo over the distinction between block and inline -
seems artificially blown out of proportion to me.
To my mind, a FORM element is a convenient way of saying,
"unless otherwise noted, every control within me will be submitted
when I am submitted." As such, why should it have any interest
in the bock/inline types of its descendents?
General feedback:
4. I'm overjoyed about the data: protocol. It's a
compact way of recovering what was submitted without having to
go all the way to server. Testers everywhere will thank you
for it. I've even made a nice little starter page for when
it's actually implemented (hopefully you are reading this as
plain text):
<html><head><title>Form and Data test</title></head>
<body>
<form method=post action="" target=iframe>
<input type=text name=Sam autofocus=autofocus value="Change this">
<button type=submit accesskey=C><u>C</u>lick me</button>
</form>
<iframe name=iframe src="about:blank" style="height:4in;width:100%">
</iframe>
<script type='text/javascript'>
document.forms[0].action = "data:text/html," +
"<html><head><title></title></head><body>\n" +
"<script type='text/javascript'>\n" +
"function elem(id) {return document.getElementById(id);}\n" +
"<\/script>This was the data:<br>%%</body></html>";
</script>
</body>
</html>
I have two points that are not explicitly adressed:
A) There is mentioned a maximum length of about 1K for this
data type (in the RFC 2397). Couldn't this be extended?
Is that 1998 limit still reasonable? For longer forms,
it would be easy to exceed this amount and to my mind there
is not a good argument for mandating a small limit.
I thought UAs are already supposed to be able to handle a
large amount of data coming in as type 'text/html'. Why
should we mandate a short length?
B) Security: Shouldn't it be mentioned that if the
the destination window gets a page like this, it should be
run in the context of the submitter?
5) When I first read the replace attribute of a form I thought
good, that is a useful innovation. Why destroy the document
just to repopulate a small section of it? So section 8 of
form submission tells me I should go see the section on:
seeding a form with initial values
to find out how this is done. For a non XML person
like me, that is scary stuff there. Trying to figure
out how ultra long strings with seemingly random
digits might be applicable to me (What I'm saying is,
the HTML person is going to be scratching his head
upon reading it). And then my eyes alight on section
6.2.4, 3rd paragraph, about image controls.
It says:
For image controls, instead of using the name given by the name attribute, the field's name is
checked against two names, the first being the value of the name attribute with the string .x
appended to it, and the second being the same but with .y appended instead. Thus image controls
are handled as if they were two controls.
So, how does this make sense in a form seeding sense?
Look, I would be overjoyed if I could read out the
.x and .y of an image control because it is something
that is painfully missing from forms, but I don't get
their context here. How does it make sense to set
this, since it's the result of a click.
Also, in step 4 of form submission, it is mentioned that:
Image buttons, during this step, are handled as if they were two controls, one with the
control's name with .x appended, whose value is the x coordinate selected by the user, and the
other with the control's name with .y appended, whose value is the y coordinate selected by the
user. The indices of these two virtual controls are handled separately and could, depending on
the values of other controls, end up with different values.
I would say that these coordinates are not selected, but rather clicked
and shouldn't it be mentioned that they are relative to the control itself
(as opposed to the window or some other object). But more importantly,
how could this .x and .y wind up with different values (I assume you don't
mean from each other) depending on the values of other controls. I must
say, I was sitting on the edge of my seat with excitement upon seeing
the 'For example' just below this, which turned out not to give it away.
6) One thing I didn't think of before, but that replace attribute
reminded me...
Wouldn't it make sense to specify a way for a form or output contol,
IF IT REQUESTED, to be updated from the server on a continuing basis
(push technology years ago, if I remember right). I know it's late
in the game for this, but perhaps you will hear me out.
If a form has a replace attribute and is submitted, then, it has
indicated that it wants a set of data back from the server. That
could take quite a while if both parties didn't enforce timeouts.
But, in theory, if the server trickled out one little piece at a
time, couldn't this connection be maintained for quite a while?
What I'm proposing is a replace="continual" where values can
continue to come in until the server closes the response or the
UA ends it (In this instance it might make sense not to have
the progress bar constantly showing). If the server sends back
the same control/value multiple times then it is updated each time
that control and value are received.
So, unless I miss something, for a relatively minor enhancement
to this spec, you gain a huge utility. (This functionality can
already be simulated, of course, by refreshing an IFrame or other
silliness, and having an onload, but it is not so robust, and
just not the right thing to do. My understanding is that you can
do this in Flash too.) It just makes sense to have this as a
native ability.
But it's late and I indulge my fantasy and am thinking off the
cuff, a dangerous combination. I want more. Whether the above
eventually makes it in or not, it seems eminently reasonable.
This next part however, is questionable... but would unleash
a whole new era of connectedness. I don't know if it makes sense
or is feasible, but I offer it as possible future idea...
Let's presume that we can do this live update business
(replace="continual"). That means the UA has declared that it
is willing to keep an open connection and receive input from
the server as it happens. Now let's suppose a second UA does
the same thing with the same server. So if UA1 sends a piece
of info to the server, UA2 could instantly be notified of
this change (this I have already done with current technology
as alluded to above. Nothing new here).
Here's what I'm thinking/wondering. That request from a UA
for data went out to the server, which could redirect it. At
the same time, UA2 has issued a similar request. Couldn't
the server cut itself out of the loop?!? After all, both
parties are asking something from it. Could the request of
one be construed as the answer to the other. OK, what I'm
really asking is can we turn a UA into a mini or simulated
server where the intermediate 'trusted' agent, the server,
is the one that makes the arrangement.
Again, this kind of thing is already possible on a simulated
basis? How would one formalize it in a reasonable way.
7. Finally, a curiosity question. SELECT elements are lacking
in this spec. Now, back in the summer it was pointed out to me
(Ian) that Hierachical menus will be available in Web Apps 1.0
What I don't understand is why they are not part of this spec.
Isn't this their natural resting place?
Best Regards,
Csaba Gabor from Vienna
--- Ian Hickson <ian at hixie.ch> wrote:
> Date: Fri, 12 Nov 2004 11:14:30 +0000 (UTC)
> From: Ian Hickson <ian at hixie.ch>
> To: csaba at alum.mit.edu
> CC: whatwg at whatwg.org
> Subject: Re: Re: [whatwg] Web Forms 2.0 Feedback
>
> On Sun, 29 Aug 2004, Csaba Gabor wrote:
> >
> > 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.
>
> My pleasure.
>
>
> > You've (implied or) asked for clarification on a few issues (points 1,
> > 2, 4, 5, 8), hence my response (interspersed on those points.
>
> Thanks!
>
>
> > 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?
>
> You can, to some degree, do this using the "em" unit, as in:
>
> height: 2em;
>
> The problem is that what you really want is a unit dependent on the
> line height, and the line height can change based on what is on the line,
> which makes this quite complicated.
>
> However, I shall forward your request to the CSS working group. It's not
> the first time people have asked for this.
>
>
> > > 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?
>
> We'd probably have to do whatever it is that currently happens with the
> click() method -- which I believe doesn't trigger the event handler.
>
> What was your use case for wanting the event handler to trigger?
>
>
> > > > 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">
> > ?
>
> The general consensus is that if any underlining happens, it should be at
> the discretion of the browser, not the author. This is quite a complicated
> issue though, due to keyboards being different on different devices, etc.
>
> We're still looking at exactly how to address access keys in general.
>
>
> > > > 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.
>
> <font> was deprecated because it was actually bad for the Web, for various
> reasons. Deprecating it means that it shouldn't be used, but, in the real
> world, browsers will always support it. There's just too much content that
> uses it, and that content isn't going anywhere -- it'll be with us for
> decades to come.
>
> With the ways of submitting that you mention, though, they each have valid
> use cases, so I don't really see how we can deprecated 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?
> >
> > OK, this is philosophy, but it may have its place.
> >
> > 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?).
>
> Well, granted, but browsers will be forced to support these features
> anyway, so removing them from the specs just means the browsers will have
> to guess how they work instead of just being able to follow the standards.
>
>
> > 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...>).
>
> It's true that <input type="submit|button|reset"> is redundant with the
> <button> types of the same name, but it is not really bloat. The code
> required to implement both is quite trivial, they are generally just
> implemented in terms of the other.
>
> Cheers,
> --
> Ian Hickson U+1047E )\._.,--....,'``. fL
> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
>
--- Ian Hickson <ian at hixie.ch> wrote:
> Date: Fri, 12 Nov 2004 10:57:18 +0000 (UTC)
> From: Ian Hickson <ian at hixie.ch>
> To: Jim Ley <jim.ley at gmail.com>
> CC: csaba at alum.mit.edu, whatwg at whatwg.org
> Subject: Re: [whatwg] Web Forms 2.0 Feedback
>
> On Mon, 30 Aug 2004, Jim Ley wrote:
> > >
> > > 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.
> >
> > but not trivial to implement unfortunately, the overwriting of IE's
> > native methods isn't reliable (you get access denied errors on
> > occasions, take a fully patched IE5.5 on Windows 2000 and you can't do
> > document.write for example)
>
> Would it work if we used a new method name, such as clickPoint() ?
>
>
> > Also, I don't think this would be possible to do with HTC's because as
> > soon as you overwrite the click method of the input element, you lose
> > access to the original click method - this means that aswell as
> > constucting the form submission yourself, you'd also need to fire all
> > event listeners listen to the click event - something which is not
> > possible in IE. So full emulation of this in IE6 would not be possible.
>
> It would be interesting to see if it would be possible to emulate this by
> posting synthetic click events at the image, with appropriate X and Y
> coordinates set.
>
> --
> Ian Hickson U+1047E )\._.,--....,'``. fL
> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
More information about the whatwg
mailing list