[whatwg] Form and select seeding

[Ian Hickson]

I have not integrated the form and select seeding features that were 
defined in WF2 into HTML5.

In the case of forms, my motivation was driven mostly by the desire to 
drop the XML submission feature, which has not been popular, and which, 
once removed, left the seeding being based on a somewhat dubious format. I 
am also not convinced that the use cases that this feature solved are all 
that common. Furthermore, they could easily be implemented in script or by 
server-side prefilling, so the arguments in favour of it are pretty weak.

In the case of select seeding, the feature was based on another dubious 
format (an XHTML file with a <select> root element) and the use cases 
didn't seem especially compelling (the file could just be merged in on the 
server side in static cases, and doing dynamic cases with half a dozen 
lines of code instead of 1 isn't a big deal).

Basically both cases lacked compelling arguments in favour and had a 
number of minor problems that added up.

Anyway, since these features are now gone, the feedback below is moot at 
this point, so I haven't done anything with it.


On Sun, 19 Nov 2006, Sean Hogan wrote:
> 
> 1. What happens when the data attribute is cleared?  Are all OPTIONs 
> removed? Or no change?
> 
> 2. What happens when the data attribute is set to the value it already 
> contains?  Is that a refresh or no change?
> 
> 3. Is there a way to start out with a SELECT that has hard-coded OPTIONs 
> but no @data, set @data to load some OPTIONs (incrementally or 
> otherwise) and then reset to the initial hard-coded options.

On Fri, 15 Dec 2006, Sean Hogan wrote:
>
> The way in which a FORM element with @data is seeded seems internally 
> inconsistent:
> 
> CLEAR & REPEAT directives apply to RepetitionBlocks in the whole 
> document.
> 
> but FIELD directives only apply to elements within the form. I would 
> prefer FIELD directives to apply to the whole document - that seems 
> consistent with current forms which retrieve a whole new page. Although 
> it does allow conflict between @data on different forms.
> 
> The first step in the initialization algorithm (resetting the form) 
> sounds wrong in the context of form submission. I assume the intention 
> is that the reset() method is called, but the documentation says "reset 
> to its initial values as specified in the markup". These two are the 
> same when the document is initially loaded, but the form could easily be 
> changed by the time of form submission.

On Thu, 29 Mar 2007, Brad Fults wrote:
>
>    The reset() method resets the form, then fires a a formchange
>    event on all the form controls of the form.
> 
> In the case of a form seeded with initial values, it is not clear to me 
> whether the intention is for the form's reset() method to reset the form 
> to some sort of blank state or to the state immediately following the 
> seeding of initial values.

On Mon, 27 Aug 2007, Garrett Smith wrote:
>
> how about seeding a FORM's data with a JSON object?
> 
> Is this a reasonable consideration?
> 
> Will it work with File type elements?

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