, , , , , Marks the beginning and end of a heading. Each
and heading tag represents a different heading level.
is the highest level.
Marks the beginning and end of a section
of bold text.
Marks the beginning and end of a section
of underlined text.
Marks the beginning and end of a section
of italicized text.
Marks the beginning and end of a section with
special font characteristics. Contemporary practices
avoid this tag and express font information, instead,
within Cascading Style Sheets. The tag is
not supported in HTML5. See Table 17.2 for some of
the available font attributes.
Defines an anchor—typically used to mark a link. The
link destination URL appears inside the first tag
as a value for the href attribute (as described later in
this section).
![]()
Specifies an image file that should appear in the text.
The file URL appears in the tag as a value for the SRC
attribute. (You’ll learn more about attributes later in
this section.)
334 HOUR 17: HTTP, HTML, and the World Wide Web
Of course, there is much more to HTML than a single table can convey. Many tags apply to a
block of text. If so, the tag appears at the beginning and the end of the block. The tag at the end
of the block includes the slash character (/) to signify that it is an end tag. In other words, the
callout for an H1 heading would be tagged as follows:
Dewey Defeats Truman
An HTML document is supposed to begin with a declaration. The !DOCTYPE
defines the version of HTML used for the document. For HTML 4.0, the !DOCTYPE command
is as follows:
(Web pages that use special browser extensions might specify a different document type.)
Most browsers don’t require the !DOCTYPE statement, and many HTML tutorials don’t even discuss
the !DOCTYPE.
Following the !DOCTYPE statement is the tag. The rest of the document is enclosed
between the tag and a corresponding tag at the end of the file. Within the
beginning and ending tags, the document is divided into the following two sections:
The head (enclosed between the and tags) contains information about
the document. The information in the head does not appear on the web page, although
the tag specifies a title that will appear in the title bar of the browser window.
The <title> is a required element. Other elements of the <head> section are optional,
such as the <style> tag for information on document styles.
The body (enclosed between the <body> and </body> tags) is the text that actually
appears on the web page and includes any HTML tags related to that text.
A simple HTML document follows:
<!DOCTYPE HTML PUBLIC "-//W3C/DTD HTML 4.0//EN">
<html>
<head>
<title> Ooh This is Easy
Easy!
If you save the preceding HTML to a text file and then open the file with a web browser, Easy!
appears in the browser window. (Depending on your browser and operating system, you might
have to save this file with an .htm or .html extension or open it as an HTML file.) The title bar
includes the title Ooh This is Easy (see Figure 17.3).
Understanding HTML 335
FIGURE 17.3
A very easy web page example.
You can spice up the page with additional text and formatting in the body section. The following
example adds the and tags for headings, the
tag for a paragraph, the tag
for bold, the tag for italics, and the tag for font information. Note that the
tag includes an attribute. Attributes are parameters enclosed within the tag that provide additional
information. See Table 17.2 for other font attributes. As you will learn later in this hour,
professional webmasters use Cascading Style Sheets to manage fonts, but the tag, which
is supported through HTML4 but is not found in HTML5, is an easy option for making your first
HTML experiments.
Ooh This is Easy
The Easy and Hard of HTML
Webster's Dictionary defines HTML as "a small snail found originally
in the Canary Islands and ranging now to the Archipelago of Parakeets."
I borrow from this theme in my consideration of HTML as a language that is both
easy and hard.
HTML is Easy
336 HOUR 17: HTTP, HTML, and the World Wide Web
HTML is easy to learn and use because everyone reacts to it energetically.
You can walk into a bar and start speaking HTML, and the man beside you will
happily tell you his many accomplishments.
HTML is Hard
HTML is hard because the options are bewildering. You never know when to use
small text and when to use big text.
TABLE 17.2 HTML Tag Attributes
size Relative font size setting. Values vary from 1 to 7: .
lang Language code denoting the language in which the text is written.
face Typeface setting: .
color Color of the text: .
The preceding example appears in the browser as shown in Figure 17.4.
FIGURE 17.4
Expanding the easy example.
As you learned earlier in this hour, the hypertext link is an important element of web design.
A link is a reference to another document or another part of the current document. If the user clicks
the text of the link, the browser immediately opens the document referenced in the link. The effect
is that the user appears to lilt through an endless garden of colorful and informative content.
Cascading Style Sheets 337
BY THE WAY
What is a Browser?
As you lilt through this colorful garden, pause occasionally to consider that the term browser
originally referred to a giraffe or a large dinosaur eating leaves out of trees.
A link appears in the HTML file as a tag. The simplest form of a link uses the tag with the
URL of the link destination given as a value for the HREF attribute. For instance, in the preceding
example, if you would like the words “Archipelago of Parakeets” to appear as hypertext with a
link to a website that tells about the archipelago, enclose the words within tags as follows:
ranging now to the Archipelago of
Parakeets. I borrow from this theme
The versatile HTML format includes many additional options. You can place a hotspot link
inside a picture. You can create your own style sheets with special tags for preformatted paragraph
styles. You can structure the web page with tables, columns, forms, and frames. Or you
can add radio buttons, check boxes, and pull-down menus. In the early days of HTML, designers
coded all the HTML directly into their documents using text editors (as described in the preceding
examples). Professional web designers now work with special web development applications,
such as Adobe Dreamweaver, that hide the details of HTML and let the designer view the page
as it will appear to the user. New tools such as wikis and content management systems (CMSs)
provide additional options for effortless web design.
Static, preformed HTML documents like those described in this section are still widely used, but
many websites today use dynamic HTML techniques to generate the web content at the time of
the request.
BY THE WAY
Capitalization
With classic HTML tags, capitalization is not significant; however, later standards such as Extensible
Markup Language (XML) and XHTML pay more attention to capitalization. XML is case sensitive, and
XHTML requires lowercase element and attribute names.
Cascading Style Sheets
Although it is possible to encode all formatting instructions into an HTML document (fonts, font
sizes, line types, etc.), in practice, repeating the same tags over and over for the same few style
elements is cumbersome. Perhaps more importantly, on-the-fly modifications can lead to inconsistency
and an unpolished, overly complicated design.
338 HOUR 17: HTTP, HTML, and the World Wide Web
A better approach is to define standard style elements for the document and put them in one
place, then reference those elements in the text. Researchers at the World Wide Web consortium
developed Cascading Style Sheets (CSS) as a way to corral style information in a single document.
The goal is to make HTML more like a modern word processor or desktop publishing tool,
which lets you pick from a list of predefined character or paragraph styles. The style defines a set
of parameters, such as the font size, color, spacing, padding, and margins.
Using a CSS separates the document contents from the presentation information. This approach
makes the HTML much easier to read, and it imposes a stylistic consistency on the document,
which is considered good design practice.
For example, a heading style might be defined as follows in the CSS document:
h1 {
Color: black;
Font-family: Arial, sans-serif;
Margin: 0 4px 0 0;
}
As you can see, the definition consists of colon-separated attributes and values. The items in the
list are separated with semicolons, and the whole style block is enclosed in {}.
The actual callout for the heading in the HTML document then just has to refer to the style:
This Is the Heading
And the attribute values for the style are all applied to the heading.
A Cascading Style Sheets file (with a .css extension) is a common sight on websites today. The
HTML file can reference the CSS file as follows:
Understanding HTTP
As you learned earlier, web servers and browsers communicate using the Hypertext Transfer
Protocol (HTTP). HTTP 1.1, which arrived in 1997 with RFC 2068 and is currently defined in RFCs
7230-7235, was the dominant version of HTTP for many years. A new version, known as HTTP/2,
appeared in 2015. HTTP/2, which is based on Google’s SPDY protocol, primarily provides performance
enhancements and is not intended as a replacement for HTTP’s semantics or status codes.
Many websites and browsers now offer support for HTTP/2, but HTTP 1.1 is still very much present
on the Internet. HTTP/2 is described in RFC 7540.
The purpose of HTTP is to support the transfer of HTML documents. HTTP is an application-
level protocol. The HTTP client and server applications use the reliable TCP transport protocol to
establish a connection.
Understanding HTTP 339
HTTP does the following:
Establishes a connection between the browser (the client) and the server
Negotiates settings and establishes parameters for the session
Provides for the orderly transfer of HTML content
Closes the connection with the server
Although the nature of web communication has become extremely complex, most of that
complexity relates to how the server builds the HTML content and what the browser does with
the content it receives. The actual process of transferring the content through HTML is relatively
uncluttered, although, as you will learn later in this section, HTTP/2 adds some additional
complications to the transfer process in order to improve performance.
When you enter a URL into the browser window, the browser first checks the scheme of the URL
to determine the protocol. (Most web browsers support other protocols in addition to HTTP.) If
the browser determines that the URL refers to a resource on an HTTP site, it extracts the DNS
name from the URL and initiates the name resolution process. The client computer sends the
DNS lookup request to a name server and receives the server’s IP address. The browser then uses
the server’s IP address to initiate a TCP connection with the server. (See Hour 6, “The Transport
Layer,” for more on TCP.)
After the TCP connection is established, the browser uses the HTTP GET command to request the
web page from the server. The GET command contains the URL of the resource the browser is
requesting and the version of HTTP the browser wants to use for the transaction. In most cases,
the browser can send the relative URL with the GET request, rather than the full URL, because the
connection with the server has already been established:
GET /watergate/tapes/transcript HTTP/1.1
Several other optional field:value pairs might follow the GET command, specifying settings
such as the language, browser type, and acceptable file types.
The server response consists of a header followed by the requested document. The format of the
response header is as follows:
HTTP/1.1 status_code reason-phrase
field:value
field:value...
The status code is a three-digit number describing the status of the request. The reason-phrase
is a brief description of the status. Some common status codes are shown in Table 17.3. As you
can see, the leftmost digit of the code identifies a general category. The 100s are informational,
the 200s denote success, the 300s specify redirection, the 400s show a client error, and the 500s
340 HOUR 17: HTTP, HTML, and the World Wide Web
specify a server error. You might be familiar with the famous 404 code, which often appears in
response to a missing page or a mistyped URL. Like the client request, the server response can
also include a number of optional field:value pairs. Some of the header fields are shown in
Table 17.4. Any field that is not understood by the browser is ignored.
TABLE 17.3 Some Common HTTP Status Codes
Code Reason-Phrase Description
100 Continue Request is in process.
200 OK Request is successful.
202 Accepted Request accepted for processing but not finished.
301 Moving Permanently Resource has a new address.
302 Moving Temporarily Resource has a new temporary address.
400 Bad Request Server doesn’t recognize the request.
401 Unauthorized Authorization failed.
404 Not Found Resource requested doesn’t exist.
406 Not Acceptable Content will not be acceptable to browser.
500 Internal Server Error Server encountered error.
503 Service Unavailable Server is overloaded or not working.
TABLE 17.4 Examples of HTTP Header Fields
Field Value Must Be Description
Content-Length Integer Size of the content object in octets
Content-Encoding x-compress x-gzip Value representing the type of encoding
associated with the message
Date Standard date format defined Date in Greenwich mean time when
in RFC 1036 the object was created
Last-modified date Standard date format defined Date in Greenwich mean time when
in RFC 1036 the object was last modified
Content-Language Language code per ISO 3316 The language in which the object was
written
As you can see from Table 17.4, some of the header fields are purely informational. Other header
fields might contain information used to parse and process the incoming HTML document.
The Content-Length field is particularly important. In the earlier HTTP version 1.0, each
request/response cycle required a new TCP connection. The client opened a connection and
initiated a request. The server fulfilled the request and then closed the connection. In that
Scripting 341
situation, the client knew when the server had stopped sending data because the server closed
the TCP connection. Unfortunately, this process required the increased overhead necessary for
continually opening and closing connections. HTTP 1.1 allows the client and server to maintain
the connection for longer than a single transmission. In that case, the client needs some way of
knowing when a single response is finished. The Content-Length field specifies the length of the
HTML object associated with the response. If the server doesn’t know the length of the object it is
sending—a situation increasingly common with the appearance of dynamic HTML—the server
sends the header field Connection:close to notify the browser that the server will specify the
end of the data by closing the connection. HTTP also supports a negotiation phase in which the
server and browser agree to common settings for certain format and preference options.
As mentioned previously, HTTP/2 was developed for performance reasons and does not change
HTTP 1.1 syntax or methods. Some of the benefits of HTTP/2 are:
Parallel processing within a connection: HTTP 1.1 let the browser open multiple simultaneous
connections, but each connection could only respond to one request at a time.
HTTP/2 allows the server to service multiple requests at once through the same connection.
Header compression: Header information transferred at the start of a new connection
can slow down the response time significantly. Compression reduces the total size of the
header data.
Server “push” responses: The server can provide content for the client before waiting for a
request. As websites grow more complex, one page might contain several different objects,
such as graphics files. Rather than waiting on a request for each item, the server can anticipate
the request for these additional objects and push the content directly.
HTTP/2 does not require encryption but strongly supports it and provides a standard profile for TLS
encryption. (You’ll learn more about encryption in Hour 19, “Encryption, Tracking, and Privacy.”)
Scripting
The web page has evolved tremendously in the last 20 years, and most professional web pages
today are quite unlike the ideal described earlier in this hour of a simple text file embedded with
static HTML tags.
Modern web pages are often a complex pastiche of objects, scripts, and machine-generated code
produced on the fly in response to user input and back-end data. The versatile HTML makes it
easy to insert data or additional instructions into the page as it is delivered, or to add code that
will execute after the page arrives.
Web browsers have become very adept at interpreting and manipulating this incoming code. As
you learn in the next hour, special tools called content management systems run on the web server,
obscuring the details of HTML code generation to provide a simple interface for the web developer.
342 HOUR 17: HTTP, HTML, and the World Wide Web
Two fundamental techniques for autogenerating web code are server-side scripting and client-
side scripting.
As you learn later in this hour, the collection of plug-in and add-on applications running on the
client system add another dimension to the activities that can be triggered from a web page. For
more about advanced web techniques see Hour 18, “Web Services.”
Most of these technologies are actually programming topics. The end user doesn’t really have
to know whether the image or table embedded in a web page comes from a static callout or a
script. However, a brief introduction to some of the concepts will provide some insights on how
HTML is used on today’s Internet.
Server-Side Scripting
Server-side scripting lets the server accept input from the client and process that input behind the
scenes. A common server-side scripting scenario is shown in Figure 17.5. The process is as follows:
1. The user browses to a page that includes a form for purchasing a product or entering visitor
information.
2. The server generates the form based on user choices and transmits the form to the browser.
3. The user enters the necessary information into the form, and the browser transmits the
form back to the server. (Note that the HTML form feature reverses the usual process. The
browser sends content to the server at the server’s request.)
4. The server accepts the data from the browser and uses a programming interface to pass
the data to programs that process the user information. If the user is purchasing a product,
these behind-the-scenes programs may check credit card information or send a shipment
order to the mail room. If the user is adding his name to a mailing list or joining a restricted
online site, a program may add the user information to a database.
Completed
Form
Form
Web
Server
Data
Server Request
Script
Scripting
Interface
FIGURE 17.5
A server-side scripting scenario.
Scripting 343
Several programming languages and environments have evolved to help developers build
server-based web applications. One method for interfacing a program or script with a web page
is through the Common Gateway Interface (CGI). CGI was developed to accept form-based
input from a web user, process that input, and then generate output in the form of HTML. CGI
scripts are commonly written in the Perl language, but CGI is compatible with other languages,
including C.
PHP is also becoming increasingly popular as a language for web development. A simple PHP
script is often embedded within an HTML tag:
Or defined using the
A web server that supports PHP parses and executes the code between the brackets, inserting the
output of the PHP command set in place of the tag as the page is delivered to the client.
Microsoft’s Active Server Page (ASP) and the later ASP.NET technologies are also popular server-
side web techniques. The concept of a web interface to a custom, server-side application has led
to a whole paradigm for programming known as the web services environment. Many of the
leading hardware and software vendors, including IBM, Microsoft, and others, have developed
sophisticated infrastructures to support web service programming.
Client-Side Scripting
Another way to integrate scripts with the web environment is on the client side (that is, on the
local client computer system that is running the web browser application). Whereas a server-side
script is executed on the server and the output of the script is embedded in the page, a client-side
solution transfers the embedded script along with the rest of the HTML code and text, and the
script is executed by the browser.
JavaScript and VBScript are two common client-side scripting technologies. The script file is often
referenced through the HTML:
The tag can reference the actual instructions, or it can refer to an external file containing the
code. In either case, this technique only works if the client computer includes support for the
scripting language referenced in the code.
For certain types of applications, client-side scripting is a more efficient alternative. An
interpreter executing the script on the client has a much more detailed view of the local
environment. Also, confining interactive elements to the client reduces network traffic and
improves performance.
344 HOUR 17: HTTP, HTML, and the World Wide Web
AJAX (which is sometimes billed as an acronym for Asynchronous JavaScript and XML) is a collection
of technologies that use client-side scripting to provide for seamless update of web content
without a full refresh of the web page. Other common client-side techniques offer interactive
options for the user, invoke animations or other multimedia effects, or respond to information
on the state of the client system.
Client-side scripting is extremely common, but as you can imagine, it poses some security challenges.
What intruder would not love the chance to execute code on the client system? Most
systems now take measures to restrict the privileges of code executing on the browser, and, as
you will learn in the next section, users have some freedom to limit the use of browser-launched
scripts. As is often the case with network-related software, the best precaution is often to keep
your system up to date and install security patches whenever they are available.
Web Browsers
As you probably already know, the whole business of the World Wide Web depends on a very
special and versatile application known as a web browser. In the client-server model discussed
earlier in this book, the web browser is the client. Early, simple browsers originally just rendered
the early, simple, static HTML files discussed in earlier hours. When web data arrived from
the server, browsers interpreted the tags, formatting the text with the specified fonts, links,
and photos.
As web data became more complex, the web browser evolved with it, and as the web became
the center of Internet commercial activity, the browser became a major source of competition
and corporate leverage among leading software companies in an era that is now known as
the “browser wars.”
Why declare a war over browsers, which have no market value in their own right and are
mostly given away as free software (either bundled with the OS or downloadable at no charge)?
Big companies like Microsoft and Netscape (and later Google) knew that by controlling the
browser they could control a whole range of technologies surrounding Internet activity, not just
web servers but also the lucrative and influential business of providing development tools and
application programming interfaces (APIs) that interact with the operating system.
At one point, Microsoft even said it had embedded its browser Internet Explorer into the
operating system itself in a way that could not be separated (an argument that was later rejected
by the courts). Microsoft wanted to extend its control of the OS market to control of the browser
market so that they could control the development environment and build pathways back into
the operating system to ensure the continued dominance of their OS projects.
From the user’s perspective, the browser is the focal point for everything that happens on
today’s Internet. The purpose of the HTML and HTTP standards is to ensure that any standard-
compliant browser can communicate with any standard-compliant server. However,
the big vendors have a tendency to use the standard as a minimum and to add their own
Web Browsers 345
enhancements, which has the same effect of locking in the user who has invested in building
custom tools for a proprietary development environment. Microsoft was forced through legal
action to open its APIs, which has largely addressed this issue. To fully participate in today’s
Internet, a browser must support the client-side scripting described earlier in this hour through
support for JavaScript or some other scripting technology. Depending on the browser and
system, this support might take the form of a browser plug-in or add-on or it might be implemented
through the operating system. A full-featured browser also must provide support for
digital signatures and certificates to allow the user to engage in secure transactions and communication
through Secure Sockets Layer/Transport Layer Security (SSL/TLS) encryption with
Hypertext Transfer Protocol Secure (HTTPS).
Modern browsers can launch other applications if necessary to open files or execute procedures.
Using other applications for these extended capabilities keeps the browser itself from getting too
big and cumbersome, and it allows application developers to concentrate on their own area of
specialty. These external applications are typically referred to as add-ons, plug-ins, or helper
applications.
Browsers are often smart enough to recognize a missing plug-in and ask whether you want to
install it if it is needed to open a file or start a video. Most browsers also provide a means for
manually adding, removing, and managing the plug-ins included within the configuration
(Figure 17.6).
FIGURE 17.6
Managing add-ons in Microsoft’s classic Internet Explorer browser.
Classic examples of browser plug-ins are Adobe tools such as the Acrobat reader and the Flash
player. When a browser encounters a reference to a link or reference to a PDF file, it calls the
appropriate Acrobat plug-in to open the file and displays the contents in a browser window.
346 HOUR 17: HTTP, HTML, and the World Wide Web
Some plug-ins provide other forms of extensions and enhanced capabilities. For instance, Firefox
provides an extensive collection of add-ons for alerts, social networking, and privacy (see Figure 17.7).
FIGURE 17.7
Firefox offers add-ons for social networking, privacy, alerts, and other uses.
The recent HTML5 standard, described later in this hour, has reduced the importance of certain
plug-ins such as Flash by offering direct support for video codecs within the browser.
The other critical component of browser configuration, in addition to extending what the browser
can do, is limiting what the browser can do. With new threats appearing on the Internet every day,
and old threats continuing to succeed despite the continuing efforts of the authorities, the security
configuration becomes an important aspect of the browser environment. Most browsers provide
a means for defining the security settings for web activities, in essence to “turn on” or “turn off”
certain capabilities depending on level of trust for the source and the level of privacy and security
required for the user environment. Internet Explorer provides a sliding scale of Internet security
levels, offering varying levels of control over scripts, ActiveX controls, and other elements that
might appear on a website (see Figure 17.8). The new Microsoft Edge browser appears to have a
more limited range of onboard security controls at this writing; however, supporting tools such as
Windows Defender and Group Policy replace some of this functionality. In the simplified world of
Mac OS, the Safari browser offers a means for enabling and disabling Java and JavaScript, blocking
pop-ups, and configuring other aspects of the security environment. Choose Preferences in the
Safari menu and select the Security option to configure Safari security settings (see Figure 17.9).
Firefox, Chrome, Opera, and other browsers offer similar features. Many browsers also let the user
predefine a list of trusted sites that are allowed to operate with fewer security restrictions.
Web Browsers 347
FIGURE 17.8
Most browsers have a way to fine-tune the security level. A more secure browser is safer, but a high security
setting can block legitimate web activity.
FIGURE 17.9
Safari’s simpler interface lets you enable JavaScript and define a cookie policy.
348 HOUR 17: HTTP, HTML, and the World Wide Web
The Semantic Web
An interesting area of research that truly might cause another Internet revolution is an ambitious
concept known as the Semantic Web. The Semantic Web, which has the full support and
advocacy of World Wide Web creator Tim Berners-Lee, is designed as a universal technique for
linking web data with real semantic meaning as a human understands it. In other words, the
goal is to somehow encode the meaning of web information in a way that is easily accessed and
processed by a computer.
To understand the purpose of the Semantic Web, one must start with some sense of how little
knowledge is truly present on a web page. For instance, consider the following lines of text,
which might be present at a typical website:
A Streetcar Named Desire
Lawrence Community Theater
Saturday, October 12, 2016
7:30 PM
A human who looks at this text knows immediately that it is a notice of an event that will occur
at the Lawrence Community Theater at 7:30 on October 12. Many readers will also recognize the
name A Streetcar Named Desire as a famous play, but those who don’t recognize the title will still
infer that the event is a play or movie because it is associated with a theater.
A computer, on the other hand, will just read those lines as alphanumeric text. The computer
doesn’t really know anything about the meaning of the text. It doesn’t know what a theater is,
and it doesn’t know that the third line is a date unless you specifically tell it so. For that matter,
a search engine might even call up this page for a user who is searching for a streetcar schedule.
The tools of the Semantic Web will one day help the web developer encode semantic information
so that an automated process will know that this page is about a play and not about a ticket for
a tram ride. Because this semantic information will be encoded along with the page itself, the
creator of the site won’t need any advance knowledge of how the reader will use the information.
Anyone can come along later and create a tool that searches for information on plays, and
the tool will find the notice of this play. Different websites can present the information differently,
with no standard format or style, and the play finder application will still find the plays—as
long as the semantic information defines the meaning of the text.
Resource Description Framework
Semantic Web techniques are still experimental, although several strategies have appeared in
the publications of the World Wide Web Consortium (W3C). One semantic tool that has received
considerable attention in the web community is called the Resource Description Framework
(RDF). RDF is a framework for expressing relationships that give an indication of meaning.
The Semantic Web 349
The fundamental unit of RDF is a statement consisting of three parts, which is called a triple in
RDF parlance. A triple is structured like a basic sentence, which has a subject, a predicate, and
an object.
For instance, in the sentence “The play has the title A Streetcar Named Desire,” the subject is
“The play,” the object is “A Streetcar Named Desire,” and the predicate is “has the title.”
RDF triples can take on several forms, but the idea is that each element is expressed as a URI,
and the URIs are concatenated in a colon-separated list. The Dublin Core Metadata Initiative
maintains a database of standard predicates referenced in RDF triples. For instance, the
following callout refers to the predicate “has the title”:
RDF and other Semantic Web techniques might someday lead to smarter search tools.
Microformats
RDFs are an extremely powerful tool for adding meaning to text; however, a fierce debate is
going on within the Internet community over whether the RDF concept is too complex and too
much effort to fit in with the methods of ordinary web developers. An alternative approach,
which is less ambitious but, most likely, more manageable and accessible for working web professionals,
is microformats.
Unlike RDFs, microformats do not attempt to represent complete sentence structures and
syntactic constructs. The goal of a microformat is simply to flag a section of text to associate it
with a predefined meaning, so that a browser or other web application that visits the site will
get a clue about the purpose of the text.
Microformats are not part of any official Internet specification, although the practice relies on
the existing tags and concepts underpinning HTML. The microformat community has arisen
independently, partly under the sponsorship of the nonprofit CommerceNet, which is interested
in promoting opportunities for Internet commerce.
A microformat is a specific vocabulary of name/value pairs designed to serve a specific purpose.
Microformat vocabularies have been developed for uses such as the following:
calendars (hCalendar)
business cards (hCard)
recipes (hRecipe)
copyright information (rel-license}
When a block of text is associated with a microformat (such as a resume, which can be identified
with the hResume microformat) the surrounding text elements can then be associated with
the various elements that make up a resume (such as experience, skill, affiliations, publications).
350 HOUR 17: HTTP, HTML, and the World Wide Web
Perhaps the most common microformat in use today is the hCard microformat, which is used
for business cards. hCard is a later incarnation of the vCard format, a MIME type originally
described in RFC 2426 and updated in RFC 6351 and other RFCs.
A simple example of HTML data tagged with the hCard microformat is as follows:
Of course, other settings are also available for specifying a street address and email address, as
well as to specify whether the telephone number is a home, work, cell, or fax number. If text on
a web page is tagged with these hCard settings, a browser that arrives at the site immediately
knows how to treat the information. Microformat-aware browsers automatically format the data
as a business card.
See the microformats.org website for more on the microformats movement, including specifications
for specific microformats and even some tools that automatically generate microformat
data. As you learn later in this hour, a similar concept known as microdata is now in the official
Internet lexicon with the arrival of HTML5.
XHTML
Many tools of the new Web, as well as many other websites on today’s Internet, rely on another
development that is quite technical for the purposes of this hour but is nevertheless worth mentioning.
The XHTML standard is an effort to bridge between old-fashioned HTML and the realities of the
XML-based web environment. (See Hour 18, “Web Services,” for more about XML.) XHTML is essentially
a formulation of HTML functionality that conforms to XML syntax. The XHTML format provides
all the expressive power of HTML within the machine-readable confines of an XML schema.
Although the concepts of XHTML are similar to HTML, XHTML is much more finicky about
sloppy or nonstandard coding practice. Certain declarations occur differently, or more formally,
and the nesting of tags must be more structured and precise. The goal of expressing HTML as an
XML schema is to provide flexibility for developers building scripts and other programs that generate
and interpret the code. XHTML also lends itself more readily to dynamic interpretation or
modification by the receiving entity. For instance, the small screen of a mobile device might not
be able to display a standard HTML page as specified, but a client-side application receiving the
page as XHTML could readily modify the text for the smaller screen.
Many believe the emergence of HTML5 (described in the next section) reduces the importance
of XHTML.
HTML5 351
HTML5
One of the most important changes taking place on the Internet today is the adoption of a new
HTML standard. HTML5 has been in discussion for several years, and it is finally making its way
to the practical side of the everyday Internet.
One who looks at the HTML5 feature list will see that many of its traits reflect the new role of
HTML as a tool for building the mobile revolution. The HTML5 standard includes many features
designed to support web browsing from mobile devices. However, other features simply reflect a
further evolution of the web environment, and incorporate functionality once provided by add-
ons and extensions directly into the HTML.
New important new features of HTML5 include the following:
Local storage and offline application support
Drawing
Embedded audio and video
Geolocation
Semantic elements
The following sections describe these important new developments in HTML5. The HTML5 standard
also includes other improvements, such as a drag-and-drop API and improved support for
forms. In many ways, HTML5 marks the further evolution of HTML to something more like a
development environment for web applications. Developers have long used HTML and its surrounding
technologies to build web-based client/server applications, but much of the functionality
required additional components and third-party extensions. HTML5 builds more of the functionality
directly into the HTML. In the rapidly evolving world of mobile device programming,
developers have begun to use HTML5 to build cross-platform mobile applications that will run
on Android, iPhone, and other platforms with only minor modifications.
Of course, the adoption of the HTML5 standard by a standards committee doesn’t guarantee its
adoption by the larger Internet community. Several popular browsers already provide HTML5
support, and web servers are also getting connected with the newest HTML. However, until web
developers start building ordinary web pages that incorporate HTML5 elements, you won’t see
the benefits of HTML5 in your everyday web surfing experience.
HTML5 Local Storage and Offline Application Support
A cookie is a small bundle of persistent data stored on the remote client system by the web
server. Cookies have been part of the web scene for years, and you’ll find configuration options
in most web browsers that let you manage how cookies are stored and saved. Web servers
352 HOUR 17: HTTP, HTML, and the World Wide Web
use cookies to restore a previous application state or save information on the user’s previous
activities. Cookies are a very useful tool that most web developers (and most web users) are
familiar with; however, they have some limitations. The cookie’s storage size of 4 KB is barely
enough room for a few basic bits of data about the user and session history, but today’s web
programmers see the need for much more local storage.
HTML5 comes with a local storage feature that greatly expands and enhances how web browsers
can store and retrieve information on the local system. HTML5 storage (which is also called
web storage or DOM storage) lets the browser store values for settings defined within the web
application. This local storage provides a number of benefits. For instance, a script executing on
the client side can stash temporary results in the storage area, thus improving performance by
reducing the need for communication with the server over the network. The storage space can
also save a more complete view of the current session state, so that a web-based game or other
interactive application can be restored (and, in some cases, keep operating temporarily) if the
server crashes or the connection is lost.
The local storage capabilities of HTML5 lead to another important improvement: offline
application support. A web browser that supports the offline application feature can keep going
when the network is disconnected.
As shown in Figure 17.10, a web application that supports offline processing includes a cache
manifest, which names the files and other resources required for operating offline. When the
browser first connects to the website, the files provided in the cache manifest are downloaded
to the client system.
Cache
Manifest
Web Client Web Server
FIGURE 17.10
The cache manifest lists the resources necessary for offline processing. The client downloads the required
files and can therefore operate even when the connection is lost.
HTML5 353
When the network is inaccessible, the web application still operates through the offline versions
of the files listed in the cache manifest. This might not sound so impressive at a glance. (Of
course, every application works if all the files it accesses are present on the system.) The problem
is that the files downloaded to the client will soon become out-of-date. However, the interesting
part of the HTML5 offline application feature is that the browser system automatically updates
the files on the local system when the connection is restored and saves all offline changes back
to the server. Thus, the files referenced in the cache manifest stand a better chance of being
current at the time the system goes offline, and the client seamlessly synchronizes its changes
through the restored connection without additional effort by the user.
HTML5’s offline storage feature could also have some disadvantages. As you will learn in Hour 19,
cookies provide a means for advertisers and content providers to track user habits and activities.
By expanding the possibilities for a vendor to store cookie-like information, offline storage could
potentially lead to additional privacy concerns.
HTML5 Drawing
Internet users are accustomed to seeing image files with photographs and diagrams embedded in
web pages. This technique of embedding graphic images greatly enhances the power and beauty
of the Web. However, web designers and developers want more from their pages, including the
ability to draw images programmatically or create small animations that will unfold while the
user is watching. Previous HTML versions add this functionality through third-party add-on
tools, such as Adobe Flash.
HTML5 rolls out its own drawing capabilities through a pair of important new elements: the
, , , Marks the beginning and end of a heading. Each
and heading tag represents a different heading level.
is the highest level.
Marks the beginning and end of a section
of bold text.
Marks the beginning and end of a section
of underlined text.
Marks the beginning and end of a section
of italicized text.
Marks the beginning and end of a section with
special font characteristics. Contemporary practices
avoid this tag and express font information, instead,
within Cascading Style Sheets. The tag is
not supported in HTML5. See Table 17.2 for some of
the available font attributes.
Defines an anchor—typically used to mark a link. The
link destination URL appears inside the first tag
as a value for the href attribute (as described later in
this section).
![]()
Specifies an image file that should appear in the text.
The file URL appears in the tag as a value for the SRC
attribute. (You’ll learn more about attributes later in
this section.)
334 HOUR 17: HTTP, HTML, and the World Wide Web
Of course, there is much more to HTML than a single table can convey. Many tags apply to a
block of text. If so, the tag appears at the beginning and the end of the block. The tag at the end
of the block includes the slash character (/) to signify that it is an end tag. In other words, the
callout for an H1 heading would be tagged as follows:
Dewey Defeats Truman
An HTML document is supposed to begin with a declaration. The !DOCTYPE
defines the version of HTML used for the document. For HTML 4.0, the !DOCTYPE command
is as follows:
(Web pages that use special browser extensions might specify a different document type.)
Most browsers don’t require the !DOCTYPE statement, and many HTML tutorials don’t even discuss
the !DOCTYPE.
Following the !DOCTYPE statement is the tag. The rest of the document is enclosed
between the tag and a corresponding tag at the end of the file. Within the
beginning and ending tags, the document is divided into the following two sections:
The head (enclosed between the and tags) contains information about
the document. The information in the head does not appear on the web page, although
the tag specifies a title that will appear in the title bar of the browser window.
The <title> is a required element. Other elements of the <head> section are optional,
such as the <style> tag for information on document styles.
The body (enclosed between the <body> and </body> tags) is the text that actually
appears on the web page and includes any HTML tags related to that text.
A simple HTML document follows:
<!DOCTYPE HTML PUBLIC "-//W3C/DTD HTML 4.0//EN">
<html>
<head>
<title> Ooh This is Easy
Easy!
If you save the preceding HTML to a text file and then open the file with a web browser, Easy!
appears in the browser window. (Depending on your browser and operating system, you might
have to save this file with an .htm or .html extension or open it as an HTML file.) The title bar
includes the title Ooh This is Easy (see Figure 17.3).
Understanding HTML 335
FIGURE 17.3
A very easy web page example.
You can spice up the page with additional text and formatting in the body section. The following
example adds the and tags for headings, the
tag for a paragraph, the tag
for bold, the tag for italics, and the tag for font information. Note that the
tag includes an attribute. Attributes are parameters enclosed within the tag that provide additional
information. See Table 17.2 for other font attributes. As you will learn later in this hour,
professional webmasters use Cascading Style Sheets to manage fonts, but the tag, which
is supported through HTML4 but is not found in HTML5, is an easy option for making your first
HTML experiments.
Ooh This is Easy
The Easy and Hard of HTML
Webster's Dictionary defines HTML as "a small snail found originally
in the Canary Islands and ranging now to the Archipelago of Parakeets."
I borrow from this theme in my consideration of HTML as a language that is both
easy and hard.
HTML is Easy
336 HOUR 17: HTTP, HTML, and the World Wide Web
HTML is easy to learn and use because everyone reacts to it energetically.
You can walk into a bar and start speaking HTML, and the man beside you will
happily tell you his many accomplishments.
HTML is Hard
HTML is hard because the options are bewildering. You never know when to use
small text and when to use big text.
TABLE 17.2 HTML Tag Attributes
size Relative font size setting. Values vary from 1 to 7: .
lang Language code denoting the language in which the text is written.
face Typeface setting: .
color Color of the text: .
The preceding example appears in the browser as shown in Figure 17.4.
FIGURE 17.4
Expanding the easy example.
As you learned earlier in this hour, the hypertext link is an important element of web design.
A link is a reference to another document or another part of the current document. If the user clicks
the text of the link, the browser immediately opens the document referenced in the link. The effect
is that the user appears to lilt through an endless garden of colorful and informative content.
Cascading Style Sheets 337
BY THE WAY
What is a Browser?
As you lilt through this colorful garden, pause occasionally to consider that the term browser
originally referred to a giraffe or a large dinosaur eating leaves out of trees.
A link appears in the HTML file as a tag. The simplest form of a link uses the tag with the
URL of the link destination given as a value for the HREF attribute. For instance, in the preceding
example, if you would like the words “Archipelago of Parakeets” to appear as hypertext with a
link to a website that tells about the archipelago, enclose the words within tags as follows:
ranging now to the Archipelago of
Parakeets. I borrow from this theme
The versatile HTML format includes many additional options. You can place a hotspot link
inside a picture. You can create your own style sheets with special tags for preformatted paragraph
styles. You can structure the web page with tables, columns, forms, and frames. Or you
can add radio buttons, check boxes, and pull-down menus. In the early days of HTML, designers
coded all the HTML directly into their documents using text editors (as described in the preceding
examples). Professional web designers now work with special web development applications,
such as Adobe Dreamweaver, that hide the details of HTML and let the designer view the page
as it will appear to the user. New tools such as wikis and content management systems (CMSs)
provide additional options for effortless web design.
Static, preformed HTML documents like those described in this section are still widely used, but
many websites today use dynamic HTML techniques to generate the web content at the time of
the request.
BY THE WAY
Capitalization
With classic HTML tags, capitalization is not significant; however, later standards such as Extensible
Markup Language (XML) and XHTML pay more attention to capitalization. XML is case sensitive, and
XHTML requires lowercase element and attribute names.
Cascading Style Sheets
Although it is possible to encode all formatting instructions into an HTML document (fonts, font
sizes, line types, etc.), in practice, repeating the same tags over and over for the same few style
elements is cumbersome. Perhaps more importantly, on-the-fly modifications can lead to inconsistency
and an unpolished, overly complicated design.
338 HOUR 17: HTTP, HTML, and the World Wide Web
A better approach is to define standard style elements for the document and put them in one
place, then reference those elements in the text. Researchers at the World Wide Web consortium
developed Cascading Style Sheets (CSS) as a way to corral style information in a single document.
The goal is to make HTML more like a modern word processor or desktop publishing tool,
which lets you pick from a list of predefined character or paragraph styles. The style defines a set
of parameters, such as the font size, color, spacing, padding, and margins.
Using a CSS separates the document contents from the presentation information. This approach
makes the HTML much easier to read, and it imposes a stylistic consistency on the document,
which is considered good design practice.
For example, a heading style might be defined as follows in the CSS document:
h1 {
Color: black;
Font-family: Arial, sans-serif;
Margin: 0 4px 0 0;
}
As you can see, the definition consists of colon-separated attributes and values. The items in the
list are separated with semicolons, and the whole style block is enclosed in {}.
The actual callout for the heading in the HTML document then just has to refer to the style:
This Is the Heading
And the attribute values for the style are all applied to the heading.
A Cascading Style Sheets file (with a .css extension) is a common sight on websites today. The
HTML file can reference the CSS file as follows:
Understanding HTTP
As you learned earlier, web servers and browsers communicate using the Hypertext Transfer
Protocol (HTTP). HTTP 1.1, which arrived in 1997 with RFC 2068 and is currently defined in RFCs
7230-7235, was the dominant version of HTTP for many years. A new version, known as HTTP/2,
appeared in 2015. HTTP/2, which is based on Google’s SPDY protocol, primarily provides performance
enhancements and is not intended as a replacement for HTTP’s semantics or status codes.
Many websites and browsers now offer support for HTTP/2, but HTTP 1.1 is still very much present
on the Internet. HTTP/2 is described in RFC 7540.
The purpose of HTTP is to support the transfer of HTML documents. HTTP is an application-
level protocol. The HTTP client and server applications use the reliable TCP transport protocol to
establish a connection.
Understanding HTTP 339
HTTP does the following:
Establishes a connection between the browser (the client) and the server
Negotiates settings and establishes parameters for the session
Provides for the orderly transfer of HTML content
Closes the connection with the server
Although the nature of web communication has become extremely complex, most of that
complexity relates to how the server builds the HTML content and what the browser does with
the content it receives. The actual process of transferring the content through HTML is relatively
uncluttered, although, as you will learn later in this section, HTTP/2 adds some additional
complications to the transfer process in order to improve performance.
When you enter a URL into the browser window, the browser first checks the scheme of the URL
to determine the protocol. (Most web browsers support other protocols in addition to HTTP.) If
the browser determines that the URL refers to a resource on an HTTP site, it extracts the DNS
name from the URL and initiates the name resolution process. The client computer sends the
DNS lookup request to a name server and receives the server’s IP address. The browser then uses
the server’s IP address to initiate a TCP connection with the server. (See Hour 6, “The Transport
Layer,” for more on TCP.)
After the TCP connection is established, the browser uses the HTTP GET command to request the
web page from the server. The GET command contains the URL of the resource the browser is
requesting and the version of HTTP the browser wants to use for the transaction. In most cases,
the browser can send the relative URL with the GET request, rather than the full URL, because the
connection with the server has already been established:
GET /watergate/tapes/transcript HTTP/1.1
Several other optional field:value pairs might follow the GET command, specifying settings
such as the language, browser type, and acceptable file types.
The server response consists of a header followed by the requested document. The format of the
response header is as follows:
HTTP/1.1 status_code reason-phrase
field:value
field:value...
The status code is a three-digit number describing the status of the request. The reason-phrase
is a brief description of the status. Some common status codes are shown in Table 17.3. As you
can see, the leftmost digit of the code identifies a general category. The 100s are informational,
the 200s denote success, the 300s specify redirection, the 400s show a client error, and the 500s
340 HOUR 17: HTTP, HTML, and the World Wide Web
specify a server error. You might be familiar with the famous 404 code, which often appears in
response to a missing page or a mistyped URL. Like the client request, the server response can
also include a number of optional field:value pairs. Some of the header fields are shown in
Table 17.4. Any field that is not understood by the browser is ignored.
TABLE 17.3 Some Common HTTP Status Codes
Code Reason-Phrase Description
100 Continue Request is in process.
200 OK Request is successful.
202 Accepted Request accepted for processing but not finished.
301 Moving Permanently Resource has a new address.
302 Moving Temporarily Resource has a new temporary address.
400 Bad Request Server doesn’t recognize the request.
401 Unauthorized Authorization failed.
404 Not Found Resource requested doesn’t exist.
406 Not Acceptable Content will not be acceptable to browser.
500 Internal Server Error Server encountered error.
503 Service Unavailable Server is overloaded or not working.
TABLE 17.4 Examples of HTTP Header Fields
Field Value Must Be Description
Content-Length Integer Size of the content object in octets
Content-Encoding x-compress x-gzip Value representing the type of encoding
associated with the message
Date Standard date format defined Date in Greenwich mean time when
in RFC 1036 the object was created
Last-modified date Standard date format defined Date in Greenwich mean time when
in RFC 1036 the object was last modified
Content-Language Language code per ISO 3316 The language in which the object was
written
As you can see from Table 17.4, some of the header fields are purely informational. Other header
fields might contain information used to parse and process the incoming HTML document.
The Content-Length field is particularly important. In the earlier HTTP version 1.0, each
request/response cycle required a new TCP connection. The client opened a connection and
initiated a request. The server fulfilled the request and then closed the connection. In that
Scripting 341
situation, the client knew when the server had stopped sending data because the server closed
the TCP connection. Unfortunately, this process required the increased overhead necessary for
continually opening and closing connections. HTTP 1.1 allows the client and server to maintain
the connection for longer than a single transmission. In that case, the client needs some way of
knowing when a single response is finished. The Content-Length field specifies the length of the
HTML object associated with the response. If the server doesn’t know the length of the object it is
sending—a situation increasingly common with the appearance of dynamic HTML—the server
sends the header field Connection:close to notify the browser that the server will specify the
end of the data by closing the connection. HTTP also supports a negotiation phase in which the
server and browser agree to common settings for certain format and preference options.
As mentioned previously, HTTP/2 was developed for performance reasons and does not change
HTTP 1.1 syntax or methods. Some of the benefits of HTTP/2 are:
Parallel processing within a connection: HTTP 1.1 let the browser open multiple simultaneous
connections, but each connection could only respond to one request at a time.
HTTP/2 allows the server to service multiple requests at once through the same connection.
Header compression: Header information transferred at the start of a new connection
can slow down the response time significantly. Compression reduces the total size of the
header data.
Server “push” responses: The server can provide content for the client before waiting for a
request. As websites grow more complex, one page might contain several different objects,
such as graphics files. Rather than waiting on a request for each item, the server can anticipate
the request for these additional objects and push the content directly.
HTTP/2 does not require encryption but strongly supports it and provides a standard profile for TLS
encryption. (You’ll learn more about encryption in Hour 19, “Encryption, Tracking, and Privacy.”)
Scripting
The web page has evolved tremendously in the last 20 years, and most professional web pages
today are quite unlike the ideal described earlier in this hour of a simple text file embedded with
static HTML tags.
Modern web pages are often a complex pastiche of objects, scripts, and machine-generated code
produced on the fly in response to user input and back-end data. The versatile HTML makes it
easy to insert data or additional instructions into the page as it is delivered, or to add code that
will execute after the page arrives.
Web browsers have become very adept at interpreting and manipulating this incoming code. As
you learn in the next hour, special tools called content management systems run on the web server,
obscuring the details of HTML code generation to provide a simple interface for the web developer.
342 HOUR 17: HTTP, HTML, and the World Wide Web
Two fundamental techniques for autogenerating web code are server-side scripting and client-
side scripting.
As you learn later in this hour, the collection of plug-in and add-on applications running on the
client system add another dimension to the activities that can be triggered from a web page. For
more about advanced web techniques see Hour 18, “Web Services.”
Most of these technologies are actually programming topics. The end user doesn’t really have
to know whether the image or table embedded in a web page comes from a static callout or a
script. However, a brief introduction to some of the concepts will provide some insights on how
HTML is used on today’s Internet.
Server-Side Scripting
Server-side scripting lets the server accept input from the client and process that input behind the
scenes. A common server-side scripting scenario is shown in Figure 17.5. The process is as follows:
1. The user browses to a page that includes a form for purchasing a product or entering visitor
information.
2. The server generates the form based on user choices and transmits the form to the browser.
3. The user enters the necessary information into the form, and the browser transmits the
form back to the server. (Note that the HTML form feature reverses the usual process. The
browser sends content to the server at the server’s request.)
4. The server accepts the data from the browser and uses a programming interface to pass
the data to programs that process the user information. If the user is purchasing a product,
these behind-the-scenes programs may check credit card information or send a shipment
order to the mail room. If the user is adding his name to a mailing list or joining a restricted
online site, a program may add the user information to a database.
Completed
Form
Form
Web
Server
Data
Server Request
Script
Scripting
Interface
FIGURE 17.5
A server-side scripting scenario.
Scripting 343
Several programming languages and environments have evolved to help developers build
server-based web applications. One method for interfacing a program or script with a web page
is through the Common Gateway Interface (CGI). CGI was developed to accept form-based
input from a web user, process that input, and then generate output in the form of HTML. CGI
scripts are commonly written in the Perl language, but CGI is compatible with other languages,
including C.
PHP is also becoming increasingly popular as a language for web development. A simple PHP
script is often embedded within an HTML tag:
Or defined using the
A web server that supports PHP parses and executes the code between the brackets, inserting the
output of the PHP command set in place of the tag as the page is delivered to the client.
Microsoft’s Active Server Page (ASP) and the later ASP.NET technologies are also popular server-
side web techniques. The concept of a web interface to a custom, server-side application has led
to a whole paradigm for programming known as the web services environment. Many of the
leading hardware and software vendors, including IBM, Microsoft, and others, have developed
sophisticated infrastructures to support web service programming.
Client-Side Scripting
Another way to integrate scripts with the web environment is on the client side (that is, on the
local client computer system that is running the web browser application). Whereas a server-side
script is executed on the server and the output of the script is embedded in the page, a client-side
solution transfers the embedded script along with the rest of the HTML code and text, and the
script is executed by the browser.
JavaScript and VBScript are two common client-side scripting technologies. The script file is often
referenced through the HTML:
The tag can reference the actual instructions, or it can refer to an external file containing the
code. In either case, this technique only works if the client computer includes support for the
scripting language referenced in the code.
For certain types of applications, client-side scripting is a more efficient alternative. An
interpreter executing the script on the client has a much more detailed view of the local
environment. Also, confining interactive elements to the client reduces network traffic and
improves performance.
344 HOUR 17: HTTP, HTML, and the World Wide Web
AJAX (which is sometimes billed as an acronym for Asynchronous JavaScript and XML) is a collection
of technologies that use client-side scripting to provide for seamless update of web content
without a full refresh of the web page. Other common client-side techniques offer interactive
options for the user, invoke animations or other multimedia effects, or respond to information
on the state of the client system.
Client-side scripting is extremely common, but as you can imagine, it poses some security challenges.
What intruder would not love the chance to execute code on the client system? Most
systems now take measures to restrict the privileges of code executing on the browser, and, as
you will learn in the next section, users have some freedom to limit the use of browser-launched
scripts. As is often the case with network-related software, the best precaution is often to keep
your system up to date and install security patches whenever they are available.
Web Browsers
As you probably already know, the whole business of the World Wide Web depends on a very
special and versatile application known as a web browser. In the client-server model discussed
earlier in this book, the web browser is the client. Early, simple browsers originally just rendered
the early, simple, static HTML files discussed in earlier hours. When web data arrived from
the server, browsers interpreted the tags, formatting the text with the specified fonts, links,
and photos.
As web data became more complex, the web browser evolved with it, and as the web became
the center of Internet commercial activity, the browser became a major source of competition
and corporate leverage among leading software companies in an era that is now known as
the “browser wars.”
Why declare a war over browsers, which have no market value in their own right and are
mostly given away as free software (either bundled with the OS or downloadable at no charge)?
Big companies like Microsoft and Netscape (and later Google) knew that by controlling the
browser they could control a whole range of technologies surrounding Internet activity, not just
web servers but also the lucrative and influential business of providing development tools and
application programming interfaces (APIs) that interact with the operating system.
At one point, Microsoft even said it had embedded its browser Internet Explorer into the
operating system itself in a way that could not be separated (an argument that was later rejected
by the courts). Microsoft wanted to extend its control of the OS market to control of the browser
market so that they could control the development environment and build pathways back into
the operating system to ensure the continued dominance of their OS projects.
From the user’s perspective, the browser is the focal point for everything that happens on
today’s Internet. The purpose of the HTML and HTTP standards is to ensure that any standard-
compliant browser can communicate with any standard-compliant server. However,
the big vendors have a tendency to use the standard as a minimum and to add their own
Web Browsers 345
enhancements, which has the same effect of locking in the user who has invested in building
custom tools for a proprietary development environment. Microsoft was forced through legal
action to open its APIs, which has largely addressed this issue. To fully participate in today’s
Internet, a browser must support the client-side scripting described earlier in this hour through
support for JavaScript or some other scripting technology. Depending on the browser and
system, this support might take the form of a browser plug-in or add-on or it might be implemented
through the operating system. A full-featured browser also must provide support for
digital signatures and certificates to allow the user to engage in secure transactions and communication
through Secure Sockets Layer/Transport Layer Security (SSL/TLS) encryption with
Hypertext Transfer Protocol Secure (HTTPS).
Modern browsers can launch other applications if necessary to open files or execute procedures.
Using other applications for these extended capabilities keeps the browser itself from getting too
big and cumbersome, and it allows application developers to concentrate on their own area of
specialty. These external applications are typically referred to as add-ons, plug-ins, or helper
applications.
Browsers are often smart enough to recognize a missing plug-in and ask whether you want to
install it if it is needed to open a file or start a video. Most browsers also provide a means for
manually adding, removing, and managing the plug-ins included within the configuration
(Figure 17.6).
FIGURE 17.6
Managing add-ons in Microsoft’s classic Internet Explorer browser.
Classic examples of browser plug-ins are Adobe tools such as the Acrobat reader and the Flash
player. When a browser encounters a reference to a link or reference to a PDF file, it calls the
appropriate Acrobat plug-in to open the file and displays the contents in a browser window.
346 HOUR 17: HTTP, HTML, and the World Wide Web
Some plug-ins provide other forms of extensions and enhanced capabilities. For instance, Firefox
provides an extensive collection of add-ons for alerts, social networking, and privacy (see Figure 17.7).
FIGURE 17.7
Firefox offers add-ons for social networking, privacy, alerts, and other uses.
The recent HTML5 standard, described later in this hour, has reduced the importance of certain
plug-ins such as Flash by offering direct support for video codecs within the browser.
The other critical component of browser configuration, in addition to extending what the browser
can do, is limiting what the browser can do. With new threats appearing on the Internet every day,
and old threats continuing to succeed despite the continuing efforts of the authorities, the security
configuration becomes an important aspect of the browser environment. Most browsers provide
a means for defining the security settings for web activities, in essence to “turn on” or “turn off”
certain capabilities depending on level of trust for the source and the level of privacy and security
required for the user environment. Internet Explorer provides a sliding scale of Internet security
levels, offering varying levels of control over scripts, ActiveX controls, and other elements that
might appear on a website (see Figure 17.8). The new Microsoft Edge browser appears to have a
more limited range of onboard security controls at this writing; however, supporting tools such as
Windows Defender and Group Policy replace some of this functionality. In the simplified world of
Mac OS, the Safari browser offers a means for enabling and disabling Java and JavaScript, blocking
pop-ups, and configuring other aspects of the security environment. Choose Preferences in the
Safari menu and select the Security option to configure Safari security settings (see Figure 17.9).
Firefox, Chrome, Opera, and other browsers offer similar features. Many browsers also let the user
predefine a list of trusted sites that are allowed to operate with fewer security restrictions.
Web Browsers 347
FIGURE 17.8
Most browsers have a way to fine-tune the security level. A more secure browser is safer, but a high security
setting can block legitimate web activity.
FIGURE 17.9
Safari’s simpler interface lets you enable JavaScript and define a cookie policy.
348 HOUR 17: HTTP, HTML, and the World Wide Web
The Semantic Web
An interesting area of research that truly might cause another Internet revolution is an ambitious
concept known as the Semantic Web. The Semantic Web, which has the full support and
advocacy of World Wide Web creator Tim Berners-Lee, is designed as a universal technique for
linking web data with real semantic meaning as a human understands it. In other words, the
goal is to somehow encode the meaning of web information in a way that is easily accessed and
processed by a computer.
To understand the purpose of the Semantic Web, one must start with some sense of how little
knowledge is truly present on a web page. For instance, consider the following lines of text,
which might be present at a typical website:
A Streetcar Named Desire
Lawrence Community Theater
Saturday, October 12, 2016
7:30 PM
A human who looks at this text knows immediately that it is a notice of an event that will occur
at the Lawrence Community Theater at 7:30 on October 12. Many readers will also recognize the
name A Streetcar Named Desire as a famous play, but those who don’t recognize the title will still
infer that the event is a play or movie because it is associated with a theater.
A computer, on the other hand, will just read those lines as alphanumeric text. The computer
doesn’t really know anything about the meaning of the text. It doesn’t know what a theater is,
and it doesn’t know that the third line is a date unless you specifically tell it so. For that matter,
a search engine might even call up this page for a user who is searching for a streetcar schedule.
The tools of the Semantic Web will one day help the web developer encode semantic information
so that an automated process will know that this page is about a play and not about a ticket for
a tram ride. Because this semantic information will be encoded along with the page itself, the
creator of the site won’t need any advance knowledge of how the reader will use the information.
Anyone can come along later and create a tool that searches for information on plays, and
the tool will find the notice of this play. Different websites can present the information differently,
with no standard format or style, and the play finder application will still find the plays—as
long as the semantic information defines the meaning of the text.
Resource Description Framework
Semantic Web techniques are still experimental, although several strategies have appeared in
the publications of the World Wide Web Consortium (W3C). One semantic tool that has received
considerable attention in the web community is called the Resource Description Framework
(RDF). RDF is a framework for expressing relationships that give an indication of meaning.
The Semantic Web 349
The fundamental unit of RDF is a statement consisting of three parts, which is called a triple in
RDF parlance. A triple is structured like a basic sentence, which has a subject, a predicate, and
an object.
For instance, in the sentence “The play has the title A Streetcar Named Desire,” the subject is
“The play,” the object is “A Streetcar Named Desire,” and the predicate is “has the title.”
RDF triples can take on several forms, but the idea is that each element is expressed as a URI,
and the URIs are concatenated in a colon-separated list. The Dublin Core Metadata Initiative
maintains a database of standard predicates referenced in RDF triples. For instance, the
following callout refers to the predicate “has the title”:
RDF and other Semantic Web techniques might someday lead to smarter search tools.
Microformats
RDFs are an extremely powerful tool for adding meaning to text; however, a fierce debate is
going on within the Internet community over whether the RDF concept is too complex and too
much effort to fit in with the methods of ordinary web developers. An alternative approach,
which is less ambitious but, most likely, more manageable and accessible for working web professionals,
is microformats.
Unlike RDFs, microformats do not attempt to represent complete sentence structures and
syntactic constructs. The goal of a microformat is simply to flag a section of text to associate it
with a predefined meaning, so that a browser or other web application that visits the site will
get a clue about the purpose of the text.
Microformats are not part of any official Internet specification, although the practice relies on
the existing tags and concepts underpinning HTML. The microformat community has arisen
independently, partly under the sponsorship of the nonprofit CommerceNet, which is interested
in promoting opportunities for Internet commerce.
A microformat is a specific vocabulary of name/value pairs designed to serve a specific purpose.
Microformat vocabularies have been developed for uses such as the following:
calendars (hCalendar)
business cards (hCard)
recipes (hRecipe)
copyright information (rel-license}
When a block of text is associated with a microformat (such as a resume, which can be identified
with the hResume microformat) the surrounding text elements can then be associated with
the various elements that make up a resume (such as experience, skill, affiliations, publications).
350 HOUR 17: HTTP, HTML, and the World Wide Web
Perhaps the most common microformat in use today is the hCard microformat, which is used
for business cards. hCard is a later incarnation of the vCard format, a MIME type originally
described in RFC 2426 and updated in RFC 6351 and other RFCs.
A simple example of HTML data tagged with the hCard microformat is as follows:
Of course, other settings are also available for specifying a street address and email address, as
well as to specify whether the telephone number is a home, work, cell, or fax number. If text on
a web page is tagged with these hCard settings, a browser that arrives at the site immediately
knows how to treat the information. Microformat-aware browsers automatically format the data
as a business card.
See the microformats.org website for more on the microformats movement, including specifications
for specific microformats and even some tools that automatically generate microformat
data. As you learn later in this hour, a similar concept known as microdata is now in the official
Internet lexicon with the arrival of HTML5.
XHTML
Many tools of the new Web, as well as many other websites on today’s Internet, rely on another
development that is quite technical for the purposes of this hour but is nevertheless worth mentioning.
The XHTML standard is an effort to bridge between old-fashioned HTML and the realities of the
XML-based web environment. (See Hour 18, “Web Services,” for more about XML.) XHTML is essentially
a formulation of HTML functionality that conforms to XML syntax. The XHTML format provides
all the expressive power of HTML within the machine-readable confines of an XML schema.
Although the concepts of XHTML are similar to HTML, XHTML is much more finicky about
sloppy or nonstandard coding practice. Certain declarations occur differently, or more formally,
and the nesting of tags must be more structured and precise. The goal of expressing HTML as an
XML schema is to provide flexibility for developers building scripts and other programs that generate
and interpret the code. XHTML also lends itself more readily to dynamic interpretation or
modification by the receiving entity. For instance, the small screen of a mobile device might not
be able to display a standard HTML page as specified, but a client-side application receiving the
page as XHTML could readily modify the text for the smaller screen.
Many believe the emergence of HTML5 (described in the next section) reduces the importance
of XHTML.
HTML5 351
HTML5
One of the most important changes taking place on the Internet today is the adoption of a new
HTML standard. HTML5 has been in discussion for several years, and it is finally making its way
to the practical side of the everyday Internet.
One who looks at the HTML5 feature list will see that many of its traits reflect the new role of
HTML as a tool for building the mobile revolution. The HTML5 standard includes many features
designed to support web browsing from mobile devices. However, other features simply reflect a
further evolution of the web environment, and incorporate functionality once provided by add-
ons and extensions directly into the HTML.
New important new features of HTML5 include the following:
Local storage and offline application support
Drawing
Embedded audio and video
Geolocation
Semantic elements
The following sections describe these important new developments in HTML5. The HTML5 standard
also includes other improvements, such as a drag-and-drop API and improved support for
forms. In many ways, HTML5 marks the further evolution of HTML to something more like a
development environment for web applications. Developers have long used HTML and its surrounding
technologies to build web-based client/server applications, but much of the functionality
required additional components and third-party extensions. HTML5 builds more of the functionality
directly into the HTML. In the rapidly evolving world of mobile device programming,
developers have begun to use HTML5 to build cross-platform mobile applications that will run
on Android, iPhone, and other platforms with only minor modifications.
Of course, the adoption of the HTML5 standard by a standards committee doesn’t guarantee its
adoption by the larger Internet community. Several popular browsers already provide HTML5
support, and web servers are also getting connected with the newest HTML. However, until web
developers start building ordinary web pages that incorporate HTML5 elements, you won’t see
the benefits of HTML5 in your everyday web surfing experience.
HTML5 Local Storage and Offline Application Support
A cookie is a small bundle of persistent data stored on the remote client system by the web
server. Cookies have been part of the web scene for years, and you’ll find configuration options
in most web browsers that let you manage how cookies are stored and saved. Web servers
352 HOUR 17: HTTP, HTML, and the World Wide Web
use cookies to restore a previous application state or save information on the user’s previous
activities. Cookies are a very useful tool that most web developers (and most web users) are
familiar with; however, they have some limitations. The cookie’s storage size of 4 KB is barely
enough room for a few basic bits of data about the user and session history, but today’s web
programmers see the need for much more local storage.
HTML5 comes with a local storage feature that greatly expands and enhances how web browsers
can store and retrieve information on the local system. HTML5 storage (which is also called
web storage or DOM storage) lets the browser store values for settings defined within the web
application. This local storage provides a number of benefits. For instance, a script executing on
the client side can stash temporary results in the storage area, thus improving performance by
reducing the need for communication with the server over the network. The storage space can
also save a more complete view of the current session state, so that a web-based game or other
interactive application can be restored (and, in some cases, keep operating temporarily) if the
server crashes or the connection is lost.
The local storage capabilities of HTML5 lead to another important improvement: offline
application support. A web browser that supports the offline application feature can keep going
when the network is disconnected.
As shown in Figure 17.10, a web application that supports offline processing includes a cache
manifest, which names the files and other resources required for operating offline. When the
browser first connects to the website, the files provided in the cache manifest are downloaded
to the client system.
Cache
Manifest
Web Client Web Server
FIGURE 17.10
The cache manifest lists the resources necessary for offline processing. The client downloads the required
files and can therefore operate even when the connection is lost.
HTML5 353
When the network is inaccessible, the web application still operates through the offline versions
of the files listed in the cache manifest. This might not sound so impressive at a glance. (Of
course, every application works if all the files it accesses are present on the system.) The problem
is that the files downloaded to the client will soon become out-of-date. However, the interesting
part of the HTML5 offline application feature is that the browser system automatically updates
the files on the local system when the connection is restored and saves all offline changes back
to the server. Thus, the files referenced in the cache manifest stand a better chance of being
current at the time the system goes offline, and the client seamlessly synchronizes its changes
through the restored connection without additional effort by the user.
HTML5’s offline storage feature could also have some disadvantages. As you will learn in Hour 19,
cookies provide a means for advertisers and content providers to track user habits and activities.
By expanding the possibilities for a vendor to store cookie-like information, offline storage could
potentially lead to additional privacy concerns.
HTML5 Drawing
Internet users are accustomed to seeing image files with photographs and diagrams embedded in
web pages. This technique of embedding graphic images greatly enhances the power and beauty
of the Web. However, web designers and developers want more from their pages, including the
ability to draw images programmatically or create small animations that will unfold while the
user is watching. Previous HTML versions add this functionality through third-party add-on
tools, such as Adobe Flash.
HTML5 rolls out its own drawing capabilities through a pair of important new elements: the
, Marks the beginning and end of a heading. Each
and heading tag represents a different heading level.
is the highest level.
Marks the beginning and end of a section
of bold text.
Marks the beginning and end of a section
of underlined text.
Marks the beginning and end of a section
of italicized text.
Marks the beginning and end of a section with
special font characteristics. Contemporary practices
avoid this tag and express font information, instead,
within Cascading Style Sheets. The tag is
not supported in HTML5. See Table 17.2 for some of
the available font attributes.
Defines an anchor—typically used to mark a link. The
link destination URL appears inside the first tag
as a value for the href attribute (as described later in
this section).
![]()
Specifies an image file that should appear in the text.
The file URL appears in the tag as a value for the SRC
attribute. (You’ll learn more about attributes later in
this section.)
334 HOUR 17: HTTP, HTML, and the World Wide Web
Of course, there is much more to HTML than a single table can convey. Many tags apply to a
block of text. If so, the tag appears at the beginning and the end of the block. The tag at the end
of the block includes the slash character (/) to signify that it is an end tag. In other words, the
callout for an H1 heading would be tagged as follows:
Dewey Defeats Truman
An HTML document is supposed to begin with a declaration. The !DOCTYPE
defines the version of HTML used for the document. For HTML 4.0, the !DOCTYPE command
is as follows:
(Web pages that use special browser extensions might specify a different document type.)
Most browsers don’t require the !DOCTYPE statement, and many HTML tutorials don’t even discuss
the !DOCTYPE.
Following the !DOCTYPE statement is the tag. The rest of the document is enclosed
between the tag and a corresponding tag at the end of the file. Within the
beginning and ending tags, the document is divided into the following two sections:
The head (enclosed between the and tags) contains information about
the document. The information in the head does not appear on the web page, although
the tag specifies a title that will appear in the title bar of the browser window.
The <title> is a required element. Other elements of the <head> section are optional,
such as the <style> tag for information on document styles.
The body (enclosed between the <body> and </body> tags) is the text that actually
appears on the web page and includes any HTML tags related to that text.
A simple HTML document follows:
<!DOCTYPE HTML PUBLIC "-//W3C/DTD HTML 4.0//EN">
<html>
<head>
<title> Ooh This is Easy
Easy!
If you save the preceding HTML to a text file and then open the file with a web browser, Easy!
appears in the browser window. (Depending on your browser and operating system, you might
have to save this file with an .htm or .html extension or open it as an HTML file.) The title bar
includes the title Ooh This is Easy (see Figure 17.3).
Understanding HTML 335
FIGURE 17.3
A very easy web page example.
You can spice up the page with additional text and formatting in the body section. The following
example adds the and tags for headings, the
tag for a paragraph, the tag
for bold, the tag for italics, and the tag for font information. Note that the
tag includes an attribute. Attributes are parameters enclosed within the tag that provide additional
information. See Table 17.2 for other font attributes. As you will learn later in this hour,
professional webmasters use Cascading Style Sheets to manage fonts, but the tag, which
is supported through HTML4 but is not found in HTML5, is an easy option for making your first
HTML experiments.
Ooh This is Easy
The Easy and Hard of HTML
Webster's Dictionary defines HTML as "a small snail found originally
in the Canary Islands and ranging now to the Archipelago of Parakeets."
I borrow from this theme in my consideration of HTML as a language that is both
easy and hard.
HTML is Easy
336 HOUR 17: HTTP, HTML, and the World Wide Web
HTML is easy to learn and use because everyone reacts to it energetically.
You can walk into a bar and start speaking HTML, and the man beside you will
happily tell you his many accomplishments.
HTML is Hard
HTML is hard because the options are bewildering. You never know when to use
small text and when to use big text.
TABLE 17.2 HTML Tag Attributes
size Relative font size setting. Values vary from 1 to 7: .
lang Language code denoting the language in which the text is written.
face Typeface setting: .
color Color of the text: .
The preceding example appears in the browser as shown in Figure 17.4.
FIGURE 17.4
Expanding the easy example.
As you learned earlier in this hour, the hypertext link is an important element of web design.
A link is a reference to another document or another part of the current document. If the user clicks
the text of the link, the browser immediately opens the document referenced in the link. The effect
is that the user appears to lilt through an endless garden of colorful and informative content.
Cascading Style Sheets 337
BY THE WAY
What is a Browser?
As you lilt through this colorful garden, pause occasionally to consider that the term browser
originally referred to a giraffe or a large dinosaur eating leaves out of trees.
A link appears in the HTML file as a tag. The simplest form of a link uses the tag with the
URL of the link destination given as a value for the HREF attribute. For instance, in the preceding
example, if you would like the words “Archipelago of Parakeets” to appear as hypertext with a
link to a website that tells about the archipelago, enclose the words within tags as follows:
ranging now to the Archipelago of
Parakeets. I borrow from this theme
The versatile HTML format includes many additional options. You can place a hotspot link
inside a picture. You can create your own style sheets with special tags for preformatted paragraph
styles. You can structure the web page with tables, columns, forms, and frames. Or you
can add radio buttons, check boxes, and pull-down menus. In the early days of HTML, designers
coded all the HTML directly into their documents using text editors (as described in the preceding
examples). Professional web designers now work with special web development applications,
such as Adobe Dreamweaver, that hide the details of HTML and let the designer view the page
as it will appear to the user. New tools such as wikis and content management systems (CMSs)
provide additional options for effortless web design.
Static, preformed HTML documents like those described in this section are still widely used, but
many websites today use dynamic HTML techniques to generate the web content at the time of
the request.
BY THE WAY
Capitalization
With classic HTML tags, capitalization is not significant; however, later standards such as Extensible
Markup Language (XML) and XHTML pay more attention to capitalization. XML is case sensitive, and
XHTML requires lowercase element and attribute names.
Cascading Style Sheets
Although it is possible to encode all formatting instructions into an HTML document (fonts, font
sizes, line types, etc.), in practice, repeating the same tags over and over for the same few style
elements is cumbersome. Perhaps more importantly, on-the-fly modifications can lead to inconsistency
and an unpolished, overly complicated design.
338 HOUR 17: HTTP, HTML, and the World Wide Web
A better approach is to define standard style elements for the document and put them in one
place, then reference those elements in the text. Researchers at the World Wide Web consortium
developed Cascading Style Sheets (CSS) as a way to corral style information in a single document.
The goal is to make HTML more like a modern word processor or desktop publishing tool,
which lets you pick from a list of predefined character or paragraph styles. The style defines a set
of parameters, such as the font size, color, spacing, padding, and margins.
Using a CSS separates the document contents from the presentation information. This approach
makes the HTML much easier to read, and it imposes a stylistic consistency on the document,
which is considered good design practice.
For example, a heading style might be defined as follows in the CSS document:
h1 {
Color: black;
Font-family: Arial, sans-serif;
Margin: 0 4px 0 0;
}
As you can see, the definition consists of colon-separated attributes and values. The items in the
list are separated with semicolons, and the whole style block is enclosed in {}.
The actual callout for the heading in the HTML document then just has to refer to the style:
This Is the Heading
And the attribute values for the style are all applied to the heading.
A Cascading Style Sheets file (with a .css extension) is a common sight on websites today. The
HTML file can reference the CSS file as follows:
Understanding HTTP
As you learned earlier, web servers and browsers communicate using the Hypertext Transfer
Protocol (HTTP). HTTP 1.1, which arrived in 1997 with RFC 2068 and is currently defined in RFCs
7230-7235, was the dominant version of HTTP for many years. A new version, known as HTTP/2,
appeared in 2015. HTTP/2, which is based on Google’s SPDY protocol, primarily provides performance
enhancements and is not intended as a replacement for HTTP’s semantics or status codes.
Many websites and browsers now offer support for HTTP/2, but HTTP 1.1 is still very much present
on the Internet. HTTP/2 is described in RFC 7540.
The purpose of HTTP is to support the transfer of HTML documents. HTTP is an application-
level protocol. The HTTP client and server applications use the reliable TCP transport protocol to
establish a connection.
Understanding HTTP 339
HTTP does the following:
Establishes a connection between the browser (the client) and the server
Negotiates settings and establishes parameters for the session
Provides for the orderly transfer of HTML content
Closes the connection with the server
Although the nature of web communication has become extremely complex, most of that
complexity relates to how the server builds the HTML content and what the browser does with
the content it receives. The actual process of transferring the content through HTML is relatively
uncluttered, although, as you will learn later in this section, HTTP/2 adds some additional
complications to the transfer process in order to improve performance.
When you enter a URL into the browser window, the browser first checks the scheme of the URL
to determine the protocol. (Most web browsers support other protocols in addition to HTTP.) If
the browser determines that the URL refers to a resource on an HTTP site, it extracts the DNS
name from the URL and initiates the name resolution process. The client computer sends the
DNS lookup request to a name server and receives the server’s IP address. The browser then uses
the server’s IP address to initiate a TCP connection with the server. (See Hour 6, “The Transport
Layer,” for more on TCP.)
After the TCP connection is established, the browser uses the HTTP GET command to request the
web page from the server. The GET command contains the URL of the resource the browser is
requesting and the version of HTTP the browser wants to use for the transaction. In most cases,
the browser can send the relative URL with the GET request, rather than the full URL, because the
connection with the server has already been established:
GET /watergate/tapes/transcript HTTP/1.1
Several other optional field:value pairs might follow the GET command, specifying settings
such as the language, browser type, and acceptable file types.
The server response consists of a header followed by the requested document. The format of the
response header is as follows:
HTTP/1.1 status_code reason-phrase
field:value
field:value...
The status code is a three-digit number describing the status of the request. The reason-phrase
is a brief description of the status. Some common status codes are shown in Table 17.3. As you
can see, the leftmost digit of the code identifies a general category. The 100s are informational,
the 200s denote success, the 300s specify redirection, the 400s show a client error, and the 500s
340 HOUR 17: HTTP, HTML, and the World Wide Web
specify a server error. You might be familiar with the famous 404 code, which often appears in
response to a missing page or a mistyped URL. Like the client request, the server response can
also include a number of optional field:value pairs. Some of the header fields are shown in
Table 17.4. Any field that is not understood by the browser is ignored.
TABLE 17.3 Some Common HTTP Status Codes
Code Reason-Phrase Description
100 Continue Request is in process.
200 OK Request is successful.
202 Accepted Request accepted for processing but not finished.
301 Moving Permanently Resource has a new address.
302 Moving Temporarily Resource has a new temporary address.
400 Bad Request Server doesn’t recognize the request.
401 Unauthorized Authorization failed.
404 Not Found Resource requested doesn’t exist.
406 Not Acceptable Content will not be acceptable to browser.
500 Internal Server Error Server encountered error.
503 Service Unavailable Server is overloaded or not working.
TABLE 17.4 Examples of HTTP Header Fields
Field Value Must Be Description
Content-Length Integer Size of the content object in octets
Content-Encoding x-compress x-gzip Value representing the type of encoding
associated with the message
Date Standard date format defined Date in Greenwich mean time when
in RFC 1036 the object was created
Last-modified date Standard date format defined Date in Greenwich mean time when
in RFC 1036 the object was last modified
Content-Language Language code per ISO 3316 The language in which the object was
written
As you can see from Table 17.4, some of the header fields are purely informational. Other header
fields might contain information used to parse and process the incoming HTML document.
The Content-Length field is particularly important. In the earlier HTTP version 1.0, each
request/response cycle required a new TCP connection. The client opened a connection and
initiated a request. The server fulfilled the request and then closed the connection. In that
Scripting 341
situation, the client knew when the server had stopped sending data because the server closed
the TCP connection. Unfortunately, this process required the increased overhead necessary for
continually opening and closing connections. HTTP 1.1 allows the client and server to maintain
the connection for longer than a single transmission. In that case, the client needs some way of
knowing when a single response is finished. The Content-Length field specifies the length of the
HTML object associated with the response. If the server doesn’t know the length of the object it is
sending—a situation increasingly common with the appearance of dynamic HTML—the server
sends the header field Connection:close to notify the browser that the server will specify the
end of the data by closing the connection. HTTP also supports a negotiation phase in which the
server and browser agree to common settings for certain format and preference options.
As mentioned previously, HTTP/2 was developed for performance reasons and does not change
HTTP 1.1 syntax or methods. Some of the benefits of HTTP/2 are:
Parallel processing within a connection: HTTP 1.1 let the browser open multiple simultaneous
connections, but each connection could only respond to one request at a time.
HTTP/2 allows the server to service multiple requests at once through the same connection.
Header compression: Header information transferred at the start of a new connection
can slow down the response time significantly. Compression reduces the total size of the
header data.
Server “push” responses: The server can provide content for the client before waiting for a
request. As websites grow more complex, one page might contain several different objects,
such as graphics files. Rather than waiting on a request for each item, the server can anticipate
the request for these additional objects and push the content directly.
HTTP/2 does not require encryption but strongly supports it and provides a standard profile for TLS
encryption. (You’ll learn more about encryption in Hour 19, “Encryption, Tracking, and Privacy.”)
Scripting
The web page has evolved tremendously in the last 20 years, and most professional web pages
today are quite unlike the ideal described earlier in this hour of a simple text file embedded with
static HTML tags.
Modern web pages are often a complex pastiche of objects, scripts, and machine-generated code
produced on the fly in response to user input and back-end data. The versatile HTML makes it
easy to insert data or additional instructions into the page as it is delivered, or to add code that
will execute after the page arrives.
Web browsers have become very adept at interpreting and manipulating this incoming code. As
you learn in the next hour, special tools called content management systems run on the web server,
obscuring the details of HTML code generation to provide a simple interface for the web developer.
342 HOUR 17: HTTP, HTML, and the World Wide Web
Two fundamental techniques for autogenerating web code are server-side scripting and client-
side scripting.
As you learn later in this hour, the collection of plug-in and add-on applications running on the
client system add another dimension to the activities that can be triggered from a web page. For
more about advanced web techniques see Hour 18, “Web Services.”
Most of these technologies are actually programming topics. The end user doesn’t really have
to know whether the image or table embedded in a web page comes from a static callout or a
script. However, a brief introduction to some of the concepts will provide some insights on how
HTML is used on today’s Internet.
Server-Side Scripting
Server-side scripting lets the server accept input from the client and process that input behind the
scenes. A common server-side scripting scenario is shown in Figure 17.5. The process is as follows:
1. The user browses to a page that includes a form for purchasing a product or entering visitor
information.
2. The server generates the form based on user choices and transmits the form to the browser.
3. The user enters the necessary information into the form, and the browser transmits the
form back to the server. (Note that the HTML form feature reverses the usual process. The
browser sends content to the server at the server’s request.)
4. The server accepts the data from the browser and uses a programming interface to pass
the data to programs that process the user information. If the user is purchasing a product,
these behind-the-scenes programs may check credit card information or send a shipment
order to the mail room. If the user is adding his name to a mailing list or joining a restricted
online site, a program may add the user information to a database.
Completed
Form
Form
Web
Server
Data
Server Request
Script
Scripting
Interface
FIGURE 17.5
A server-side scripting scenario.
Scripting 343
Several programming languages and environments have evolved to help developers build
server-based web applications. One method for interfacing a program or script with a web page
is through the Common Gateway Interface (CGI). CGI was developed to accept form-based
input from a web user, process that input, and then generate output in the form of HTML. CGI
scripts are commonly written in the Perl language, but CGI is compatible with other languages,
including C.
PHP is also becoming increasingly popular as a language for web development. A simple PHP
script is often embedded within an HTML tag:
Or defined using the
A web server that supports PHP parses and executes the code between the brackets, inserting the
output of the PHP command set in place of the tag as the page is delivered to the client.
Microsoft’s Active Server Page (ASP) and the later ASP.NET technologies are also popular server-
side web techniques. The concept of a web interface to a custom, server-side application has led
to a whole paradigm for programming known as the web services environment. Many of the
leading hardware and software vendors, including IBM, Microsoft, and others, have developed
sophisticated infrastructures to support web service programming.
Client-Side Scripting
Another way to integrate scripts with the web environment is on the client side (that is, on the
local client computer system that is running the web browser application). Whereas a server-side
script is executed on the server and the output of the script is embedded in the page, a client-side
solution transfers the embedded script along with the rest of the HTML code and text, and the
script is executed by the browser.
JavaScript and VBScript are two common client-side scripting technologies. The script file is often
referenced through the HTML:
The tag can reference the actual instructions, or it can refer to an external file containing the
code. In either case, this technique only works if the client computer includes support for the
scripting language referenced in the code.
For certain types of applications, client-side scripting is a more efficient alternative. An
interpreter executing the script on the client has a much more detailed view of the local
environment. Also, confining interactive elements to the client reduces network traffic and
improves performance.
344 HOUR 17: HTTP, HTML, and the World Wide Web
AJAX (which is sometimes billed as an acronym for Asynchronous JavaScript and XML) is a collection
of technologies that use client-side scripting to provide for seamless update of web content
without a full refresh of the web page. Other common client-side techniques offer interactive
options for the user, invoke animations or other multimedia effects, or respond to information
on the state of the client system.
Client-side scripting is extremely common, but as you can imagine, it poses some security challenges.
What intruder would not love the chance to execute code on the client system? Most
systems now take measures to restrict the privileges of code executing on the browser, and, as
you will learn in the next section, users have some freedom to limit the use of browser-launched
scripts. As is often the case with network-related software, the best precaution is often to keep
your system up to date and install security patches whenever they are available.
Web Browsers
As you probably already know, the whole business of the World Wide Web depends on a very
special and versatile application known as a web browser. In the client-server model discussed
earlier in this book, the web browser is the client. Early, simple browsers originally just rendered
the early, simple, static HTML files discussed in earlier hours. When web data arrived from
the server, browsers interpreted the tags, formatting the text with the specified fonts, links,
and photos.
As web data became more complex, the web browser evolved with it, and as the web became
the center of Internet commercial activity, the browser became a major source of competition
and corporate leverage among leading software companies in an era that is now known as
the “browser wars.”
Why declare a war over browsers, which have no market value in their own right and are
mostly given away as free software (either bundled with the OS or downloadable at no charge)?
Big companies like Microsoft and Netscape (and later Google) knew that by controlling the
browser they could control a whole range of technologies surrounding Internet activity, not just
web servers but also the lucrative and influential business of providing development tools and
application programming interfaces (APIs) that interact with the operating system.
At one point, Microsoft even said it had embedded its browser Internet Explorer into the
operating system itself in a way that could not be separated (an argument that was later rejected
by the courts). Microsoft wanted to extend its control of the OS market to control of the browser
market so that they could control the development environment and build pathways back into
the operating system to ensure the continued dominance of their OS projects.
From the user’s perspective, the browser is the focal point for everything that happens on
today’s Internet. The purpose of the HTML and HTTP standards is to ensure that any standard-
compliant browser can communicate with any standard-compliant server. However,
the big vendors have a tendency to use the standard as a minimum and to add their own
Web Browsers 345
enhancements, which has the same effect of locking in the user who has invested in building
custom tools for a proprietary development environment. Microsoft was forced through legal
action to open its APIs, which has largely addressed this issue. To fully participate in today’s
Internet, a browser must support the client-side scripting described earlier in this hour through
support for JavaScript or some other scripting technology. Depending on the browser and
system, this support might take the form of a browser plug-in or add-on or it might be implemented
through the operating system. A full-featured browser also must provide support for
digital signatures and certificates to allow the user to engage in secure transactions and communication
through Secure Sockets Layer/Transport Layer Security (SSL/TLS) encryption with
Hypertext Transfer Protocol Secure (HTTPS).
Modern browsers can launch other applications if necessary to open files or execute procedures.
Using other applications for these extended capabilities keeps the browser itself from getting too
big and cumbersome, and it allows application developers to concentrate on their own area of
specialty. These external applications are typically referred to as add-ons, plug-ins, or helper
applications.
Browsers are often smart enough to recognize a missing plug-in and ask whether you want to
install it if it is needed to open a file or start a video. Most browsers also provide a means for
manually adding, removing, and managing the plug-ins included within the configuration
(Figure 17.6).
FIGURE 17.6
Managing add-ons in Microsoft’s classic Internet Explorer browser.
Classic examples of browser plug-ins are Adobe tools such as the Acrobat reader and the Flash
player. When a browser encounters a reference to a link or reference to a PDF file, it calls the
appropriate Acrobat plug-in to open the file and displays the contents in a browser window.
346 HOUR 17: HTTP, HTML, and the World Wide Web
Some plug-ins provide other forms of extensions and enhanced capabilities. For instance, Firefox
provides an extensive collection of add-ons for alerts, social networking, and privacy (see Figure 17.7).
FIGURE 17.7
Firefox offers add-ons for social networking, privacy, alerts, and other uses.
The recent HTML5 standard, described later in this hour, has reduced the importance of certain
plug-ins such as Flash by offering direct support for video codecs within the browser.
The other critical component of browser configuration, in addition to extending what the browser
can do, is limiting what the browser can do. With new threats appearing on the Internet every day,
and old threats continuing to succeed despite the continuing efforts of the authorities, the security
configuration becomes an important aspect of the browser environment. Most browsers provide
a means for defining the security settings for web activities, in essence to “turn on” or “turn off”
certain capabilities depending on level of trust for the source and the level of privacy and security
required for the user environment. Internet Explorer provides a sliding scale of Internet security
levels, offering varying levels of control over scripts, ActiveX controls, and other elements that
might appear on a website (see Figure 17.8). The new Microsoft Edge browser appears to have a
more limited range of onboard security controls at this writing; however, supporting tools such as
Windows Defender and Group Policy replace some of this functionality. In the simplified world of
Mac OS, the Safari browser offers a means for enabling and disabling Java and JavaScript, blocking
pop-ups, and configuring other aspects of the security environment. Choose Preferences in the
Safari menu and select the Security option to configure Safari security settings (see Figure 17.9).
Firefox, Chrome, Opera, and other browsers offer similar features. Many browsers also let the user
predefine a list of trusted sites that are allowed to operate with fewer security restrictions.
Web Browsers 347
FIGURE 17.8
Most browsers have a way to fine-tune the security level. A more secure browser is safer, but a high security
setting can block legitimate web activity.
FIGURE 17.9
Safari’s simpler interface lets you enable JavaScript and define a cookie policy.
348 HOUR 17: HTTP, HTML, and the World Wide Web
The Semantic Web
An interesting area of research that truly might cause another Internet revolution is an ambitious
concept known as the Semantic Web. The Semantic Web, which has the full support and
advocacy of World Wide Web creator Tim Berners-Lee, is designed as a universal technique for
linking web data with real semantic meaning as a human understands it. In other words, the
goal is to somehow encode the meaning of web information in a way that is easily accessed and
processed by a computer.
To understand the purpose of the Semantic Web, one must start with some sense of how little
knowledge is truly present on a web page. For instance, consider the following lines of text,
which might be present at a typical website:
A Streetcar Named Desire
Lawrence Community Theater
Saturday, October 12, 2016
7:30 PM
A human who looks at this text knows immediately that it is a notice of an event that will occur
at the Lawrence Community Theater at 7:30 on October 12. Many readers will also recognize the
name A Streetcar Named Desire as a famous play, but those who don’t recognize the title will still
infer that the event is a play or movie because it is associated with a theater.
A computer, on the other hand, will just read those lines as alphanumeric text. The computer
doesn’t really know anything about the meaning of the text. It doesn’t know what a theater is,
and it doesn’t know that the third line is a date unless you specifically tell it so. For that matter,
a search engine might even call up this page for a user who is searching for a streetcar schedule.
The tools of the Semantic Web will one day help the web developer encode semantic information
so that an automated process will know that this page is about a play and not about a ticket for
a tram ride. Because this semantic information will be encoded along with the page itself, the
creator of the site won’t need any advance knowledge of how the reader will use the information.
Anyone can come along later and create a tool that searches for information on plays, and
the tool will find the notice of this play. Different websites can present the information differently,
with no standard format or style, and the play finder application will still find the plays—as
long as the semantic information defines the meaning of the text.
Resource Description Framework
Semantic Web techniques are still experimental, although several strategies have appeared in
the publications of the World Wide Web Consortium (W3C). One semantic tool that has received
considerable attention in the web community is called the Resource Description Framework
(RDF). RDF is a framework for expressing relationships that give an indication of meaning.
The Semantic Web 349
The fundamental unit of RDF is a statement consisting of three parts, which is called a triple in
RDF parlance. A triple is structured like a basic sentence, which has a subject, a predicate, and
an object.
For instance, in the sentence “The play has the title A Streetcar Named Desire,” the subject is
“The play,” the object is “A Streetcar Named Desire,” and the predicate is “has the title.”
RDF triples can take on several forms, but the idea is that each element is expressed as a URI,
and the URIs are concatenated in a colon-separated list. The Dublin Core Metadata Initiative
maintains a database of standard predicates referenced in RDF triples. For instance, the
following callout refers to the predicate “has the title”:
RDF and other Semantic Web techniques might someday lead to smarter search tools.
Microformats
RDFs are an extremely powerful tool for adding meaning to text; however, a fierce debate is
going on within the Internet community over whether the RDF concept is too complex and too
much effort to fit in with the methods of ordinary web developers. An alternative approach,
which is less ambitious but, most likely, more manageable and accessible for working web professionals,
is microformats.
Unlike RDFs, microformats do not attempt to represent complete sentence structures and
syntactic constructs. The goal of a microformat is simply to flag a section of text to associate it
with a predefined meaning, so that a browser or other web application that visits the site will
get a clue about the purpose of the text.
Microformats are not part of any official Internet specification, although the practice relies on
the existing tags and concepts underpinning HTML. The microformat community has arisen
independently, partly under the sponsorship of the nonprofit CommerceNet, which is interested
in promoting opportunities for Internet commerce.
A microformat is a specific vocabulary of name/value pairs designed to serve a specific purpose.
Microformat vocabularies have been developed for uses such as the following:
calendars (hCalendar)
business cards (hCard)
recipes (hRecipe)
copyright information (rel-license}
When a block of text is associated with a microformat (such as a resume, which can be identified
with the hResume microformat) the surrounding text elements can then be associated with
the various elements that make up a resume (such as experience, skill, affiliations, publications).
350 HOUR 17: HTTP, HTML, and the World Wide Web
Perhaps the most common microformat in use today is the hCard microformat, which is used
for business cards. hCard is a later incarnation of the vCard format, a MIME type originally
described in RFC 2426 and updated in RFC 6351 and other RFCs.
A simple example of HTML data tagged with the hCard microformat is as follows:
Of course, other settings are also available for specifying a street address and email address, as
well as to specify whether the telephone number is a home, work, cell, or fax number. If text on
a web page is tagged with these hCard settings, a browser that arrives at the site immediately
knows how to treat the information. Microformat-aware browsers automatically format the data
as a business card.
See the microformats.org website for more on the microformats movement, including specifications
for specific microformats and even some tools that automatically generate microformat
data. As you learn later in this hour, a similar concept known as microdata is now in the official
Internet lexicon with the arrival of HTML5.
XHTML
Many tools of the new Web, as well as many other websites on today’s Internet, rely on another
development that is quite technical for the purposes of this hour but is nevertheless worth mentioning.
The XHTML standard is an effort to bridge between old-fashioned HTML and the realities of the
XML-based web environment. (See Hour 18, “Web Services,” for more about XML.) XHTML is essentially
a formulation of HTML functionality that conforms to XML syntax. The XHTML format provides
all the expressive power of HTML within the machine-readable confines of an XML schema.
Although the concepts of XHTML are similar to HTML, XHTML is much more finicky about
sloppy or nonstandard coding practice. Certain declarations occur differently, or more formally,
and the nesting of tags must be more structured and precise. The goal of expressing HTML as an
XML schema is to provide flexibility for developers building scripts and other programs that generate
and interpret the code. XHTML also lends itself more readily to dynamic interpretation or
modification by the receiving entity. For instance, the small screen of a mobile device might not
be able to display a standard HTML page as specified, but a client-side application receiving the
page as XHTML could readily modify the text for the smaller screen.
Many believe the emergence of HTML5 (described in the next section) reduces the importance
of XHTML.
HTML5 351
HTML5
One of the most important changes taking place on the Internet today is the adoption of a new
HTML standard. HTML5 has been in discussion for several years, and it is finally making its way
to the practical side of the everyday Internet.
One who looks at the HTML5 feature list will see that many of its traits reflect the new role of
HTML as a tool for building the mobile revolution. The HTML5 standard includes many features
designed to support web browsing from mobile devices. However, other features simply reflect a
further evolution of the web environment, and incorporate functionality once provided by add-
ons and extensions directly into the HTML.
New important new features of HTML5 include the following:
Local storage and offline application support
Drawing
Embedded audio and video
Geolocation
Semantic elements
The following sections describe these important new developments in HTML5. The HTML5 standard
also includes other improvements, such as a drag-and-drop API and improved support for
forms. In many ways, HTML5 marks the further evolution of HTML to something more like a
development environment for web applications. Developers have long used HTML and its surrounding
technologies to build web-based client/server applications, but much of the functionality
required additional components and third-party extensions. HTML5 builds more of the functionality
directly into the HTML. In the rapidly evolving world of mobile device programming,
developers have begun to use HTML5 to build cross-platform mobile applications that will run
on Android, iPhone, and other platforms with only minor modifications.
Of course, the adoption of the HTML5 standard by a standards committee doesn’t guarantee its
adoption by the larger Internet community. Several popular browsers already provide HTML5
support, and web servers are also getting connected with the newest HTML. However, until web
developers start building ordinary web pages that incorporate HTML5 elements, you won’t see
the benefits of HTML5 in your everyday web surfing experience.
HTML5 Local Storage and Offline Application Support
A cookie is a small bundle of persistent data stored on the remote client system by the web
server. Cookies have been part of the web scene for years, and you’ll find configuration options
in most web browsers that let you manage how cookies are stored and saved. Web servers
352 HOUR 17: HTTP, HTML, and the World Wide Web
use cookies to restore a previous application state or save information on the user’s previous
activities. Cookies are a very useful tool that most web developers (and most web users) are
familiar with; however, they have some limitations. The cookie’s storage size of 4 KB is barely
enough room for a few basic bits of data about the user and session history, but today’s web
programmers see the need for much more local storage.
HTML5 comes with a local storage feature that greatly expands and enhances how web browsers
can store and retrieve information on the local system. HTML5 storage (which is also called
web storage or DOM storage) lets the browser store values for settings defined within the web
application. This local storage provides a number of benefits. For instance, a script executing on
the client side can stash temporary results in the storage area, thus improving performance by
reducing the need for communication with the server over the network. The storage space can
also save a more complete view of the current session state, so that a web-based game or other
interactive application can be restored (and, in some cases, keep operating temporarily) if the
server crashes or the connection is lost.
The local storage capabilities of HTML5 lead to another important improvement: offline
application support. A web browser that supports the offline application feature can keep going
when the network is disconnected.
As shown in Figure 17.10, a web application that supports offline processing includes a cache
manifest, which names the files and other resources required for operating offline. When the
browser first connects to the website, the files provided in the cache manifest are downloaded
to the client system.
Cache
Manifest
Web Client Web Server
FIGURE 17.10
The cache manifest lists the resources necessary for offline processing. The client downloads the required
files and can therefore operate even when the connection is lost.
HTML5 353
When the network is inaccessible, the web application still operates through the offline versions
of the files listed in the cache manifest. This might not sound so impressive at a glance. (Of
course, every application works if all the files it accesses are present on the system.) The problem
is that the files downloaded to the client will soon become out-of-date. However, the interesting
part of the HTML5 offline application feature is that the browser system automatically updates
the files on the local system when the connection is restored and saves all offline changes back
to the server. Thus, the files referenced in the cache manifest stand a better chance of being
current at the time the system goes offline, and the client seamlessly synchronizes its changes
through the restored connection without additional effort by the user.
HTML5’s offline storage feature could also have some disadvantages. As you will learn in Hour 19,
cookies provide a means for advertisers and content providers to track user habits and activities.
By expanding the possibilities for a vendor to store cookie-like information, offline storage could
potentially lead to additional privacy concerns.
HTML5 Drawing
Internet users are accustomed to seeing image files with photographs and diagrams embedded in
web pages. This technique of embedding graphic images greatly enhances the power and beauty
of the Web. However, web designers and developers want more from their pages, including the
ability to draw images programmatically or create small animations that will unfold while the
user is watching. Previous HTML versions add this functionality through third-party add-on
tools, such as Adobe Flash.
HTML5 rolls out its own drawing capabilities through a pair of important new elements: the
is the highest level.
Marks the beginning and end of a section
of bold text.
Marks the beginning and end of a section
of underlined text.
Marks the beginning and end of a section
of italicized text.
Marks the beginning and end of a section with
special font characteristics. Contemporary practices
avoid this tag and express font information, instead,
within Cascading Style Sheets. The tag is
not supported in HTML5. See Table 17.2 for some of
the available font attributes.
Defines an anchor—typically used to mark a link. The
link destination URL appears inside the first tag
as a value for the href attribute (as described later in
this section).
![]()
Specifies an image file that should appear in the text.
The file URL appears in the tag as a value for the SRC
attribute. (You’ll learn more about attributes later in
this section.)
334 HOUR 17: HTTP, HTML, and the World Wide Web
Of course, there is much more to HTML than a single table can convey. Many tags apply to a
block of text. If so, the tag appears at the beginning and the end of the block. The tag at the end
of the block includes the slash character (/) to signify that it is an end tag. In other words, the
callout for an H1 heading would be tagged as follows:
Dewey Defeats Truman
An HTML document is supposed to begin with a declaration. The !DOCTYPE
defines the version of HTML used for the document. For HTML 4.0, the !DOCTYPE command
is as follows:
(Web pages that use special browser extensions might specify a different document type.)
Most browsers don’t require the !DOCTYPE statement, and many HTML tutorials don’t even discuss
the !DOCTYPE.
Following the !DOCTYPE statement is the tag. The rest of the document is enclosed
between the tag and a corresponding tag at the end of the file. Within the
beginning and ending tags, the document is divided into the following two sections:
The head (enclosed between the and tags) contains information about
the document. The information in the head does not appear on the web page, although
the tag specifies a title that will appear in the title bar of the browser window.
The <title> is a required element. Other elements of the <head> section are optional,
such as the <style> tag for information on document styles.
The body (enclosed between the <body> and </body> tags) is the text that actually
appears on the web page and includes any HTML tags related to that text.
A simple HTML document follows:
<!DOCTYPE HTML PUBLIC "-//W3C/DTD HTML 4.0//EN">
<html>
<head>
<title> Ooh This is Easy
Easy!
If you save the preceding HTML to a text file and then open the file with a web browser, Easy!
appears in the browser window. (Depending on your browser and operating system, you might
have to save this file with an .htm or .html extension or open it as an HTML file.) The title bar
includes the title Ooh This is Easy (see Figure 17.3).
Understanding HTML 335
FIGURE 17.3
A very easy web page example.
You can spice up the page with additional text and formatting in the body section. The following
example adds the and tags for headings, the
tag for a paragraph, the tag
for bold, the tag for italics, and the tag for font information. Note that the
tag includes an attribute. Attributes are parameters enclosed within the tag that provide additional
information. See Table 17.2 for other font attributes. As you will learn later in this hour,
professional webmasters use Cascading Style Sheets to manage fonts, but the tag, which
is supported through HTML4 but is not found in HTML5, is an easy option for making your first
HTML experiments.
Ooh This is Easy
The Easy and Hard of HTML
Webster's Dictionary defines HTML as "a small snail found originally
in the Canary Islands and ranging now to the Archipelago of Parakeets."
I borrow from this theme in my consideration of HTML as a language that is both
easy and hard.
HTML is Easy
336 HOUR 17: HTTP, HTML, and the World Wide Web
HTML is easy to learn and use because everyone reacts to it energetically.
You can walk into a bar and start speaking HTML, and the man beside you will
happily tell you his many accomplishments.
HTML is Hard
HTML is hard because the options are bewildering. You never know when to use
small text and when to use big text.
TABLE 17.2 HTML Tag Attributes
size Relative font size setting. Values vary from 1 to 7: .
lang Language code denoting the language in which the text is written.
face Typeface setting: .
color Color of the text: .
The preceding example appears in the browser as shown in Figure 17.4.
FIGURE 17.4
Expanding the easy example.
As you learned earlier in this hour, the hypertext link is an important element of web design.
A link is a reference to another document or another part of the current document. If the user clicks
the text of the link, the browser immediately opens the document referenced in the link. The effect
is that the user appears to lilt through an endless garden of colorful and informative content.
Cascading Style Sheets 337
BY THE WAY
What is a Browser?
As you lilt through this colorful garden, pause occasionally to consider that the term browser
originally referred to a giraffe or a large dinosaur eating leaves out of trees.
A link appears in the HTML file as a tag. The simplest form of a link uses the tag with the
URL of the link destination given as a value for the HREF attribute. For instance, in the preceding
example, if you would like the words “Archipelago of Parakeets” to appear as hypertext with a
link to a website that tells about the archipelago, enclose the words within tags as follows:
ranging now to the Archipelago of
Parakeets. I borrow from this theme
The versatile HTML format includes many additional options. You can place a hotspot link
inside a picture. You can create your own style sheets with special tags for preformatted paragraph
styles. You can structure the web page with tables, columns, forms, and frames. Or you
can add radio buttons, check boxes, and pull-down menus. In the early days of HTML, designers
coded all the HTML directly into their documents using text editors (as described in the preceding
examples). Professional web designers now work with special web development applications,
such as Adobe Dreamweaver, that hide the details of HTML and let the designer view the page
as it will appear to the user. New tools such as wikis and content management systems (CMSs)
provide additional options for effortless web design.
Static, preformed HTML documents like those described in this section are still widely used, but
many websites today use dynamic HTML techniques to generate the web content at the time of
the request.
BY THE WAY
Capitalization
With classic HTML tags, capitalization is not significant; however, later standards such as Extensible
Markup Language (XML) and XHTML pay more attention to capitalization. XML is case sensitive, and
XHTML requires lowercase element and attribute names.
Cascading Style Sheets
Although it is possible to encode all formatting instructions into an HTML document (fonts, font
sizes, line types, etc.), in practice, repeating the same tags over and over for the same few style
elements is cumbersome. Perhaps more importantly, on-the-fly modifications can lead to inconsistency
and an unpolished, overly complicated design.
338 HOUR 17: HTTP, HTML, and the World Wide Web
A better approach is to define standard style elements for the document and put them in one
place, then reference those elements in the text. Researchers at the World Wide Web consortium
developed Cascading Style Sheets (CSS) as a way to corral style information in a single document.
The goal is to make HTML more like a modern word processor or desktop publishing tool,
which lets you pick from a list of predefined character or paragraph styles. The style defines a set
of parameters, such as the font size, color, spacing, padding, and margins.
Using a CSS separates the document contents from the presentation information. This approach
makes the HTML much easier to read, and it imposes a stylistic consistency on the document,
which is considered good design practice.
For example, a heading style might be defined as follows in the CSS document:
h1 {
Color: black;
Font-family: Arial, sans-serif;
Margin: 0 4px 0 0;
}
As you can see, the definition consists of colon-separated attributes and values. The items in the
list are separated with semicolons, and the whole style block is enclosed in {}.
The actual callout for the heading in the HTML document then just has to refer to the style:
This Is the Heading
And the attribute values for the style are all applied to the heading.
A Cascading Style Sheets file (with a .css extension) is a common sight on websites today. The
HTML file can reference the CSS file as follows:
Understanding HTTP
As you learned earlier, web servers and browsers communicate using the Hypertext Transfer
Protocol (HTTP). HTTP 1.1, which arrived in 1997 with RFC 2068 and is currently defined in RFCs
7230-7235, was the dominant version of HTTP for many years. A new version, known as HTTP/2,
appeared in 2015. HTTP/2, which is based on Google’s SPDY protocol, primarily provides performance
enhancements and is not intended as a replacement for HTTP’s semantics or status codes.
Many websites and browsers now offer support for HTTP/2, but HTTP 1.1 is still very much present
on the Internet. HTTP/2 is described in RFC 7540.
The purpose of HTTP is to support the transfer of HTML documents. HTTP is an application-
level protocol. The HTTP client and server applications use the reliable TCP transport protocol to
establish a connection.
Understanding HTTP 339
HTTP does the following:
Establishes a connection between the browser (the client) and the server
Negotiates settings and establishes parameters for the session
Provides for the orderly transfer of HTML content
Closes the connection with the server
Although the nature of web communication has become extremely complex, most of that
complexity relates to how the server builds the HTML content and what the browser does with
the content it receives. The actual process of transferring the content through HTML is relatively
uncluttered, although, as you will learn later in this section, HTTP/2 adds some additional
complications to the transfer process in order to improve performance.
When you enter a URL into the browser window, the browser first checks the scheme of the URL
to determine the protocol. (Most web browsers support other protocols in addition to HTTP.) If
the browser determines that the URL refers to a resource on an HTTP site, it extracts the DNS
name from the URL and initiates the name resolution process. The client computer sends the
DNS lookup request to a name server and receives the server’s IP address. The browser then uses
the server’s IP address to initiate a TCP connection with the server. (See Hour 6, “The Transport
Layer,” for more on TCP.)
After the TCP connection is established, the browser uses the HTTP GET command to request the
web page from the server. The GET command contains the URL of the resource the browser is
requesting and the version of HTTP the browser wants to use for the transaction. In most cases,
the browser can send the relative URL with the GET request, rather than the full URL, because the
connection with the server has already been established:
GET /watergate/tapes/transcript HTTP/1.1
Several other optional field:value pairs might follow the GET command, specifying settings
such as the language, browser type, and acceptable file types.
The server response consists of a header followed by the requested document. The format of the
response header is as follows:
HTTP/1.1 status_code reason-phrase
field:value
field:value...
The status code is a three-digit number describing the status of the request. The reason-phrase
is a brief description of the status. Some common status codes are shown in Table 17.3. As you
can see, the leftmost digit of the code identifies a general category. The 100s are informational,
the 200s denote success, the 300s specify redirection, the 400s show a client error, and the 500s
340 HOUR 17: HTTP, HTML, and the World Wide Web
specify a server error. You might be familiar with the famous 404 code, which often appears in
response to a missing page or a mistyped URL. Like the client request, the server response can
also include a number of optional field:value pairs. Some of the header fields are shown in
Table 17.4. Any field that is not understood by the browser is ignored.
TABLE 17.3 Some Common HTTP Status Codes
Code Reason-Phrase Description
100 Continue Request is in process.
200 OK Request is successful.
202 Accepted Request accepted for processing but not finished.
301 Moving Permanently Resource has a new address.
302 Moving Temporarily Resource has a new temporary address.
400 Bad Request Server doesn’t recognize the request.
401 Unauthorized Authorization failed.
404 Not Found Resource requested doesn’t exist.
406 Not Acceptable Content will not be acceptable to browser.
500 Internal Server Error Server encountered error.
503 Service Unavailable Server is overloaded or not working.
TABLE 17.4 Examples of HTTP Header Fields
Field Value Must Be Description
Content-Length Integer Size of the content object in octets
Content-Encoding x-compress x-gzip Value representing the type of encoding
associated with the message
Date Standard date format defined Date in Greenwich mean time when
in RFC 1036 the object was created
Last-modified date Standard date format defined Date in Greenwich mean time when
in RFC 1036 the object was last modified
Content-Language Language code per ISO 3316 The language in which the object was
written
As you can see from Table 17.4, some of the header fields are purely informational. Other header
fields might contain information used to parse and process the incoming HTML document.
The Content-Length field is particularly important. In the earlier HTTP version 1.0, each
request/response cycle required a new TCP connection. The client opened a connection and
initiated a request. The server fulfilled the request and then closed the connection. In that
Scripting 341
situation, the client knew when the server had stopped sending data because the server closed
the TCP connection. Unfortunately, this process required the increased overhead necessary for
continually opening and closing connections. HTTP 1.1 allows the client and server to maintain
the connection for longer than a single transmission. In that case, the client needs some way of
knowing when a single response is finished. The Content-Length field specifies the length of the
HTML object associated with the response. If the server doesn’t know the length of the object it is
sending—a situation increasingly common with the appearance of dynamic HTML—the server
sends the header field Connection:close to notify the browser that the server will specify the
end of the data by closing the connection. HTTP also supports a negotiation phase in which the
server and browser agree to common settings for certain format and preference options.
As mentioned previously, HTTP/2 was developed for performance reasons and does not change
HTTP 1.1 syntax or methods. Some of the benefits of HTTP/2 are:
Parallel processing within a connection: HTTP 1.1 let the browser open multiple simultaneous
connections, but each connection could only respond to one request at a time.
HTTP/2 allows the server to service multiple requests at once through the same connection.
Header compression: Header information transferred at the start of a new connection
can slow down the response time significantly. Compression reduces the total size of the
header data.
Server “push” responses: The server can provide content for the client before waiting for a
request. As websites grow more complex, one page might contain several different objects,
such as graphics files. Rather than waiting on a request for each item, the server can anticipate
the request for these additional objects and push the content directly.
HTTP/2 does not require encryption but strongly supports it and provides a standard profile for TLS
encryption. (You’ll learn more about encryption in Hour 19, “Encryption, Tracking, and Privacy.”)
Scripting
The web page has evolved tremendously in the last 20 years, and most professional web pages
today are quite unlike the ideal described earlier in this hour of a simple text file embedded with
static HTML tags.
Modern web pages are often a complex pastiche of objects, scripts, and machine-generated code
produced on the fly in response to user input and back-end data. The versatile HTML makes it
easy to insert data or additional instructions into the page as it is delivered, or to add code that
will execute after the page arrives.
Web browsers have become very adept at interpreting and manipulating this incoming code. As
you learn in the next hour, special tools called content management systems run on the web server,
obscuring the details of HTML code generation to provide a simple interface for the web developer.
342 HOUR 17: HTTP, HTML, and the World Wide Web
Two fundamental techniques for autogenerating web code are server-side scripting and client-
side scripting.
As you learn later in this hour, the collection of plug-in and add-on applications running on the
client system add another dimension to the activities that can be triggered from a web page. For
more about advanced web techniques see Hour 18, “Web Services.”
Most of these technologies are actually programming topics. The end user doesn’t really have
to know whether the image or table embedded in a web page comes from a static callout or a
script. However, a brief introduction to some of the concepts will provide some insights on how
HTML is used on today’s Internet.
Server-Side Scripting
Server-side scripting lets the server accept input from the client and process that input behind the
scenes. A common server-side scripting scenario is shown in Figure 17.5. The process is as follows:
1. The user browses to a page that includes a form for purchasing a product or entering visitor
information.
2. The server generates the form based on user choices and transmits the form to the browser.
3. The user enters the necessary information into the form, and the browser transmits the
form back to the server. (Note that the HTML form feature reverses the usual process. The
browser sends content to the server at the server’s request.)
4. The server accepts the data from the browser and uses a programming interface to pass
the data to programs that process the user information. If the user is purchasing a product,
these behind-the-scenes programs may check credit card information or send a shipment
order to the mail room. If the user is adding his name to a mailing list or joining a restricted
online site, a program may add the user information to a database.
Completed
Form
Form
Web
Server
Data
Server Request
Script
Scripting
Interface
FIGURE 17.5
A server-side scripting scenario.
Scripting 343
Several programming languages and environments have evolved to help developers build
server-based web applications. One method for interfacing a program or script with a web page
is through the Common Gateway Interface (CGI). CGI was developed to accept form-based
input from a web user, process that input, and then generate output in the form of HTML. CGI
scripts are commonly written in the Perl language, but CGI is compatible with other languages,
including C.
PHP is also becoming increasingly popular as a language for web development. A simple PHP
script is often embedded within an HTML tag:
Or defined using the
A web server that supports PHP parses and executes the code between the brackets, inserting the
output of the PHP command set in place of the tag as the page is delivered to the client.
Microsoft’s Active Server Page (ASP) and the later ASP.NET technologies are also popular server-
side web techniques. The concept of a web interface to a custom, server-side application has led
to a whole paradigm for programming known as the web services environment. Many of the
leading hardware and software vendors, including IBM, Microsoft, and others, have developed
sophisticated infrastructures to support web service programming.
Client-Side Scripting
Another way to integrate scripts with the web environment is on the client side (that is, on the
local client computer system that is running the web browser application). Whereas a server-side
script is executed on the server and the output of the script is embedded in the page, a client-side
solution transfers the embedded script along with the rest of the HTML code and text, and the
script is executed by the browser.
JavaScript and VBScript are two common client-side scripting technologies. The script file is often
referenced through the HTML:
The tag can reference the actual instructions, or it can refer to an external file containing the
code. In either case, this technique only works if the client computer includes support for the
scripting language referenced in the code.
For certain types of applications, client-side scripting is a more efficient alternative. An
interpreter executing the script on the client has a much more detailed view of the local
environment. Also, confining interactive elements to the client reduces network traffic and
improves performance.
344 HOUR 17: HTTP, HTML, and the World Wide Web
AJAX (which is sometimes billed as an acronym for Asynchronous JavaScript and XML) is a collection
of technologies that use client-side scripting to provide for seamless update of web content
without a full refresh of the web page. Other common client-side techniques offer interactive
options for the user, invoke animations or other multimedia effects, or respond to information
on the state of the client system.
Client-side scripting is extremely common, but as you can imagine, it poses some security challenges.
What intruder would not love the chance to execute code on the client system? Most
systems now take measures to restrict the privileges of code executing on the browser, and, as
you will learn in the next section, users have some freedom to limit the use of browser-launched
scripts. As is often the case with network-related software, the best precaution is often to keep
your system up to date and install security patches whenever they are available.
Web Browsers
As you probably already know, the whole business of the World Wide Web depends on a very
special and versatile application known as a web browser. In the client-server model discussed
earlier in this book, the web browser is the client. Early, simple browsers originally just rendered
the early, simple, static HTML files discussed in earlier hours. When web data arrived from
the server, browsers interpreted the tags, formatting the text with the specified fonts, links,
and photos.
As web data became more complex, the web browser evolved with it, and as the web became
the center of Internet commercial activity, the browser became a major source of competition
and corporate leverage among leading software companies in an era that is now known as
the “browser wars.”
Why declare a war over browsers, which have no market value in their own right and are
mostly given away as free software (either bundled with the OS or downloadable at no charge)?
Big companies like Microsoft and Netscape (and later Google) knew that by controlling the
browser they could control a whole range of technologies surrounding Internet activity, not just
web servers but also the lucrative and influential business of providing development tools and
application programming interfaces (APIs) that interact with the operating system.
At one point, Microsoft even said it had embedded its browser Internet Explorer into the
operating system itself in a way that could not be separated (an argument that was later rejected
by the courts). Microsoft wanted to extend its control of the OS market to control of the browser
market so that they could control the development environment and build pathways back into
the operating system to ensure the continued dominance of their OS projects.
From the user’s perspective, the browser is the focal point for everything that happens on
today’s Internet. The purpose of the HTML and HTTP standards is to ensure that any standard-
compliant browser can communicate with any standard-compliant server. However,
the big vendors have a tendency to use the standard as a minimum and to add their own
Web Browsers 345
enhancements, which has the same effect of locking in the user who has invested in building
custom tools for a proprietary development environment. Microsoft was forced through legal
action to open its APIs, which has largely addressed this issue. To fully participate in today’s
Internet, a browser must support the client-side scripting described earlier in this hour through
support for JavaScript or some other scripting technology. Depending on the browser and
system, this support might take the form of a browser plug-in or add-on or it might be implemented
through the operating system. A full-featured browser also must provide support for
digital signatures and certificates to allow the user to engage in secure transactions and communication
through Secure Sockets Layer/Transport Layer Security (SSL/TLS) encryption with
Hypertext Transfer Protocol Secure (HTTPS).
Modern browsers can launch other applications if necessary to open files or execute procedures.
Using other applications for these extended capabilities keeps the browser itself from getting too
big and cumbersome, and it allows application developers to concentrate on their own area of
specialty. These external applications are typically referred to as add-ons, plug-ins, or helper
applications.
Browsers are often smart enough to recognize a missing plug-in and ask whether you want to
install it if it is needed to open a file or start a video. Most browsers also provide a means for
manually adding, removing, and managing the plug-ins included within the configuration
(Figure 17.6).
FIGURE 17.6
Managing add-ons in Microsoft’s classic Internet Explorer browser.
Classic examples of browser plug-ins are Adobe tools such as the Acrobat reader and the Flash
player. When a browser encounters a reference to a link or reference to a PDF file, it calls the
appropriate Acrobat plug-in to open the file and displays the contents in a browser window.
346 HOUR 17: HTTP, HTML, and the World Wide Web
Some plug-ins provide other forms of extensions and enhanced capabilities. For instance, Firefox
provides an extensive collection of add-ons for alerts, social networking, and privacy (see Figure 17.7).
FIGURE 17.7
Firefox offers add-ons for social networking, privacy, alerts, and other uses.
The recent HTML5 standard, described later in this hour, has reduced the importance of certain
plug-ins such as Flash by offering direct support for video codecs within the browser.
The other critical component of browser configuration, in addition to extending what the browser
can do, is limiting what the browser can do. With new threats appearing on the Internet every day,
and old threats continuing to succeed despite the continuing efforts of the authorities, the security
configuration becomes an important aspect of the browser environment. Most browsers provide
a means for defining the security settings for web activities, in essence to “turn on” or “turn off”
certain capabilities depending on level of trust for the source and the level of privacy and security
required for the user environment. Internet Explorer provides a sliding scale of Internet security
levels, offering varying levels of control over scripts, ActiveX controls, and other elements that
might appear on a website (see Figure 17.8). The new Microsoft Edge browser appears to have a
more limited range of onboard security controls at this writing; however, supporting tools such as
Windows Defender and Group Policy replace some of this functionality. In the simplified world of
Mac OS, the Safari browser offers a means for enabling and disabling Java and JavaScript, blocking
pop-ups, and configuring other aspects of the security environment. Choose Preferences in the
Safari menu and select the Security option to configure Safari security settings (see Figure 17.9).
Firefox, Chrome, Opera, and other browsers offer similar features. Many browsers also let the user
predefine a list of trusted sites that are allowed to operate with fewer security restrictions.
Web Browsers 347
FIGURE 17.8
Most browsers have a way to fine-tune the security level. A more secure browser is safer, but a high security
setting can block legitimate web activity.
FIGURE 17.9
Safari’s simpler interface lets you enable JavaScript and define a cookie policy.
348 HOUR 17: HTTP, HTML, and the World Wide Web
The Semantic Web
An interesting area of research that truly might cause another Internet revolution is an ambitious
concept known as the Semantic Web. The Semantic Web, which has the full support and
advocacy of World Wide Web creator Tim Berners-Lee, is designed as a universal technique for
linking web data with real semantic meaning as a human understands it. In other words, the
goal is to somehow encode the meaning of web information in a way that is easily accessed and
processed by a computer.
To understand the purpose of the Semantic Web, one must start with some sense of how little
knowledge is truly present on a web page. For instance, consider the following lines of text,
which might be present at a typical website:
A Streetcar Named Desire
Lawrence Community Theater
Saturday, October 12, 2016
7:30 PM
A human who looks at this text knows immediately that it is a notice of an event that will occur
at the Lawrence Community Theater at 7:30 on October 12. Many readers will also recognize the
name A Streetcar Named Desire as a famous play, but those who don’t recognize the title will still
infer that the event is a play or movie because it is associated with a theater.
A computer, on the other hand, will just read those lines as alphanumeric text. The computer
doesn’t really know anything about the meaning of the text. It doesn’t know what a theater is,
and it doesn’t know that the third line is a date unless you specifically tell it so. For that matter,
a search engine might even call up this page for a user who is searching for a streetcar schedule.
The tools of the Semantic Web will one day help the web developer encode semantic information
so that an automated process will know that this page is about a play and not about a ticket for
a tram ride. Because this semantic information will be encoded along with the page itself, the
creator of the site won’t need any advance knowledge of how the reader will use the information.
Anyone can come along later and create a tool that searches for information on plays, and
the tool will find the notice of this play. Different websites can present the information differently,
with no standard format or style, and the play finder application will still find the plays—as
long as the semantic information defines the meaning of the text.
Resource Description Framework
Semantic Web techniques are still experimental, although several strategies have appeared in
the publications of the World Wide Web Consortium (W3C). One semantic tool that has received
considerable attention in the web community is called the Resource Description Framework
(RDF). RDF is a framework for expressing relationships that give an indication of meaning.
The Semantic Web 349
The fundamental unit of RDF is a statement consisting of three parts, which is called a triple in
RDF parlance. A triple is structured like a basic sentence, which has a subject, a predicate, and
an object.
For instance, in the sentence “The play has the title A Streetcar Named Desire,” the subject is
“The play,” the object is “A Streetcar Named Desire,” and the predicate is “has the title.”
RDF triples can take on several forms, but the idea is that each element is expressed as a URI,
and the URIs are concatenated in a colon-separated list. The Dublin Core Metadata Initiative
maintains a database of standard predicates referenced in RDF triples. For instance, the
following callout refers to the predicate “has the title”:
RDF and other Semantic Web techniques might someday lead to smarter search tools.
Microformats
RDFs are an extremely powerful tool for adding meaning to text; however, a fierce debate is
going on within the Internet community over whether the RDF concept is too complex and too
much effort to fit in with the methods of ordinary web developers. An alternative approach,
which is less ambitious but, most likely, more manageable and accessible for working web professionals,
is microformats.
Unlike RDFs, microformats do not attempt to represent complete sentence structures and
syntactic constructs. The goal of a microformat is simply to flag a section of text to associate it
with a predefined meaning, so that a browser or other web application that visits the site will
get a clue about the purpose of the text.
Microformats are not part of any official Internet specification, although the practice relies on
the existing tags and concepts underpinning HTML. The microformat community has arisen
independently, partly under the sponsorship of the nonprofit CommerceNet, which is interested
in promoting opportunities for Internet commerce.
A microformat is a specific vocabulary of name/value pairs designed to serve a specific purpose.
Microformat vocabularies have been developed for uses such as the following:
calendars (hCalendar)
business cards (hCard)
recipes (hRecipe)
copyright information (rel-license}
When a block of text is associated with a microformat (such as a resume, which can be identified
with the hResume microformat) the surrounding text elements can then be associated with
the various elements that make up a resume (such as experience, skill, affiliations, publications).
350 HOUR 17: HTTP, HTML, and the World Wide Web
Perhaps the most common microformat in use today is the hCard microformat, which is used
for business cards. hCard is a later incarnation of the vCard format, a MIME type originally
described in RFC 2426 and updated in RFC 6351 and other RFCs.
A simple example of HTML data tagged with the hCard microformat is as follows:
Of course, other settings are also available for specifying a street address and email address, as
well as to specify whether the telephone number is a home, work, cell, or fax number. If text on
a web page is tagged with these hCard settings, a browser that arrives at the site immediately
knows how to treat the information. Microformat-aware browsers automatically format the data
as a business card.
See the microformats.org website for more on the microformats movement, including specifications
for specific microformats and even some tools that automatically generate microformat
data. As you learn later in this hour, a similar concept known as microdata is now in the official
Internet lexicon with the arrival of HTML5.
XHTML
Many tools of the new Web, as well as many other websites on today’s Internet, rely on another
development that is quite technical for the purposes of this hour but is nevertheless worth mentioning.
The XHTML standard is an effort to bridge between old-fashioned HTML and the realities of the
XML-based web environment. (See Hour 18, “Web Services,” for more about XML.) XHTML is essentially
a formulation of HTML functionality that conforms to XML syntax. The XHTML format provides
all the expressive power of HTML within the machine-readable confines of an XML schema.
Although the concepts of XHTML are similar to HTML, XHTML is much more finicky about
sloppy or nonstandard coding practice. Certain declarations occur differently, or more formally,
and the nesting of tags must be more structured and precise. The goal of expressing HTML as an
XML schema is to provide flexibility for developers building scripts and other programs that generate
and interpret the code. XHTML also lends itself more readily to dynamic interpretation or
modification by the receiving entity. For instance, the small screen of a mobile device might not
be able to display a standard HTML page as specified, but a client-side application receiving the
page as XHTML could readily modify the text for the smaller screen.
Many believe the emergence of HTML5 (described in the next section) reduces the importance
of XHTML.
HTML5 351
HTML5
One of the most important changes taking place on the Internet today is the adoption of a new
HTML standard. HTML5 has been in discussion for several years, and it is finally making its way
to the practical side of the everyday Internet.
One who looks at the HTML5 feature list will see that many of its traits reflect the new role of
HTML as a tool for building the mobile revolution. The HTML5 standard includes many features
designed to support web browsing from mobile devices. However, other features simply reflect a
further evolution of the web environment, and incorporate functionality once provided by add-
ons and extensions directly into the HTML.
New important new features of HTML5 include the following:
Local storage and offline application support
Drawing
Embedded audio and video
Geolocation
Semantic elements
The following sections describe these important new developments in HTML5. The HTML5 standard
also includes other improvements, such as a drag-and-drop API and improved support for
forms. In many ways, HTML5 marks the further evolution of HTML to something more like a
development environment for web applications. Developers have long used HTML and its surrounding
technologies to build web-based client/server applications, but much of the functionality
required additional components and third-party extensions. HTML5 builds more of the functionality
directly into the HTML. In the rapidly evolving world of mobile device programming,
developers have begun to use HTML5 to build cross-platform mobile applications that will run
on Android, iPhone, and other platforms with only minor modifications.
Of course, the adoption of the HTML5 standard by a standards committee doesn’t guarantee its
adoption by the larger Internet community. Several popular browsers already provide HTML5
support, and web servers are also getting connected with the newest HTML. However, until web
developers start building ordinary web pages that incorporate HTML5 elements, you won’t see
the benefits of HTML5 in your everyday web surfing experience.
HTML5 Local Storage and Offline Application Support
A cookie is a small bundle of persistent data stored on the remote client system by the web
server. Cookies have been part of the web scene for years, and you’ll find configuration options
in most web browsers that let you manage how cookies are stored and saved. Web servers
352 HOUR 17: HTTP, HTML, and the World Wide Web
use cookies to restore a previous application state or save information on the user’s previous
activities. Cookies are a very useful tool that most web developers (and most web users) are
familiar with; however, they have some limitations. The cookie’s storage size of 4 KB is barely
enough room for a few basic bits of data about the user and session history, but today’s web
programmers see the need for much more local storage.
HTML5 comes with a local storage feature that greatly expands and enhances how web browsers
can store and retrieve information on the local system. HTML5 storage (which is also called
web storage or DOM storage) lets the browser store values for settings defined within the web
application. This local storage provides a number of benefits. For instance, a script executing on
the client side can stash temporary results in the storage area, thus improving performance by
reducing the need for communication with the server over the network. The storage space can
also save a more complete view of the current session state, so that a web-based game or other
interactive application can be restored (and, in some cases, keep operating temporarily) if the
server crashes or the connection is lost.
The local storage capabilities of HTML5 lead to another important improvement: offline
application support. A web browser that supports the offline application feature can keep going
when the network is disconnected.
As shown in Figure 17.10, a web application that supports offline processing includes a cache
manifest, which names the files and other resources required for operating offline. When the
browser first connects to the website, the files provided in the cache manifest are downloaded
to the client system.
Cache
Manifest
Web Client Web Server
FIGURE 17.10
The cache manifest lists the resources necessary for offline processing. The client downloads the required
files and can therefore operate even when the connection is lost.
HTML5 353
When the network is inaccessible, the web application still operates through the offline versions
of the files listed in the cache manifest. This might not sound so impressive at a glance. (Of
course, every application works if all the files it accesses are present on the system.) The problem
is that the files downloaded to the client will soon become out-of-date. However, the interesting
part of the HTML5 offline application feature is that the browser system automatically updates
the files on the local system when the connection is restored and saves all offline changes back
to the server. Thus, the files referenced in the cache manifest stand a better chance of being
current at the time the system goes offline, and the client seamlessly synchronizes its changes
through the restored connection without additional effort by the user.
HTML5’s offline storage feature could also have some disadvantages. As you will learn in Hour 19,
cookies provide a means for advertisers and content providers to track user habits and activities.
By expanding the possibilities for a vendor to store cookie-like information, offline storage could
potentially lead to additional privacy concerns.
HTML5 Drawing
Internet users are accustomed to seeing image files with photographs and diagrams embedded in
web pages. This technique of embedding graphic images greatly enhances the power and beauty
of the Web. However, web designers and developers want more from their pages, including the
ability to draw images programmatically or create small animations that will unfold while the
user is watching. Previous HTML versions add this functionality through third-party add-on
tools, such as Adobe Flash.
HTML5 rolls out its own drawing capabilities through a pair of important new elements: the
tags for headings, the
The Easy and Hard of HTML
Webster's Dictionary defines HTML as "a small snail found originally in the Canary Islands and ranging now to the Archipelago of Parakeets." I borrow from this theme in my consideration of HTML as a language that is both easy and hard.
HTML is Easy
336 HOUR 17: HTTP, HTML, and the World Wide WebHTML is easy to learn and use because everyone reacts to it energetically. You can walk into a bar and start speaking HTML, and the man beside you will happily tell you his many accomplishments.
HTML is Hard
HTML is hard because the options are bewildering. You never know when to use small text and when to use big text.
TABLE 17.2 HTML Tag Attributes size Relative font size setting. Values vary from 1 to 7: . lang Language code denoting the language in which the text is written. face Typeface setting: . color Color of the text: . The preceding example appears in the browser as shown in Figure 17.4. FIGURE 17.4 Expanding the easy example. As you learned earlier in this hour, the hypertext link is an important element of web design. A link is a reference to another document or another part of the current document. If the user clicks the text of the link, the browser immediately opens the document referenced in the link. The effect is that the user appears to lilt through an endless garden of colorful and informative content. Cascading Style Sheets 337 BY THE WAY What is a Browser? As you lilt through this colorful garden, pause occasionally to consider that the term browser originally referred to a giraffe or a large dinosaur eating leaves out of trees. A link appears in the HTML file as a tag. The simplest form of a link uses the tag with the URL of the link destination given as a value for the HREF attribute. For instance, in the preceding example, if you would like the words “Archipelago of Parakeets” to appear as hypertext with a link to a website that tells about the archipelago, enclose the words within tags as follows: ranging now to the Archipelago of Parakeets. I borrow from this theme The versatile HTML format includes many additional options. You can place a hotspot link inside a picture. You can create your own style sheets with special tags for preformatted paragraph styles. You can structure the web page with tables, columns, forms, and frames. Or you can add radio buttons, check boxes, and pull-down menus. In the early days of HTML, designers coded all the HTML directly into their documents using text editors (as described in the preceding examples). Professional web designers now work with special web development applications, such as Adobe Dreamweaver, that hide the details of HTML and let the designer view the page as it will appear to the user. New tools such as wikis and content management systems (CMSs) provide additional options for effortless web design. Static, preformed HTML documents like those described in this section are still widely used, but many websites today use dynamic HTML techniques to generate the web content at the time of the request. BY THE WAY Capitalization With classic HTML tags, capitalization is not significant; however, later standards such as Extensible Markup Language (XML) and XHTML pay more attention to capitalization. XML is case sensitive, and XHTML requires lowercase element and attribute names. Cascading Style Sheets Although it is possible to encode all formatting instructions into an HTML document (fonts, font sizes, line types, etc.), in practice, repeating the same tags over and over for the same few style elements is cumbersome. Perhaps more importantly, on-the-fly modifications can lead to inconsistency and an unpolished, overly complicated design. 338 HOUR 17: HTTP, HTML, and the World Wide Web A better approach is to define standard style elements for the document and put them in one place, then reference those elements in the text. Researchers at the World Wide Web consortium developed Cascading Style Sheets (CSS) as a way to corral style information in a single document. The goal is to make HTML more like a modern word processor or desktop publishing tool, which lets you pick from a list of predefined character or paragraph styles. The style defines a set of parameters, such as the font size, color, spacing, padding, and margins. Using a CSS separates the document contents from the presentation information. This approach makes the HTML much easier to read, and it imposes a stylistic consistency on the document, which is considered good design practice. For example, a heading style might be defined as follows in the CSS document: h1 { Color: black; Font-family: Arial, sans-serif; Margin: 0 4px 0 0; } As you can see, the definition consists of colon-separated attributes and values. The items in the list are separated with semicolons, and the whole style block is enclosed in {}. The actual callout for the heading in the HTML document then just has to refer to the style: