[whatwg] Comments on Web Forms 2.0

[Ian Hickson]

On Thu, 10 Jun 2004, Ian Bicking wrote:
>
> 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).

The plan at the moment is:

  1. Web Forms 2.0 ASAP
  2. Web Apps 1.0 in the coming months
  3. Reassess the situation.


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

I added a note to the XForms section:

  This section is aimed at XForms authors and implementors. If you do not
  plan to use XForms, you may prefer to skip ahead to the next section.
  Knowledge of XForms is not required to use this specification.


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

I agree, but it's a huge thing to specify, and we really want to get Web
Forms 2.0 out of the door ASAP (we started it back last September).


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

The fact that this is such a controversial issue is another reason to
delay specifying this by a few months. We don't want the whole spec to be
dragged back for that one feature.


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

Again, something to be dealt with in the future, once the current spec is
being implemented.


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

Yeah, this seems more like something for the Web Apps spec.


> The various date/time inputs seem similar to a number input with
> precision.  Could they be collapsed into a single input type?

What's the advantage of doing so?


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

That seems nice and generic but I think it's much more complicated for
authors.


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

As in, type="anniversary"? Is there an ISO8601 format for that?


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

Yes, I'm not sure whether to keep "tel" or not.


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

I don't understand what you mean by extensibility here.


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

No, although with the "step" feature now can do this (precision="10").


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

Someone else suggested this too, so now yes. precision="25", etc.


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

Possibly. The "min" and "max" attributes already apply to datetime stuff.

Maybe we should drop "precision" altogether and just have "step", then
make it apply to all the numeric and date/time types.

Hmm. Let me think on this.


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

There is a use case. Look at the example in that section:

   http://whatwg.org/specs/web-forms/current-work/#the-output


> 2.4. Extensions to the textarea element
>
> You don't mention wrap="none".  I assume it would remain?

Well UAs can keep supporting it, but it is semantically very dubious, so I
wouldn't expect authors to use it.


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

Just use <button> elements. The value of this change doesn't outweigh the
disadvantages (breaking backwards compatibility).


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

If you don't want a coordinate, don't use type="image". Use CSS to replace
your button with an image.


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

Added:

  <p>Empty fields (those with no value) do not need to match their
  pattern. (Although if they are <a href="#required">required
  fields</a>, they will stop submission for that reason anyway.)</p>


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

Indeed. This is why I am planning on removing it at some point. I'm
curious as to how XForms handles the "help" attribute.


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

The text you are talking about was about elements in the DOM, whereas you
mean about parse time.

I've added some text about parse time, about how tags should be parsed as
character data but comments and entities should be parsed correctly. If we
say anything other than that, we unfortunately break existing sites, as
Mozilla has discovered.

In XHTML there is no ambiguity of course.


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

Yes. Is this a problem?


> I think someone else brought up tab ordering, which is similar.

Tab ordering is indeed a problem.


> I don't know my HTML well enough: is it valid to have <span>s or
> <div>s around <tr>s?

No.


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

Use <tbody>.


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

Yes. The order is right there in the DOM. The submission order is the DOM
order.


> Or you could look at the order in which the fields were returned, but
> that information is usually lost on the server side.

It doesn't have to be...


> 4.4. Form validation
>
> More examples would be helpful here.

Yes, more examples would be helpful throughout.


> 8. Step eight: Handle the returned data
>
> It's unclear to me what exactly happens with replace="values".

You take the returned document, then send it through the algorithm at:

   http://whatwg.org/specs/web-forms/current-work/#seeding

...without changing which document is visible.


> Specifically, what URL appears as the location?

Unchanged.


> What happens when you reload

The values on the original page (presubmission) are used, assuming your UA
doesn't reuse whatever values you most recently typed (which is common for
a soft-relad).


> or go back to this page?

Depends on the UA. UAs differ in what they remember when going back.


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

Not really. Not any more than with DHTML having filled in the values, for
instance.


> 5.1. Successful form controls
>
> It can really be annoying that unchecked checkboxes aren't successful.

Yes, but for backwards compatibility there's nothing we can do about this.


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

There is no realistic example. It just has to be defined, since the
protocol is there and most UAs now support it.

Thanks for your comments,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'