[whatwg] Comments on Web Forms 2.0

Some comments on Web Forms 2.0.  After reading through it, nearly
everything in the spec is of interest to me, and if it was implemented
I would start using it immediately.  Not just in new projects, or as a
new strategy and direction for development, I'd just start using it.
No other upcoming developments offer this possibility.

Admittedly, there's a lot of things it doesn't cover.  I'm hopeful
that there would be a Web Forms 2.1 or 3.0 -- if this spec could be
implemented and usable in a reasonably short amount of time, then not
everything needs to be in the spec.  Momentum would be better than a
Killer App (well, Killer Spec).

As to the criticisms that we can already do this, that is part of the
very premise of these specifications.  If we want functionality that
can be implemented in IE6, it's highly likely it could be implemented
in most other browsers as well, right now, using Javascript.

But coding each of these things in Javascript is challenging -- it
requires extensive testing, and it's common that the result won't be
extensible, robust, or sufficiently general.  Management of this
Javascript is itself difficult on the server side -- if you rely on
generating Javascript on the server side, it is difficult to easily
reuse a component across different technologies (e.g., server side
include vs. PHP vs. ASP), and providing reusable server-side components
is challenging when there's a mix of client-side Javascript and
server-side behavior.  Also, there is no basic vocabulary for this
code, instead we have a a plethora of ad hoc code, each of which works
differently for the author, *acts* differently for the user, and is
typically left out of many smaller applications where it would be
useful but not worth the development effort.  I would like never to
see again a date input with a <select> box containing a century worth
of years.

But all this means that the final product is in essence a reusable
Javascript library.  Somehow this seems too trivial for a
specification and a working group.  But I would hope that the spec can
be a central point both for robust implementations across a variety of
user agents, and a education effort so that people can confidently and
efficiently use these new features.  If it's useful, then it doesn't
matter how it's implemented.  For the mass of web developers who are
developing purely for current browsers, this would certainly be useful.



Following are some more detailed comments, which may be boring to many
of you...




1.3 Relationship to XForms

I get the impression that the XForms processor you suggest here is
just an option, and that this kind of layering is not particularly
preferred.  But it's not clear.  When I first skimmed this, this
scared me off.  I though I would need to understand XForms first.


1.5 Missing Features

"A rich text editing or HTML editing control. This need may be
addressed in a future specification."

That's too bad, I think this is a very useful control.  OTOH, there
exists reasonably modular Javascript that addresses this now.
Ultimately, though, I think there's a Right Way and a Not As Right
Way, so I don't think there's a real need for a diversity of
implementations in the long term.  Though due to the many commercial
offerings in this realm, I somehow doubt consolidation would actually
happen.


"A declarative way of specifying that one list should filter the view
of a second list. Again, however, this need may addressed in a future
version of this specification."

This has been one of the more common uses of Javascript in forms, in
my own experience.  OTOH, those techniques already work.


2.1. Extensions to the input element

Re: datetime et al.  It would be nice along with these if the user's
prefered timezone were known.  But then knowing that would actually be
nice in a wide variety of situations outside of forms.

The various date/time inputs seem similar to a number input with
precision.  Could they be collapsed into a single input type?  Or
maybe with a list of values you are looking for, like "y,m,d" for
date, "y,m" for expdate, "y,w" for week, "y,m,d,h,M" for specific time
(but without second precision), etc.  Though that allows for the
peculiar "y,h", which would make no sense.  But we can't really give a
range (e.g., y-h for y,m,d,h) because weeks don't fit in there.  Maybe
week needs to be a special case.

Also, month and day is a reasonable input.  To enter your anniversary,
recurring dates, etc.


Re: tel.  Seems challenging to do in a useable way.  Though I suppose
a good UA could simplify this, and add all the necessary information
based on an abbreviated phone number (i.e., ###-###-####).  Though
that RFC seems so complicated for something that is currently so
simple (at least from a form perspective).  I am quite comfortable
using a text field for phone numbers.


Re: uri.  I feel like this calls for some extensibility.  But I'm not
sure what.  Some indication of scope and possibility for suggestions.
Filling a URL in from a bookmark seems an unlikely use case to me.


2.1.2. Precision

Re: adp.  Is a negative number allowed here?  I.e., adp="-1" allows
for numbers like 0, 10, 100, 120, etc., but not 4.

Would there be any way of, say, counting by 25's (or .25's)?  An
increment argument, perhaps.  This could even take the place of adp,
like increment="0.1" means adp="1".

Could this apply to dates and times, or an analog of this?
Specifically, precision to 15 minutes, or one hour, or one minute?
15 minute increments are common in calendars, for instance, or 10
minutes for a room scheduling application (or even one second for an
astrology application).


2.2. The output  element

It might be good to start with a use case.  This remains confusing to
me, specifically how it is different from a hidden input.  (Besides it
not being hidden, but I think more than that is intended.)


2.4. Extensions to the textarea element

You don't mention wrap="none".  I assume it would remain?


2.7. Extensions to the submit buttons

As an additional change to submit buttons: it is annoying that a
submit button's value is the same as its description.  You either have
to encode the information about the submit button in its name
(e.g. "action_edit" vs. "action_delete"), or rely on the descriptions
(test the "action" field to see if it is "Edit" or "Delete"), which is
fragile since the description is part of the visible UI.  Some of this
is alleviated with the extra attributes for submit buttons, but this
smaller, incremental change still seems useful.

So it would be nice if there was a new attribute (say, "description")
that was displayed as the text of the button if present.  If not
present the value attribute would be used, as it is now.

Additionally, the "image" input type is annoying, because it returns
different fields than a normal submit button (with .x and .y).  It
would be nice if there were an option to make the image submit act
exactly like a submit button.  Then changing this visible element
wouldn't change the structure of the form.


2.10. The required attribute

Does required (or rather, the absence of required) override pattern?
Specifically, if something is empty, not required, but the pattern
does not match the empty string, is it valid?  It would be very
helpful if this was valid -- it's common to want a valid value OR no
value at all, and many patterns don't match the empty string.


2.15.  The help  attribute

It seems difficult to make meaningful help without some knowledge of
how it is going to be displayed.  Do you include a search box?  Do you
include an image?  Do you include links?  Do you make it long or
short?  Depending on how it is displayed, the help document could
be written very differently.

Considering this ambiguity, it also doesn't seem very important.  I
don't see a reason to include it.  Also, I imagine UAs will either
display it in an obnoxious way (floating text) or a totally hidden way
(hit F1).


2.16. Handling unexpected elements and values

"For textarea elements containing elements"

FWIW, bugs related to elements inside a textarea frequently go by for
some time, until someone enters text like </textarea> or '<a "' or
some other invalid HTML, and then the form is rendered useless.  This
can be extremely frustrating.

It would be nice if authors who didn't quote the contents of textareas
were made aware of their mistake more quickly.


3.1. Introduction for authors

Once I followed along further, I saw the examples, but I'll leave
these comments in here anyway, even if they are addressed further on...

I assume when dealing with nesting repeated forms, you'd do something
like:

<fieldset id="contact" repeat="template">
   Name: <input type="text" name="name_[contact]">
   Phone Numbers:
   <ul>
     <li id="phone_[contact]" repeat="template">
       <input type="text" name="phone_[contact]_[phone]">
     </li>
   <ul>
   <input type="add" template="phone_[contact]" value="Add a number">
</fieldset>

As such, the substitutions have to occur in many places.  I think
someone else brought up tab ordering, which is similar.  Maybe this is
all covered by 3.5.1., number 7.

I don't know my HTML well enough: is it valid to have <span>s or
<div>s around <tr>s?  Something like this would be useful to do:

<table>
   <div id="contact" repeat="template">
     <tr><td>Name:</td>
         <td><input type="text" name="name_[contact]"></td></tr>
     <tr id="phone_[contact]" repeat="template">
         <td>Phone:</td>
         <td><input type="text" name="phone_[contact]_[phone]">
     </tr>
   </div>
</table>


3.5.3. Movement of repetition blocks

It would be really nice to have a way to get at the order the rows end
up in.  In fact, it would be a little boring to reorder if the form
submission doesn't represent that fact.  Am I missing something?
("Moving repetition blocks does not change the index of the repetition
blocks.")  I guess it could be done with the events, but it seems like
it should be easier.  Or you could look at the order in which the
fields were returned, but that information is usually lost on the server
side.


4.4. Form validation

More examples would be helpful here.


8. Step eight: Handle the returned data

It's unclear to me what exactly happens with replace="values".
Specifically, what URL appears as the location?  What happens when you
reload or go back to this page?  Post forms always give me trouble
because of their behavior in these cases, and replace="values" seems
even more subtle -- it becomes very vague where the user "is".


5.1. Successful form controls

It can really be annoying that unchecked checkboxes aren't successful.
Sometimes it's just what you want (typically when you have multiple
checkboxes with the same name), but sometimes it's not, because you
can't tell that the field ever existed (this is specifically the case
with generic form result handlers that have no knowledge of what
fields to expect).  No suggestion, just thought I'd note that.


5.6.3. For data: actions

I'm totally confused by data:.  Is this some weird backward compatible
thing?  I can understand it as a data source, but as an action?  A
realistic example would be helpful.


For the rest of the DOM/Javascript stuff, I'm not really knowledgeable
enough to comment.

Received on Thursday, 10 June 2004 09:24:30 UTC