- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 21 Jan 2005 11:38:02 +0000 (UTC)
On Sun, 16 Jan 2005, [ISO-8859-1] Olav Junker Kj?r wrote: > > The real problem is that there is no way to declare that all form > controls in a single table row is part of the same dataset and should be > submitted (and updated) as a unit, since HTML does not allow TR elements > to be contained directly by a FORM. This is a serious problem, since > tabular data which you want to edit "row by row" is exactly the type of > data TABLE was intended for. True. Authors will effectively be forced to have a <form id="rowNNN/> in the first column of each row, and then have form="rowNNN" on each form control. Not perfect, but we can't really change the <table> content model (table parsing is already a house of cards, making it worse is a legacy content minefield). > But maybe its just because I understand the semantics of the form > element incorrectly? I think of a form as as a grouping of related input > fields which is edited by the user as a whole. By this understanding, it > makes sense to have the form defined by containment. OTOH, if the form > element is thought of more like the data model in XForms, then it makes > sense to define the FORM separately from the input widgets, and allow > widgets to bind to several data models. I dont think this fits too well > with how forms usually are thought of in HTML, though. The beauty (?) of the Web Forms 2 definition is that you can use either model, as you see fit. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 21 January 2005 03:38:02 UTC