[whatwg] Incremental rendering of forms
Jim Ley
jim.ley at gmail.com
Thu Aug 26 10:35:17 PDT 2004
On Thu, 26 Aug 2004 16:05:38 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
> On Thu, 26 Aug 2004, Jim Ley wrote:
> > 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?)
>
> Other people have already mentioned this on this list. It is common to
> want to have tables where each row is a separate form.
Could you please describe a situation where this is using a table
semantically correctly, rather than this being a feature due to the
poor state of CSS in many UA's. I've always understood use case to
not be about the technology, but to be about things people want to do,
can you please try and focus on those use cases. At least one would
be fine...
> > Could you explain more what you mean here - what does "prefilling
> > fields" and "from two different files" mean.
>
> http://www.whatwg.org/specs/web-forms/current-work/#seeding
Right so the requirement here is because of a poor design of the
seeding, why don't we fix that instead, seen as the proposal here
violates the backwards compatibility requirement, I think it would
make much more sense to fix the other new feature. Especially as that
one is easy to fix (provide a mechanism in the seed XML document to
specify which form the elements should go in, and have it bound either
outside the form, or bound in both with selectors to choose which.)
> One example of this kind of case is a form which accepts an address, where
> the post code can be filled in separately, and where there is a small form
> for this purpose which can do postcode number lookup.
Which is something that hasn't yet provided us with a problem, and
it's made much easier with the submit buttons being able to target
different resources. Seen as these things will not degrade in IE6
(let alone other UA's) in any case, I don't really see how this meets
the WHAT-WG principles.
> I meant not think about the structure. Many authors have told me they
> don't like having to think about whether the element they are adding to
> their large document is a child of the <form> element or whether they have
> to move the <form> element up a few divs (or tables) to make it include
> the element they just added.
So to simplify the authoring life of some really not to aware users,
you're going to allow them to create documents that don't work in all
legacy UA's? I'm sorry I think that is completely ridiculous use
case.
> If what I included in this e-mail is not enough for you, then I don't know
> what else to say, sorry.
how about just digging out the original discussion of the use case,
and post those.
Jim.
More information about the whatwg
mailing list