You may want to ask if the PHP stuff in that tut are any good over in the PHP forum.
Re the HTML/CSS
my only real comment on the HTML is that they’ve wrapped each label-input pair in a p instead of using a fieldset around the whole thing:
<form…>
<fieldset>
<legend>contact</legend>
form elements
</fieldset>
</form>
…however, that is up to the developer when the form is short like this one is. It’s already obviously a contact form so the legend is redundant here, and using a fieldset means you must have a legend as well.
Also then since labels and inputs are inlines, either css would have to make the labels blocks or you’d add br tags to the HTML (I consider br’s to keep a form’s content clear to be an acceptable use of br). The way this tut uses br though is kinda silly: there is no content reason to make a split between label and input, only a content reason to split each label-input pair. To keep the labels alone on their lines, they should have used CSS to make the labels blocks.
label: input
label: input
label: input
is readable
label:
input label:
input label:
input
is less so.
So, not bad.
The CSS:
12px sized fonts are… 1990. Unless your text is lining up with background images, let the font size adjust to the page. IE will not enlarge text set in px when the user does text-enlarge (this is not the same as zoom, which will always enlarge everything), not even IE9.
The red of the error messages, and the fact that the error messages are in spans, who come AFTER the invalid input, are not great for usability/accessibility.
Red on black isn’t the most readable combination, and will fail colour-contrast minimums on any contrast-checker.
Having the error announced after the input doesn’t matter so much for graphical users, but means users of any linear browser come across the label, the input, and the error last. The error should be first. And in a readable colour.
The errors are also a great place to use ARIA attributes: give the error message an id and the label’s aria-describedby can link to it… if you do this, browsers and screen readers who understand ARIA roles will be fine if the errors are after the input; you have the possibility of hearing the error first with the label if you want.
The error list they have at the top of the page is a good idea. What makes it a better idea is making those links (only if it’s a long long form though) to the individual problem-questions. This also gives keyboard users a quick way to jump to the first wrong question.
.button:hover {
background-color:#f1f1f1;
color: #333;
}
You see they forgot about all those mouseless devices out there again. :focus :focus :focus, people.
I also don’t see the point in setting textareas to pixel height and widths: textareas MUST have cols and rows attributes anyway, and since those do differ from browser to browser, use percentages in CSS to make the width at least the same cross-browser.
Since the form has a fixed width (should be fixed in a flexible width though, like em’s), the textarea can be width: 100% and look the same cross-browser.
#contact_form_wrap {
margin:0 auto;
margin-top:50px;
In case you were wondering, no they don’t need two lines for that:
#contact_form_wrap {
margin: 50px auto 0;
}
Padding’s been set on the form but if you build a form and do decide to use a fieldset, keep in mind those have default padding and sometimes margins in browsers, so set both the form and the fieldset to margin: 0; padding: 0 before furthing in style. Also, legends are a problem to style as well.
If your contact form is as short as this one, you can leave out a fieldset. However a header above the form should state something about “contact us” or “contact form” or whatever.