I tried implementing a form and I seem to stumbe upon yet another problem: I don’t succeed in getting the form where i want.
I tried resetting every positioning syntax there is but it wont move to the desired place.
And from that, how are we supposed to know what you want it to look like?
I’m guessing that setting the width of every cell in the table to 1px won’t be helping matters…
But really, you shouldn’t be using a table there at all. That isn’t tabular data, it’s a form, and there are proper elements to use in forms, like <fieldset> and <label>, rather than throwing things randomly into table cells.
Forms have their own semantics (relationships between labels and inputs etc.) so why confuse this with table semantics (relationships between rows and columns etc.)?
let me give you a typical example of where I routinely use tables in a form.
In a customised cms for a newsletter subscription website I will have a menu item called “Manage Users”.
When I extract the users’ records from the database and display them in a form I will have going across the page for each user record columns titled
userID, first name, last name, email, subscriptions, access level, edit, delete
The edit will be a link to a “user info” form and the delete will be a checkbox so I can delet multiple users in 1 go, but that is beside the point.
Imho these rows of users x 8 columns can legitimately be argued to be tabular data and so it is legitimate to use a table to display these rows and columns in a table within a <form>.
The table cells can still containg <labels> and other appropriate elements where required but in terms of aligning x number of rows by 8 columns correctly a table is much quicker and simpler for me.
If you accept the above as being valid then it makes no difference whether the data has 2,3,4 or whatever number of columns.
I agree that “generally speaking” tables are a no-no for content layout but as I say above, imho the above type of data can be argued to be tabular data.
yes you’re right - as I said it’s easier for me to line up 8 columns for x number of rows using a table for this type of data since it can be argued to be tabular data.
so can you please then give some example code (with I assume the required css) on how you would markup without using tables say 2 rows x 8 columns with the column titles I posted so that the userId, first and last names (text strings) are left justified and aligned vertically, the access level are 2 radio buttons (admin or user), subscriptions is a <select> and the edit and delete are links and checkboxes respectively and are aligned centrally with their “columns”.
Apart from myself, I am sure there will be others interested as well since
Personally I don’t like using tables (I wasn’t weaned on them) so I avoid them wherever not strictly necessary.
I wasn’t weaned on them either, but thinking a bit more about this (as I’m always happy to learn new things)…hmmmmmmm, interesting :scratch:
By “not strictly necessary” I asume you mean there is no other way of doing something with other html elements and css apart from using tables and I simply can’t think of a situation where that would be so - but I’m not a html/css expert , or an expert on anything for that matter.
Assumning you have used tables before, can you please post a code snippet of where you have in the past felt using a table was “strictly necessary”.
I was really just talking about tabular data. That’s where I would say it’s strictly necessary. I’ll have a look at your code question later, as I must run now.
Lately I’ve been experimenting with screen reader software, and that’s an eye-opener in terms of how information is presented. You wouldn’t want content read out as table data unless there really is a reason for form elements to be arranged that way. I’m not necessarily saying that that’s not appropriate for a form in some instances, but certainly in the OP’s case I’d say not.
I’ve never used screen reader software but I am aware of the principle of how they work and you make a valid point.
Regarding the OP’s code, when I ran it I thought you can argue it is tabular data but I concede that in his/her case it would not be too difficult to markup the elements without using tables.
But as the number of rows and columns become larger, and if I want a tabular appearance of the elements in the browser then for me it becomes much easier and quicker to use a table.
But I totally agree tables should not be used to create a common header, sidebar, content and footer layout.
btw- imho using tables is ok in this case because you can legitimately argue this is tabular data.
Uh, no? This form is three questions:
Name:
Email:
Comment:
SEND, CANCEL
No need for a table for that. The stuff ABOVE the form is tabular, yes. The form itself? No.
Looking at the form code the way it is now, that’s all you need: heck, you DON’T need the “field” classes on those divs, or any classes on the labels, because you can
#formulier div {
style divs in the form with the id of formulier
}
and #formulier label {
style labels in this form
}
Usually I have lots of forms and they start styles like this:
form div {
styles;
}
form label {
styles;
}
And then if I need something specifically different for a form, I’ll use the form’s id to reset that control.
I have done forms in tables for the reason Kalon has: sometimes a form is a user filling out a table. But then you have to build carefully: screen readers are more likely to see just the form stuff than the table stuff, so you make sure the table doesn’t get in the way and the relevant parts of the table are visible as “form controls”.
Brothercake did a table to a form in a clever way but I’ll have to look around to find it. It was rather brilliant.
Another issue: the mailto command. Does it automatically send what you wrote to the email adress or does it pop up an outlook or whatever email client for you? I don’t need the last. I want the comment sent directly
In some clients it pops up the email client, in other cases nothing happens at all (such as in Mac Mail). But in no cases does it send the email directly, so this is not the process to use. You really need to process a form with something like PHP.
yes I agree you can markup the elements without using tables but I would still argue that if the required visual display in the browser is to be a tabular display then it is legitimate to use a table to markup up the elements if the developer chooses to do so.
but I would still argue that if the required visual display in the browser is to be a tabular display
Unless I misread you, I believe I saw you say you thought the OP’s form looked tabular. I disagree that one can argue this needs or should even think of having a table.
And, if you are using a table for layout and display purposes, why stop at forms? You can use tables for whole pages for that reason then. Just saying.
But definitely if you can see that the user is filling in a table… yeah, makes sense to use a table in the first place. As you say, the results are then returned in the same manner they were filled in.
Actually the only thing saving my butt in my old table-forms is the use of the title attribute, because otherwise many readers aren’t going to hear the table headers at all. In a real table, if the inputs are in td’s, often the “label” text is equal to the combination of the column header and the row header. While you can mark up a table to have that td be associated with the headers correctly, for readers who go into a Forms Mode (to type into the inputs), the table stuff can be and is ignored. So later when I bring that table back, filled in, everything’s fine: it’s a normal table with values and everyone can read it. But as a form I have to be really careful… and possibly Orca screen reader is missing the titles (but might be reading the table headers so not sure on that one).
