[whatwg] Web Forms 2.0 Feedback

Tue Apr 5 05:38:42 PDT 2005

On Thu, 24 Mar 2005, Csaba Gabor wrote:
> >
> > [simulating img clicks]
> > 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.

Ah! You can do that by simply creating an event using the createEvent()
method and then dispatching it into the DOM via dispatchEvent(). That will 
work for any event.

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

Yeah, several people have said that. We're thinking about removing it. On 
the other hand, several people have said that it is a godsend and that 
they are so happy it is there because they are fed up of rolling their 
own. At the moment it's about equally matched, in fact.

The model is pretty simple and relatively easy to implement, so I'm 
leaning towards keeping it.

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

This is just allowing you to do:

   <ol>
    <li>
     <form>
      <input>
     </form>
    </li>
   </ol>

...which would otherwise be illegal (it is illegal in HTML4). Currently 
you have to do:

   <ol>
    <li>
     <form>
      <p><input></p>
     </form>
    </li>
   </ol>

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

<body> only accepts block-level content in HTML4 Strict.

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

In HTML4 Strict you can only have block-level content in <form> elements. 
This is simply relaxing this to allow inline-level content as well in 
certain cases where that makes semantic sense.

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

I agree with you. The way it is defined in WF2 effectively makes <form> 
transparent to all this, letting the ancestors and descendants figure it 
out between themselves.

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

This will be extended in the Web Apps spec.

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

In general it is best to leave security concerns of this nature out of the 
normative definitions of the spec, in case new problems arise that were 
not considered during the development of the spec. However, the concern 
you raise has indeed been considered and is what UAs implement, I believe.

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

Yeah, I expect we will need tutorials to make this understandable. The 
problem is the processing model as to be detailed, so the spec can't 
really be both simple for authors and implementors, and the latter take 
priority generally. :-)

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

It's a minor detail to do with keeping track of the controls being filled 
-- the above does not say that image inputs can be seeded.

> 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

They could be selected via some other means, UAs are not required to need 
a mouse for htis.

> and shouldn't it be mentioned that they are relative to the control itself
> (as opposed to the window or some other object).

That is unchanged from, and therefore covered in, the HTML4 spec.

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

It's an edge case. Say you have:

   <input name="i.x">
   <input type="image" name="i">

...then the image will generate an "i.x" and an "i.y" but not there are 
two "i.x"s and only one "i.y". This is just taking care of that.

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

This will be covered by the "remote events" part of the Web Apps spec:

   http://whatwg.org/specs/web-apps/current-work/#server-sent

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

<optgroup>s can be nested in Web Forms 2.

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