You need a name, as that’s what determines the key in the key-value pair sent to the form’s target. You need a type, as that’s what tells the browser whether it should show a text box or a check box or a select list, etc. Everything else is optional. If you’re not using the id or class for JS or CSS then you don’t need them.
Thats optional however very recommanded, it associates the label with the input field that has the same id as the for on the label (like in ur code)
A label that is associated with a control via for will be clickable. Clicking it selects the control. Highly useful with radio/checkboxes in particular. It also has accessibility implications for screen readers for the visually impaired.
Yes. That’s what connects the label text to the input field so that people who can’t see the form know what label text goes with which input field. Without it they will have no way to know which input field is supposed to contain what.
(I have seen a lot of people use that technique.)
is a pretty weak justification because it implies a “follow the herd” mentality. A lot of sheep use tables for content layout because they see other sheep in the flock and their shepherds still using them
I agree with kohoutek. There are enough form elements that there is no real purpose to using list items. Can it be semantically justified as being a meaningful list of something?
The UL looks like complete nonsense where it has been placed and the FORM, form control LABEL is associated with INPUT it is not a list no more than this paragraph is a list.
The people that use LI for form layout, e.g. wrapping of INPUT are doing it for laziness reasons or a slight misunderstanding of how semantics work in nearly every case.
Having more than one control input does not merit a list; having a multiple-choice check box might but that is a different kettle of fish anyway.
I’m not sure that makes it correct. Sometimes books are written at a time when certain ideas are considered nifty or “in” for that moment. For example, I still have books that propound the use of tables for layout.
I hope so, because I have all the Christmas Cookies!!!
I’m not sure that makes it correct. Sometimes books are written at a time when certain ideas are considered nifty or “in” for that moment. For example, I still have books that propound the use of tables for layout.
We can wait for Paul O’ to be the tie-breaker…
If it turns out that I am wrong on this, it will be a shock, because here I thought I had really rock-solid HTML and CSS thanks to everyone here at SitePoint. (Who knows, maybe this is one that escaped me?!)
The SitePoint book “Fancy Form Design” (2009) uses list tags as wrappers around all the form content. I don’t remember seeing a more recent book suggesting a different alternative.
The W3C examples use <p> tags which is definitely wrong and also suggests <div> tags as the alternative.
One way in which div tags would have an advantage over a list would be if you later device that one (or a group) of form fields deserves to be wrapped inside a <fieldset> which if you were using a list would mean splitting the list up into several separate lists. I can’t think of any other benefits though so if you have a lot of fields in the form and know you’ll never seed to wrap pieces of the form in fieldsets then using a list means using shorter tags than the alternative.
There are no semantic tags in HTML to specifically identify a form field and its associated label so this is probably the area with the greatest disagreement between people attempting to use semantic markup as to just which is the most appropriate tags to use.
Yes, it is quite possible you learnt that technique from book but like was mentioned they sometimes seem to use “trends” or have bizarre ideas and try to make square pegs fit in round holes. Even forcing markup to jump through hoops it was never designed for and try to justify themselves.
The list fetishes are a common one in the industry where they can loose sight and see lists everywhere where there are none. If you get someone publishing it then many believe the hype. As with HTML5 it is so badly implemented there are already second edition books on a non normative language.
I think people some times forget that there are no enforceable rules, standards, call them what you want for html markup. All we have is a set of non enforeacble recommendations from the w3c. Given that we should be using a Strict doctype nowadays, then as long as the html passes the w3c validator then structurally it is ok. We should also be using be using semantically correct elements for the content. Most of the time what is correct semantically is obvious but many times what is semantically correct can be a grey area and open to individual interpretation and opinions. It can even be argued that form inputs/controls lined up vertically and horizontally is tabular data. Others might argue that you could have a list of form inputs or controls. Provided the html with a Strict doctype passes the w3c validator then it’s really a matter of opinion whether a list, table or other elements are used to contain form inputs/controls - there is no such thing as a html markup god/adjudicator/tie-breaker or whatever