=====
CS 328 - Week 3 Lecture 2 - 2026-02-04
=====
TODAY WE WILL:
* announcements
* CLIENT TIER - continuing intro to HTML forms
* prep for next class
=====
* should be working on Homework 2!
* deadline: 11:59 pm on Friday, February 6
* must get at-least-1st-submissions in by then
* should be reading/working through activities in
zyBooks text Chapters 1 AND 2
("HTML Fundamentals" and "More HTML")
* we'll be using this material this week and beyond
(although for full credit for the activities,
they need to be completed by 11:59 pm Friday, February 27,
the Friday before Exam 1)
=====
REMINDER: classic approach using HTTPS/HTTP and HTML forms
=====
* are using HTTPS/HTTP, HyperText Transfer Protocol [Secure], here;
* the heart of the web!
* Very simple request/response protocol
* Web client sends [encrypted] request message,
web server replies with [encrypted] response message
* STATELESS -- each request/response pair is INDEPENDENT!
* so, consider this classic approach involving HTML forms:
* [summarizing/adapting figure from Shishir Gundavaram,
"CGI Programming on the WWW", O'Reilly]
* user enters a URL for an HTML page on the web
into a browser:
URL
browser/client tier --------> web server/application tier
* the web server on the application tier retrieves that
HTML document including a form, and sends it to the
browser on the client tier, and the browser executes
that HTML, displaying the document and the form:
HTML
browser/client tier <-------- web server/application tier
* say the user fills out the form, and clicks its submit
button; browser packages up the form data and sends it
AS PART of this request:
form data
browser/client tier ---------> web server/application tier
* the web server on the application tier may send this
request-including-form-data to another "thing" on the
application tier to process it --
(e.g., a PHP Preprocessor, or a Java Servlet Engine,
or server-side JavaScript processor, or other
Common Gateway Interface (CGI) application on the
application tier)
* this PHP Preprocessor/Java Servlet Engine/
server-side JavaScript processor/other CGI application
MIGHT make request(s) from the DATA TIER to craft
its response!
THEN it sends its completed RESPONSE to the web server,
to send back to the browser:
response/output
browser/client tier<-------------- web server/application tier
... and the browser executes that response,
displaying the results;
=====
HTML form element
=====
* this IS an HTML block element
* it typically contains widget elements that allow a user
to specify info they want to submit, and to ask to that
it be submitted
* widget elements? such as submit buttons, textfields,
radio buttons, checkboxes, texareas, drop-downs, and
more!!
* for this particular classic approach,
make sure these widget elements are INSIDE
the body of a form element!
* CS 328 course style: each form element is required
to include at least one input element whose type="submit",
whose purpose is to submit the form's information
* more on this input element below!
* form element CAN have many attributes, but:
* REQUIRED form attribute: action
<form action="..." ...>
specifies the server target's URL to which the form data
should be submitted
* ALSO-should-have form attribute: method
* values: either "get" or "post"
* if form has NO method attribute,
method="get" is ASSUMED
* when a form is submitted, the form widgets that do have
data to send each result in a name=value pair
* method="get" - the browser appends the name=value
pairs for the submitted form to the END of the action
URL, following a ?, and separated by &
* method="post" - the browser includes the name=value
pairs for the submitted form in the HTTPS request body
NOTE:
* the characters allowed for transmitting these name=value
pairs are LIMITED, so other characters
will be encoded into legal variants (space becomes +, for example)
* quickie mini-example: for a form with
<form action="https://www.google.com/"
method="get">
...
let's say that form, when submitted, has two widgets
that result in name=value pairs:
q=software+runaways
start=10
the resulting URL will be:
https://www.google.com/?q=software+runaways&start=10
=====
input element
=====
* actually used to implement a VARIETY of types of form
widgets
* (but there ARE also form widget elements that are not
input elements...)
* input element is an inline element -- needs to be within an appropriate
block element
* the type atribute of an input element specifies which
widget type that element is
* input is a void element - so, no content, and in
strict-style, end its tag with />
* FUN STRICT-STYLE REMINDER:
* attributes are to have values,
which are to be quoted
=====
how to write BINARY ATTRIBUTES using STRICT-STYLE
====
* yes, even so-called binary attributes such as
required -- (an optional attribute that is
ONLY included in a widget element
when you want to require the user to act on that
widget before the form can be submitted)
in strict-style, write: required="required"
(that is, typically:
bin_attrib="binary_attrib"
)
* frequently: input element's name atribute's value will
be the name included in the name=value sent for that
element when the form is submitted (but there are some
exceptions)
* what value will be sent?
...might be the value attribute's value!
...might be something else!
...it depends on the type attribute of the input element;
=====
input with type="submit" - classic submit button
=====
* <input type="submit" ... />
* do not confuse this with the more-general button element,
which is often associated with client-side JavaScript;
* CS 328 course style is to always have at least one
input element with type="submit" in each of your form
elements, whose purpose is to submit the form's information
* this creates a SPECIAL button on the form,
often called a submit button;
when this is clicked, the browser sends a request to the
web server, to the form's action URL, that includes
the name=value pairs for the form's widgets at that
moment
* if submit button has a value attribute, that value is
the displayed label for the submit button
...otherwise, its label is determined by the browser;
* (for example: compare what you get on Chrome and
Firefox...)
* if submit button has a name attribute, then a name=value
pair will be submitted for that button as part of the form's
information when that submit button is clicked
* (name will be the name attribute's value, value will be
the submit button's label text)
* frequently, it is not considered necessary to give a submit
button a name attribute
* (but if you have multiple submit buttons in a form,
it can be handy, so application tier can know which
submit button the user clicked...)
* see 4 silly examples in 328lect03-2.html!
* try each out, and see if you can explain the name=value pairs
submitted (or not) for each of these
=====
fieldset element
=====
* allows you to visually group elements/widgets in a form
* optional child element of legend lets you specify text
to appear on the border of that fieldset
* by default, typically is displayed as a narrow border around
the widgets within
=====
input with type="text" - classic single-line textfield
=====
* traditional single-line input textfield
* (will be the default if you don't give a type attribute
to an input element)
* most appropriate for: open-ended data that only requires a
single line to be input
* name attribute gives the name for the name=value pair
submitted from that textfield
* what value is sent? the value currently contained in
that textfield when a submit button from that form
is pushed
* a FEW of the useful optional attributes:
* placeholder - its value will display, but won't
be considered the textfield's value
* value - its value will display and if not changed
by the user, WILL be considered the textfield's
value -- appropriate for a common default response
* (there are numerous other useful optional attributes
an input with type="text" can have!)
* BUT: fun fact: an HTML textfield does not include any
instructions/label
* indeed, only a few HTML form widgets do!
* SO, it is also good to accompany a textfield with a logically-
connected label element...
=====
label element
=====
* text you want associated with a particular widget
* inline element, can have content
* GOOD style: you logically associate it with a widget
* ONE way to logically associate it:
give the label element a for attribute
whose value is the same as the id attribute of the
associated widget
=====
ASIDE: id attribute
=====
* NOTE!! -- any element can have an id attribute,
its value is EXPECTED and REQUIRED to be unique amongst
all the elements in a document...
* its purpose is to UNIQUELY IDENTIFY an element within
an HTML document!
* Why? just a FEW example uses for an id attribute:
* for associating a label element with a form widget element
* for specifying a location for an a element to jump to
within a document
* for specifying a target for CSS (Cascading Style Sheets) styles
* to work with client-side JavaScript
----- END OF ASIDE -----
=====
back to the label element
=====
* logically associating a label element with a form
widget element is IMPORTANT for assistive technologies!
* labels might be before, above, after, or even below
its associated widget -- can be HARD for a screen reader
to navigate
* also: many browsers will allow clicking ON this label's
content to highlight that widget, so the user's typing
immediately fills/affects that widget;
(this is also called setting the focus on that widget)
* this may make it easier for those with limited mobility
to navigate the form --
it also makes it more convenient for most users!
^ universal design!
from https://universaldesign.ie/about-universal-design:
"If an environment is accessible, usable, convenient and
a pleasure to use, everyone benefits."
=====
here's a CS 328 THEME to remember:
=====
choose form widgets that make sense for the task!
=====
* consider the possible options,
consider if the options are open-ended or from a specific set,
consider if they are choose-just-one or choose-zero-or-more,
etc.!
* using appropriate form widgets MAY improve the user's experience!
* using appropriate form widgets MAY reduce user errors in completing the form!
=====
ALSO: Living Standard HTML continues to add more form wodgets --
and, note, there CAN BE a lag
in browsers supporting new HTML features
SO:
=====
info on browser compatibility
=====
* MDN's HTML web docs:
https://developer.mozilla.org/en-US/docs/Web/HTML
...include BROWSER COMPATIBILITY info in its entries about different HTML
elements; COOL, and could be useful!
* Can I Use...: https://caniuse.com
can also help with checking browser support for different
web technologies