W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2004

[whatwg] Incremental rendering of forms

From: Jim Ley <jim.ley@gmail.com>
Date: Thu, 26 Aug 2004 16:32:40 +0100
Message-ID: <851c8d3104082608326503eab3@mail.gmail.com>
On Thu, 26 Aug 2004 14:31:29 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
> On Thu, 19 Aug 2004, [ISO-8859-1] Olav Junker Kj?r wrote:
> > Ian Hickson wrote:
> >> I have had repeated requests for this from Web authors, and received
> >> numerous notes praising the idea since publishing a draft with it in.
> >>
> >> That's persuasive for me.
> >
> > I believe you, but could you summarize or point to some of the concrete use
> > cases? I would like to be persuaded also.
> 
> There are various use cases and reasons, such as:
> 
>   * Not changing the content model of HTML element like <table> is quite
>     important since there are many legacy parsing issues involved

What?  could you describe an actual use case situation here, that
makes this relevant?  (ie a table that semantically is more than one
form, and this isn't even a use case, it's a constraint brought about
from other use cases perhaps - but which ones?)
 
>   * Prefilling fields that are not contiguous from two different files
>     (as in:
>        English [ ............ ]
>        Norwegian [ ...........]
>        English [ ............ ]
>        Norwegian [ ...........]
>     ...where the English fields are one form, and the Norwegian fields
>     are another.)

Could you explain more what you mean here - what does "prefilling
fields" and "from two different files" mean.
 
>   * Having subforms, where you have, e.g., one form covering most of the
>     page, and then little forms within it.

could you again explain more about this in terms of a use case, it
seems like you've gone from the feature to justify it.   Use cases
involve uses, not functionality.

>   * Being able to predefine the form submission URIs at the top of the
>     page and then using them without having to think about what form an
>     element is in.

I'm getting even more confused now...  how does having forms not a
member of their containing form element allow you to "not think about
form an element is in" it seems to me that it makes it absolutely
explicit that you know what form an element is in - since you have to
add it to the element.  I'm obviously mis-understanding.

Can I ask again for some use cases - those that made you decide "right
the solution to that is having form elements in different forms" -
rather than ones that you seem to have made up given the premise that
such things exist.   Or at the very least expand these so I can
understand them.

Cheers,

Jim.
Received on Thursday, 26 August 2004 08:32:40 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:36 UTC