I keep hearing that div
tags should be used for layout purposes and not table
tags. So does that also apply to form layout? I know a form layout is still a layout, but it seems like creating form layouts with div
s requires more html
and css
. So with that in mind, should forms layouts use div
tags instead?
相关问题
- Views base64 encoded blob in HTML with PHP
- Laravel Option Select - Default Issue
- Is there a way to play audio on a mobile browser w
- HTML form is not sending $_POST values
- implementing html5 drag and drop photos with knock
If your forms are laid out in a tabular format (for example, labels on the left and fields on the right), then yes, use table tags.
I think it's a myth that forms are "difficult" to layout nicely with good HTML and CSS. The level of control that CSS gives you over your layout goes way beyond what any clunky table-based layout ever would. This isn't a new idea, as this Smashing Magazine article from way back in 2006 shows.
I tend to use variants of the following markup in my forms. I have a generic .form style in my CSS and then variants for text inputs, checkboxes, selects, textareas etc etc.
Tables aren't evil. They are by far the best option when tabular data needs to be displayed. Forms IMHO aren't tabular data - they're forms, and CSS provides more than enough tools to layout forms however you like.
Most of the answers I've seen here seem appropriate. The only thing I'd add, specifically to apathetic's or Mr. Matt's is to use
<dl>/<dt>/<dd>
. I believe these represent the list semantically.You might want to restyle these, but this says semantically what's going on, that is you've got a list of "terms" (
<dt>
) and "definitions" (<dd>
), with the term being the label and the definition being the user entered values.One thing that I don't often see discussed in these form layout questions, if you've chosen a table to layout your form (with labels on the left and fields on the right as mentioned in one of the answers) then that layout is fixed. At work we recently had to do a quick 'proof of concept' of our web apps in Arabic. The apps which had used tables for form layout were basically stuck, whereas I was able to reverse the order of all the form fields and labels on all my pages by changing about ten lines in my CSS file.
It's a grey area. Not everything in markup has clearly defined boundaries, and this is one case where you get to use your personal preference and make a judgement call. It doesn't quite fit the idea of data being organised, but the cells are related across multiple axes, and that's the rule of thumb I use to decide whether something fits in a table or not.
The general principle is that you want to use whatever HTML elements best convey the semantic content that you are intending and then rely on css to visually represent that semantic content. Following that principle buys a lot of intrinsic benefits including easier site-general visual changes, search engine optimization, multi-device layouts, and accessibility.
So, the short answer is: you can do whatever you want, but best practices suggest that you only use table tags to represent tabular data and instead use whatever html tags best convey what it is that you are trying to represent. It might be a little harder initially, but once you get used to the idea, you'll wonder why you ever did it any other way.
Depending on what you are trying to do with your form, it shouldn't take that much more markup to use semantic markup and css, especially if you rely on the cascading properties of css. Also, if you have several of the same form across many pages in your site, the semantic approach is much more efficient, both to code and to maintain.