=====
CS 328 - Week 3 Lecture 2 - 2025-02-05
=====
=====
TODAY WE WILL:
=====
* announcements
* CLIENT TIER: intro to HTML forms
* prep for next class
=====
* should be working on Homework 2!
* at-least-1st-attempts submitted by 11:59 pm on
Friday, February 7
* should be reading Chapter 2 - "More HTML" in the course
zyBooks text as well as Chapter 1
* should be doing this now, to help with the next lab
exercise and homework and beyond
* for full zyBooks credit, deadline for completion is
Friday, February 28 (the Friday before Exam 1)
=====
quick notes about HTTP/HTTPS
=====
* 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 with HTML forms involved;
* [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;
=====
intro to HTML form element
=====
* a form element is a group of form widgets (and possibly other elements)
that allow a user to submit information to a web server
* one of the classic approaches for providing
a graphical user interface for such applications
* form widgets? these are elements such as
submit buttons, radio buttons, checkboxes,
textfields, textareas, and LOTS more;
* form element CAN have many attributes,
it MUST have one: the attribute action,
(and I think it SHOULD have the attribute method as well)
* action attribute: has as its value the URL of the thing
on the application tier that is going to handle this
form's data when it is submitted
* can be absolute or relative
* method attribute: has as its value "post" or "get"
* get: the name=value pairs from a submitted form
are APPENDED to the action URL, after a ? character
* post: the name=value pairs from a submitted form
are passed within the HTTP/S request body
* if no method attribute is given, method="get" is
assumed (it's better to always specify it, though!)
* when a form is submitted, the form widgets that do have
data to send each result in a name=value pair,
these are separated by a & to build the string to be sent
* the characters allowed for these 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
=====
* used for implementing MANY kinds of form widgets
(but not all of them)
* it is a void element!!!!!!!
and it is an inline element
* its type attribute determines which type of form
widget it is
...if none is given, you get type="text"
but it is better to always explicitly include a type attribute
=====
submit button - input element with type="submit"
=====
* <input type="submit" ... />
* often called a submit button
* looks like a button -- and the user does click it --
BUT it has a special, specific purpose for a form;
* do not confuse it with the button element,
which is more general, and often associated with
client-side JavaScript
* when a user clicks a form widget that is an input element
with type="submit":
* the browser gathers the name=value pairs for JUST the
form element that submit button is within,
* and sends them to the form's action attribute's URL
based on the method specified by the method attribute
* CS 328 course style is to always have at least one explicit
input element with type="submit" in each of your form
elements
* if this has no name attribute, no name=value
pair is sent for the submit button widget itself
* (after all -- its purpose is often JUST to send
the form information to the web server; it may not
necessarily need to provide any additional info itself)
* however, if it DOES have a name attribute, it WILL send a name=value
pair, where the name is the value of the name attribute,
and the value is the text displayed on the submit button
* if it has a value attribute, that will be used as the
submit button's label
* if not given, the browser will give it a default label;
oddly, this is not standard between browsers!
(compare Chrome and Firefox, for example)
* SO -- if it has a name attribute, the value for the name=value
pair will be either the value attribute's value OR the
submit button's label if there's NO value attribute
* 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
=====
before we go on: here's a 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.!
* these MAY improve the user's experience!
* these MAY reduce user errors in completing the form!
=====
BUT: HTML5 added a LOT of new form widgets -- and, note,
as HTML continues to develop, there IS 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
=====
textfield: input element with attribute type="text"
=====
* single-line text entry widget
* most appropriate for: open-ended data that only requires a single line
* SHOULD have a name attribute! (its value will be the name
in the name=value pair)
* it CAN have many other attributes,
such as value (its value will be initially displayed within
the textfield)
* when the form containing it is submitted,
the name in the name=value pair will be the value of the
name attribute,
the value will be whatever is in the textfield when the
form is submitted
=====
label element
=====
* BUT: fun fact: an HTML textfield does not include any
instructions/label
* indeed, only a few HTML form widgets do!
* GOOD STYLE is to associate the instructions/label for
a textfield (as well as other form widgets) using a
label element
* this logically associates that text WITH that element
* this 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."
* so: label element IS an inline element,
and it can have content, which will be displayed and will be
the text that will be logically associated with its
associated form widget
* there are TWO ways the label element can be logically associated
with a particular form widget;
but to explain one of them, we need another attribute:
-----
IMPORTANT ASIDE: id attribute - unique identifier for an HTML element!
-----
* ANY HTML element can have an id element,
whose value should be a UNIQUE value that NO other element in
that HTML document has
* we'll see that different elements may have the same value
for their name element,
BUT no two (or more) elements within an HTML document
should ever have the same value for their id element
* Why? some 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 -----
* SO, back to how to write a label element:
there are TWO ways the label element can be logically associated
with a particular form widget;
* if the form widget has an id attribute,
you can give the desired label element a for attribute whose value is
that widget's id attribute's value,
and that label will be logically associated with that
widget:
<label for="lastname"> Last Name: </label>
<input type="text" name="last_name" id="lastname" />
* this version makes CSS styling easier!
* this version is demo'd in 328lect03-2.html
* or, you can nest a widget element within a label element,
as part of the label element's content;
that is, if the label's content INCLUDES a form widget as well
as text,
then that label will be logically associated with that
widget:
<label> Last Name: <input type="text" name="last_name" /> </label>
* no id attribute is needed for the form widget,
but this version DOES make CSS styling trickier;
* you will try out these, and experiment with some more form widgets
and related elements, in the Week 3 Lab Exercise (and Homework 3 and
beyond)