There is nothing about a <form> tag that makes it "tabular". Many form's just dont fit into neat columns and rows. These days I code elements firstly so they are semantically correct. Then I use CSS to attempt to lay them out as best as I can (with what I know and what I can teach myself from all the online resources). And, as the other parts of this thread show, you can do a HELL of a lot with CSS to layout semantically created <form>s. After that I will look too using the smallest amounts of _javascript_ to "tweak" things at runtime. Then (and this is usually when what I am building is an application that just happens to use a browser) I will go to using larger amounts of _javascript_ - but then I am usually in control of the end platform and can restrict the browser appropriately (be it IE or Firefox - for example).
The data that is collected by a <form> tag may have a consistent schema to it (such as name, address, phone) which is stored in a database as a collection of like objects (what we usually call a "table") - but even that does not justify a <form> as being "tabular" data.
What constitutes "tabular" data is when you want to display such a collection of like objects (which may or may not come from a database "table") in a manner that can be considered, semantically, "tabular". Or when you clearly are working with items that semantically are a grid (
e.g. a spreadhseet, or a even a complex report of some kind).
We (and I do it too - but I think it is very lazy) have always just thought of forms on the web as just being a set of labels and fields rolling down the screen (because that was all that was ever possible). Whereas the print world (and just about everyone else) things of forms as information placed as clumps on the page that make sense to be grouped together. So we should be embracing that view now that we have CSS to help us lay things out (although it is still not perfect).
Semantically (i.e. the meaning attached to the tag actually representing what the tag is actually doing) a <form> is exactly that (something that contains tags that will collect data). This then generally implies that you would find <label> (something to give the user feedback on what information was being requested) and <input/select/textarea> (places to put the data - my own personal opinion being that we should only have an <input> tag with attributes to tell it how to behave OR that the <input> tag should only be for text and not for type="radio" or type="checbox" as these are semantically different elements). That said, the next question may be "What about tabular data that you want to input as a result of a parent/child relationship?". My answer to that is that HTML/XHTML is lacking any suitable construct to achieve this (
i.e. there needs to be some type of tabular entry element in the specification that allows such data entry for a form). So, in this case, (i.e. to visually layout some fields in a <form> that need to accept data in a tabular way - yes it is a <table>).
And, with all that said, it's only just my opinion (gleaned from all the available information on the semantic approach to markup).
But, when the chips are down and you have to deliver, you do what works.
Regards,
Gary Menzel
On 5/1/05, Cole Kuryakin - x7m <[EMAIL PROTECTED]> wrote:
I've been wondering the same thing as Tee ->> whether to use the table for form or not, still can't make up my mind.I've been using tables for my forms just because it's fast and easy to align stuff - like a horizontal double or triple-column input design or even putting a text label AFTER a check box or radio button - but I don't want to take "the fast way out" if using tables for my forms is not adhearing to the spirit of web standards or accessibility.I have read elsewhere that using tables for form elements is permissable as it's considered "tabular" data.I'm interested in the group's overall opinion on this subject.Cole
