Thus far we have focused on one half of the communication process: the “speaking” of our ideas to our sites’ visitors. Generally this is not enough. We would like to hear back from our visitors. We want them to join a mailing list, make an order, contribute an idea, vote, and who knows what else. We need information from them. Enter HTML forms.
Many of you in this class will be professional communicators. Forms are kind of a big deal to you. Books don’t have them. Nor do radio and television. But our websites do. What power! Forms are a doorway; they make the web a two-way street. Your words go out, and their words come back.
Doorway might not be a good term. Funnel might be a better term. For other humans to fit themselves into your system, they must contort themselves into the shape imposed on them by your form. If you require a first name, middle name, and last name, you are assuming that all humans have this amount of names. If you ask for a 5-digit ZIP code, you are assuming that all humans live in the United States. If you allow only ten characters for a first name, you are microagressing.
If you find yourself designing forms in the future, please be a sensitive person. Do not pigeonhole your users into being people just like you.
There’s a lot of really fascinating differences between people, things that aren’t even contentious! Like our favorite flavor of ice cream. Speaking of, let’s jump into our lab activities for the day.
We’ll start today with a quick demo of the possible form widgets that you read about in your book. Then we’ll jump into two tasks for our lab:
Here’s your TODO list:
See you next time!
Today we construct some forms, which give our page’s visitors a chance to contact, comment, and credit card. (Seriously, don’t process credit cards without studying up extensively on security.)
First create a
lab19 directory. Add a
partners.html and include your first names and last initials.
contact.css a form that looks like this:
Make sure you give each form element a
name attribute identifying the semantic meaning of the data being entered. The form-forwarding services require
name attributes to be set.
Be sure to match the following:
Fix the width of the form to some number of pixels. Make each of the first three rows a
label element, and nest the text description and the
input element inside.
If we actually wish to communicate the data from a form to a human being or a program that can process it, we must define the form’s
The location of the webpage that does the emailing or processing is specified as the
action. We will use a third-party form processing service as the
method should be
post, which means the form data is bundled up in something very much like an email attachment and sent to the page specified by
action. The alternative is
get, which packs all the form data into the URL/address of the page. This makes the URL very long and unwieldy. You’ve probably seen these URLs with
get requests embedded in them. We get them in email all the time. Like in the links to CS 318 quizzes!
Writing the page that handles a form submission is a topic for a more advanced course. However, there a few free services that can forward our form data to an email address. Check out one of these:
Follow the service’s directions to get your form submitting to your email address. Please show or forward your instructor a submission email.
icecream.css a form that looks like this:
Observe the following requirements:
selectfor the lists. Consult MDN to see how to make it display multiple options.
rangeinput for the slider. (This input helps the server determine how many napkins to provide.) Limit it to the range [0, 3].
Commit and push your work. Verify that all pages have been uploaded by visiting
https://USERNAME.github.io/cs318/lab19 in your browser.
Validate your pages with the W3C Validator. Paste in the URLs to your pages, one at a time, and address all concerns raised by the validator. Fix your changes on the local machine, commit, and push until the validator reports no errors or warnings.