This chapter is about online forms. Online forms are more relevant than expected because even online search engines and login screens are forms at heart but dressed up to not look like the forms you fill out for online forms.
However, the knowledge of HTML for forms is practically only half of what you need for making a working form. The other half is the back end server-side processing, though such knowledge of programming various databases are outside the scope of this class. (That is most likely how form logic, such as checking for invalid forms of phone numbers, are checked after submission - if that is not already done in real time with JavaScript).
This is where you learn what a select list, radio button, and check box looks like.
Again, the chapter is quite long because it is unavoidably full of reference information contained in tables and necessary figures to show how options will render.
Otherwise, there is not much to this chapter, other than getting yourself to plow through reference information and doing the Practice Exercises.
Password boxes are even components of forms - though they most likely need server-side processing in order to be actually useful.
Scrolling text boxes are nearly not used frequently enough to accept longer free-form responses, in my experience - even for surveys.
By the way, I think website builders should stop using HTML to launch the user's default e-mail client. Instead, the e-mail address should be displayed for users to decide for themselves what client they wish to send an e-mail with. (This is just my opinion, but the book also mentions this point in this chapter.)
I would prefer to always have a standard submit button. It is always more inherently extensible and interlopable with accessibility and also just plain simple - keeping in line with KISS. Having a custom image button for form submission seems like a fad from the 2000-nots that has not aged well - sort of like Word Art.
Of course, forms can be styled with CSS, just like most other ordinary elements of HTML that have visual outputs/rendering.
Server-side processing is the second half of making online forms IRL - otherwise, you have this situation like with the Wired Sounds for Wired People site. (If you have heard of this "Internet oddity" before, then do not be duped - allegedly, there is no server-side processing for the mysterious login page to even work.)
The book has you practice with a trivial dummy server-side script. For the real world, web programmers are typically split into two heuristic tribes (unless the team is so small that you have to do everything yourself): front-end and back-end. Front-end developers usually take care of what the website looks visually for end users but should be able to pull ready made back-end scripts when needed (so, everything in the book so far, and some more), while back-end users have to set up database processing and other server-side processes that allow for site interactivity interesting enough for normal end-users to make use of. However, the back-end programmers should be mindful that they are helping make a usable end product. (The front-end developers need to be mindful of the value of the back-end developers, too - much like visible actors and backstage hands in a theater play.)
HTML5 offers some unique form fields that base HTML does not, though most of these should be obvious for the usable Internet today or can be looked up in references as required. E-mail, URL, and telephone number fields are pretty obvious. Search fields are nearly taken for granted, given how ubiquitous search engines are. Datalist form controls (i.e., picking from a presorted list of options in a drop-down menu) is also pretty direct with its purpose.
Sliders (dragging a pointer along a line segment) seem rather fancy. I personally would prefer to use a spinner (a number box that you click up/down to increase/decrease the number) is better, since not everyone using the Internet is able to have fine motor skills to drag a slider, especially if it is pretty granular in interval increments with respect to the total scale range.
Calendar form inputs heuristically have only two visual looks, since basically all web browsers are Firefox-based or Chromium-based.
Color-wells are not common, but it is nice to know and have as an option.
The concept of progressive enhancement is repeated at the end of this chapter.
The JavaJam site assignment is straightforward. You are only creating a Jobs page and making a form to accept job applications. Of course, this form is way too simplistic for the real world. Most businesses would simply use job application services, probably as a "plugin", to accept job applications so that it would have rigorous and robust online form rules and validations.