TT284 Web Technologies
Block 1, Part 1: A brief history of
the internet
Doug Briggs
Copyright ã 2011 The Open University
WEB 03088 8
1.1
Block 1: Basic web technologies
Part 1 - A brief history of the
internet
Contents
1 Introduction
2
3
4
5
Learning outcomes
The internet and the Web: a brief history
Web applications
Client–server architecture
7
9
10
12
13
5.1 Static web content
13
5.2 Dynamic web content
14
6 A simple client–server model
7 Two simple client-server models
8 Web addresses
16
17
19
8.1 Domain name system
19
8.2 ‘Request’ and ‘response’
8.3 The GET request
20
20
8.4 The OK response
20
9 ‘Warriors of the Net’
10 The need for speed – downloading web content
10.1 A simple download calculation for digital resources
11 The W3C and standards
11.1 The International World Wide Web Consortium
11.2 The expanding work of the W3C
12 Summary
13 References
Where next
22
23
23
26
26
27
28
29
30
1 Introduction
1 Introduction
The internet and the World Wide Web have grown rapidly to become
powerful tools supporting the development of information delivery systems.
You can shop online, search for a new house or car, bid at an auction, book
a holiday, pay bills, buy stocks and shares and even submit your tax return
(Figure 1). You can take a virtual tour through an art gallery or a historic
building. You can email family, friends and business colleagues, engage in
social networking, or pay your road tax. The internet can be used to make
Figure 1 The web provides a variety of services
phone calls or play games ‘online’ and ‘live’ in real-time with other players.
The internet allows us to connect in so many different ways. All these
activities have in common the delivery, presentation and exchange of
information and whenever we visit a website we are engaging with some
sort of web application.
You can do all this from, for example, a desktop PC, a mobile phone or a
tablet – with many different devices and many different user agents (or
browsers) which means that the role of standards for delivering that content
on demand becomes the cornerstone for making all that possible.
This week we will look at the history of the internet and we shall provide a
context for the protocols, the web technologies and standards that have
made the rapid growth of the internet possible.
7
Block 1: Basic web technologies
Part 1 - A brief history of the internet
For this part of Block 1
This week you will be provided with a number of resources to support
your study and to give you a basic understanding of how the Web
actually works.
We will be looking at the original proposal by Tim Berners-Lee for a
network of interconnected computers exchanging documents on a web
and we’ll examine how that elegant idea informs what we recognise as
the Web today.
You will watch:
Warriors of the Net movie
This animated sequence is well worth watching and should help with
some of the more technical aspects of transferring data across a
network.
It would now make sense to create a work folder for your TT284
resources and activities for the rest of the module.
8
2 Learning outcomes
2 Learning outcomes
This week we shall provide the context for this block of the module by
looking into some of the broad issues regarding the development of
applications for the internet and the Web.
On successfully completing this week’s study you should have achieved the
following learning outcomes:
be able to understand the history of the Web and the impact of standards
and protocols on the deployment of web-distributed applications
have some understanding and be able to explain the basic modes of
operation of the client–server model of the Web and the associated
protocols, including HTTP
be able to discuss the role of standards for developing web applications
be able to explain the concepts of ‘usability’ and ‘accessibility’ in
delivering web content.
9
Block 1: Basic web technologies
Part 1 - A brief history of the internet
3 The internet and the Web: a brief
history
The Web is a beautifully simple idea made possible by two distinct
technologies: interconnected computer networks and data exchange
protocols.
The interconnected computer networks are what we refer to as the internet,
and are the result of research work that was carried out for the US
Department of Defense in the late 1960s. The Advanced Research Projects
Agency Network (ARPANet) project of 1969 was aimed at creating
computer networks that would be resistant to failure. It led to the creation of
the Transmission Control Protocol and the Internet Protocol, or you might be
more familiar with the term TCP/IP. These two protocols now underpin all
the everyday services of the internet, such as email, the Web, FTP,
newsgroups, Web 2 technologies, and so on.
The second part of the story was the development of a protocol to support
the exchange of electronic documents (the Hypertext Transfer Protocol
(HTTP)) and a document mark-up language (the Hypertext Mark-up
Language (HTML)), both of which are accredited to Tim Berners-Lee, a
British scientist working at CERN who was looking for a means to distribute
information across the CERN network. HTTP provided the means for a user
to request a document on another computer and have a web server respond
to that request and deliver the content.
HTML, on the other hand, provided the ability to annotate a simple text
document so as to represent structural, presentational and semantic
information. A user could define headings and paragraphs, and embed
images or even clickable links to other documents (the hyperlinks) and this
was irrespective of the hardware or operating system of the different users.
In creating deliverable content over a network and in developing these key
elements, Tim Berners-Lee had created an internet-based solution for global
information sharing. The term he coined for this was the ‘World Wide Web’.
Tim Berners-Lee’s original proposal can be found at: http://www.w3.org/
History/1989/proposal.html
You can see from this research proposal that a simple solution was created to
allow people to be able to share structured content between different users
and devices within an organisation and Tim Berners-Lee proposed a ‘“web”
of notes with links (like references) between them’ (Berners-Lee, 1989). In
effect this and the device interdependency was the internet in a microcosm;
an idea that was to spill out to the wider world and inform the internet as we
now know it.
Today, the two ideas encapsulated in that original proposal are looked after
by two different standards bodies. HTML and other subsequent presentation
languages (such as CSS through to SVG, Ajax, XML and XSLT) are
controlled by the W3C (the World Wide Web Consortium) whereas HTTP
and the ‘transportation’ protocols are controlled by the IETF (Internet
Engineering Task Force).
10
3 The internet and the Web: a brief history
You can find out more about the work of the W3C via the following FAQs:
http://www.w3.org/standards/faq.html
In addition to the W3C we have also referenced the IETF who look after the
transportation of data – the protocols for data transfer. It is the mission of
the IETF ’to make the Internet work better by producing high quality,
relevant technical documents that influence the way people design, use, and
manage the Internet’ (IETF, 2011).
You can find out more about the IETF and the technologies and protocols
they control at: http://www.ietf.org/about/
In the following sections we shall examine in a little more detail what we
mean by ‘web applications’, and we shall introduce the concept of the
client–server model for the delivery of content from one computer to others.
11
Block 1: Basic web technologies
Part 1 - A brief history of the internet
4 Web applications
In this module we will talk a lot about web applications, but what exactly
does this mean? What is a web application? There are a number of features
that are shared by all web applications, and I shall outline these below.
First and foremost, a web application fulfils the notion of some form of
business requirement. What is meant by that is that any company,
organisation or individual going to the expense or trouble of developing,
testing, deploying and maintaining a web application must have in mind
some function or purpose in mind. It is that purpose that I shall call the
business requirement of the site.
Many websites provide a means to distribute information to the public,
whilst others allow customers to purchase goods or services, bid at auctions,
manage their finances, exchange messages, and so on.
For one company the web application fulfils the requirement to distribute
information to potential customers, and it replaces or reduces the need to
distribute information in other forms. For another, an online shopping
application might allow a company to expand its customer base without the
expense of opening ‘bricks and mortar’ shops. These savings are not
insignificant, as many high street retailers have discovered. The internet has
transformed how many businesses conduct their business.
Many companies now use the same internet and web technologies to support
internal processes on their intranet, such as reporting sales, supporting
project teams, logging interactions with customers or just submitting their
expense claims.
So another of the key features of a web application is in the use of internet
and web technologies, by which I mean the use of the published standards
and recommendations related to the communication protocols and the design
and software products.
Every computer or connected device now comes with some form of web
browser or app, and with internet connectivity, so designing applications that
use these items means that I don’t have to distribute software to every user,
or teach them how to use it.
So, if we are running a business and the customers use devices that can
connect to the internet, be they PCs or mobile devices, then we consider
these users with their user agents (or browsers) to be clients. The web
applications on our servers are accessed through their browsers and delivered
to their devices.
This brings us into the territory of the architecture or ‘structure’ of the Web
and moves us neatly toward the idea of the client–server model for the
distribution and exchange of information.
12
5 Client–server architecture
5 Client–server architecture
All web applications split the computing workload between a user’s browser
processing and displaying data on their PC or device and a remote ‘web’
server that provides content. The user requesting via their browser a web
application from the server is referred to as the ‘client’ (sometimes called the
front-end) and can be located just about anywhere in the world. The web
‘server’ (or back end) consists of special software loaded onto a special
computer known as a ‘server’ and it is this computer that responds to
requests for ‘pages’ of content. In this way, the Web is an example of a
client–server architecture or distributed architecture.
Web applications should be ‘standards-compliant’, in that they should
comply with the various recommendations and standards published by bodies
such as the W3C and the IETF. These recommendations and standards define
the various protocols used for exchanging data and the mark-up languages
used to display content.
Without compliance with these standards and protocols for data retrieval, the
internet simply wouldn’t work.
Just as important are the recommendations and standards that help to ensure
that web applications are both usable (i.e. that user interfaces should be both
intuitive and unambiguous and therefore ‘usable’ by all users) and they must
also be accessible to disadvantaged users. There is a legal requirement to
enable accessibility for disadvantaged users in many countries (http://www.
w3.org/WAI/Policy/) that must be satisfied, such as in the UK the
Disability Discrimination Act 1995 (and amendments in 2004) and the
Special Educational Needs and Disability Act 2001. As yet in the UK the
case law is untested, but in Australia a successful case was brought against
the Sydney Organising Committee for the Olympic Games in 2000
(AHRC, 2000). In the mission of the W3C of Web for All (http://www.w3.
org/Consortium/mission.html), accessibility is seen as an important
design consideration when developing web content and the W3C have
created the Web Content Accessibility Guidelines for developers creating
web services or content (http://www.w3.org/WAI/intro/wcag).
So, to summarise, a web application:
.
fulfils some form of ‘business’ requirement
.
is built using internet and web technologies and protocols
.
employs a distributed architecture
.
is standards-compliant
.
should be usable
.
should be accessible.
5.1 Static web content
Web applications vary enormously in terms of their size and complexity. At
the least complex level they may involve the delivery of information such
that every user receives the same content. In such cases the design takes no
13
Block 1: Basic web technologies
Part 1 - A brief history of the internet
account of who you are, when you visit or where you live. Such applications
are said to deliver ‘static content’ and are used primarily for information
distribution.
5.2 Dynamic web content
At the other end of the complexity scale are the web applications such as
online shopping sites of the national supermarkets, which allow users to
purchase items for home delivery. A supermarket may carry in excess of
65 000 items and have thousands of simultaneous users, but their web
application must be able to track every item purchased by every individual
user. Such a web application is said to deliver ‘dynamic content’ – that is
content that is personalised to the user and is responsive to the individual
choices made by that user.
In terms of size, one web server may host hundreds of personal ‘websites’,
such as those offered by an ISP to its subscribers, or one application may
require several thousand servers. In 2011 at the time of writing this block,
Facebook, the global networking site, is reported to have 500 million active
users, with in excess of 900 million digital objects (http://www.facebook.
com/press/info.php?statistics).
One of the main challenges for the web application designer, as opposed to
one who creates ‘self-standing’ desktop software, is to deliver as rich,
functional and responsive an application as possible, but those requirements
are balanced against a simplicity of delivery that has allowed the rapid and
continual expansion of the Web. Recent examples include Google Maps and
applications that allow large numbers of internet users to create their own
online journals, or personal ‘blogs’.
Part of the role of a web application developer is to ensure that content
appears quickly and that users can find what they are looking for. If we can
test to some degree how quickly our web pages will be delivered to a user’s
browser over different connections then we have some idea about how to
create the page.
The web applications we create must be delivered and tested to a schedule,
and must be constructed in such a way that they can be maintained and
expanded as and when required. With mobile phone technology now
including web access as standard, scalability of any web application for
increased demand is also an important design consideration.
A web application may also require that we keep track of individual users as
they move from one page to another, to store data about purchases they
make, and ensure the security of personal information provided during such
transactions.
14
5 Client–server architecture
Activity 1 What makes one website better than another?
As you navigate the Web, you find that some experiences are better than
others. So what is it that makes one website a better experience than
another? One factor often quoted is the time taken for the ‘page’ to
download. Another is the usability of the site: how easy it is for the user to
find their way around and locate the information they want.
Find a small number of examples of websites that you consider to be intuitive
and ‘usable’ and find a small number that you consider are not and do not
contribute toward ‘good web design’. Discuss these in the TT284 Themes
Forum for this block.
15
Block 1: Basic web technologies
Part 1 - A brief history of the internet
6 A simple client–server model
If you read the literature related to web application development you will
encounter numerous ‘models’ that make various claims about offering
quicker and better, systematic or team-based web development procedures.
All these models provide a framework for creating web applications in a
structured way that allow us to employ good management during the
development process. For this block, I shall focus on the delivery of such
applications through the often quoted client–server model. If you can
understand this simple model, then more complex models have their
foundations seated in the transactions that I shall describe.
The term ‘client–server’ was first used in the 1980s to describe how PCs on
a network exchanged information with one another. By the turn of that
decade the simple client–server model had come into common usage to
describe how the internet works.
We’ve already touched a little on the idea of a ‘client’ and a ‘server’. In the
model, a client is defined as a requester of services and a ‘server’ (including
a web server) is defined as the provider of services. We can think of a client
quite simply as a user with a browser-enabled device (such as a PC running
Firefox) connected to the internet, and a server as a computer connected to
the internet that contains some digital content that can be requested and
despatched to the client. There is a transaction from client to server called a
request and a response.
So how exactly does that work?
16
7 Two simple client-server models
7 Two simple client-server models
Your browser interacts with other software on the ‘server’ at a remote
location. The browser interacts with the web server using a set of
instructions called protocols to transfer files or data from one machine to
another.
The model illustrated in Figure 2 reflects the classic client–server
configuration of the internet that is particularly suited for delivering simple
web pages.
Figure 2 Generic client–server configuration for web pages
All web activity begins on the client side (or at the user PC) when a user
starts his or her browser. The browser begins by loading a home page
document, either from local storage (known as a cache) or from a server
over some network. This request (and the server’s reply) is formatted
according to the dictates of the HTTP standard.
Figure 3 illustrates the client–server model particularly suited to dynamic
web applications built around databases. Using this model the application
development process could be divided between specialists in HTML coding,
server scripting and programming, and database management.
Figure 3 Generic client–server configuration for web applications
So, the role of a server is to spend most of its time listening to the network
traffic and waiting for document requests containing that server’s unique
address. Upon receipt of a request, the server verifies that the requesting
browser is allowed to retrieve documents from the server and, if so, it then
checks for the requested document. If found, the server sends a response to
17
Block 1: Basic web technologies
Part 1 - A brief history of the internet
that request and it also delivers (downloads) the document and any
associated files to the browser.
As we shall see, the server usually logs the request, the client computer’s
name, the document requested and the time.
18
8 Web addresses
8 Web addresses
Each computer connected to the internet has a unique number, or ‘address’,
assigned to it.
These numbers are defined by the Internet Protocol (IP) standard which
defines how information is passed from one machine to another. An IP
address is currently made up of four numbers, each less than 256 and these
numbers are separated by full stops to produce a unique identifying number,
e.g. 196.66.152.28.
Whilst computers are more than capable of dealing in numbers, human
beings prefer names, and so for each IP address there is a corresponding
name assigned to the computer, which is chosen by its owner. These names
are held by computers known as ‘name servers’, which effectively match up
any unique IP address to the corresponding domain name.
The complete distributed database and the protocols for exchanging
messages between name servers and between name servers and clients are
called the domain name system.
8.1 Domain name system
With hundreds of millions of machines connected to the internet, it might be
considered problematic coming up with individual names, but because the
internet is a ‘network of networks’ it conveniently divides into groups
known as domains.
These domains are further divided into sub-domains and so on. So, in the
same way that a house name might be common with others within a postal
address, the address of your machine becomes unique when you append all
the domain names and sub-domain names related to that machine within the
network. The fully qualified domain name www.open.ac.uk points directly
to a unique server named ‘www’ in part of the domain known as ‘open’ in
the academic network ‘ac’ residing in the United Kingdom ‘uk’.
Note the W3C encourage meaningful domain names so that resources can be
easily identified and the structure used can be recognised in the URL, but
recently foreshortened versions of URLs have been introduced, such as
http://tinyurl.com/3bbc6g. These are generated by algorithms and usually for
social networking sites and web technologies such as Twitter where there is
a strict limit on the number of characters the technology can support – in the
case of Twitter it is 140 characters and a URL could eat into that allocation.
In such cases these foreshortened versions should be seen strictly as
convenient ways of passing on a shortcut to a web page, rather than
representing the domain name and location of the page itself. In such cases
you can think of these versions as shorthand rather than the norm.
19
Block 1: Basic web technologies
Part 1 - A brief history of the internet
8.2 ‘Request’ and ‘response’
In thinking about a client and server scenario we rely wholly on
understanding the basics of HTTP and at the heart of it are two quite simple
elements that we’ve already touched on: these are the ‘request’ that is made
by your web browser and the ‘response’ you receive from the web server.
The process is that a browser will typically request a file of some sort and
that the server will either return the file or it will return a message indicating
why it can’t provide the file, or satisfy the request.
I will now take you briefly through these exchanges. There is no need for
you to go through all the details of the request and the response messages as
defined within HTTP. You can refer to RFC 2616 (http://www.faqs.org/
rfcs/rfc2616.html) for more detail.
What follows is a fairly typical ‘Client-Server’ handshake that shows
information exchanged between client and server and also results in the
delivery to your browser of the Open University’s home page.
8.3 The GET request
The default request from a web browser uses the GET method. You will
encounter this method later in this block when looking at exchanging data
via forms to web servers. Here, at its most simple – we are looking at a
basic request for a particular web page. The request is made up of three
parts: a request line, one or more ‘header’ lines, and a ‘body’ or payload.
Altogether this is sometimes referred to as an HTTP command.
The request that is sent to the server from a user entering a specific website
address into a browser is shown in the animation in Figure 4.
Figure 4 An animation of the GET request
We’ll look a little further at character sets later in this block.
What happens next occurs on the server side of the transaction.
8.4 The OK response
Once the data (the request using the GET method) has been received by the
server and assuming a successful transaction between the client and the
server, the server then creates and sends a response as shown in the
animation in Figure 5.
On receiving a GET message the server will first check that it can locate the
requested file. If it can then the next thing that happens is that it will check
that the user has permission to read the file. Finally it will create a response
message to send back to the browser.
20
8 Web addresses
Figure 5 An animation of the OK response
The ability to keep connections open for further use (using the ‘Connection’
header) was introduced in HTTP 1.1 as a means of reducing traffic over the
internet and speeding up the delivery of messages – remember that it takes a
small, but finite, amount of time to create a connection. The server only
needs to include this line if it will close the connection at the end of this
message.
There are many other headers that can be included in a response message,
but these are more than sufficient to understand the basic process of HTTP
(i.e. the request that is made – and the handshake that is returned to the user
to make a successful digital transaction from client to server and back again
across the internet).
If you find all this talk of requests and responses interesting then you can
further explore them and their nuances at http://www.w3.org/Protocols/
rfc2616/rfc2616-sec14.html. If you find it all rather confusing, then
perhaps it might help to think of these protocols as the means to support
exchanges between the user agent (browser) and the server as a sequence of
messages, rather like Twitter ‘tweets’ or short email messages addressed
between server and client. Some messages have an attachment (or body) and
some don’t.
21
Block 1: Basic web technologies
Part 1 - A brief history of the internet
9 ‘Warriors of the Net’
The internet supports an enormous number of services or technologies and
each with their own set of rules or ‘protocols’; these services are used every
day by millions of people.
Email and the Web are the most widely quoted, but just as important are
services for file transfer (FTP), news groups (NNTP), chat rooms (IRC),
address resolution (ARP), domain name system (DNS), Real Simple
Syndication (RSS) and so on.
All of these services utterly rely upon the Transport Control Protocol (TCP)
and the Internet Protocol (IP). Although you don’t need to know the details
of TCP and IP, it is helpful to have a basic understanding of these important
protocols and how they facilitate information flows across the internet.
Remember that in the late 1960s these protocols (or rules) maintained the
stability of transactions across networks and it is that stability that is still
provided today.
So, before reading any further you should now complete Activity 2.
Activity 2 The ‘Warriors of the Net’ Animation
Watch this animation. It is about 13 minutes long and is well worth watching,
even if you already have a good idea about how the internet works.
Warriors of the Net
A transcript of the narration has been provided should you find this more
accessible.
To view the transcript, click on the word ‘Transcript’ below the animation
screen.
I should point out that there are a few technical inaccuracies in the animation,
but for the purposes of this module we can ignore them.
What is clear from the animation is that there are two distinct technologies to
look at, and whilst the W3C represent the languages of the Web, it is the
IETF that represents the direction and the protocols and rules of how any
digital transactions are carried between the user and the server. It is both the
W3C and the IETF that control the open delivery of applications across
networks.
Or, put simply, these two bodies deliver what we want and when we want it in
terms of both standards and in terms of stability.
To learn more about the IETF, visit the IETF home page, http://www.ietf.org.
22
10 The need for speed – downloading web content
10 The need for speed –
downloading web content
At this point you should now have some idea of how the internet functions
through the IP, name servers and domain name systems. We have explored
requests and responses and I hope that the Warriors of the Net animation has
gone some way toward helping you visualise how information flows across
the internet.
In creating content for the Web another consideration when designing pages
is what has been termed the ‘World Wide Wait’, that is the response time
between a client requesting a page and that page and its content being
delivered.
Jakob Nielsen, who has conducted many usability studies, calls this ‘the
need for speed’ (http://www.useit.com/alertbox/9703a.html).
In other words, there is a recognised demand for quick and reliable
downloads and that means keeping your code as efficient as possible and
your file sizes as small as you can.
One way of checking this is to estimate how long it would take for a
selected set of resources to download to a user’s device.
So, how might we estimate download times for the content of a single static
page?
10.1 A simple download calculation for
digital resources
A crucial usability indicator is the time it takes to retrieve a resource across
a network. Assuming that the user is visiting a website with an average data
transmission rate of 56 kilobits per second (Kbps); consider the request for a
single web page comprising 6934 bytes of text (including HTML tags) and a
CSS file containing 2360 bytes, along with six images that form a navigation
panel used throughout the website, at an average size of 4034 bytes, and a
single image for the banner at a size of 20 849 bytes.
For the sake of this example we’ll assume that it takes the server 8
milliseconds to respond to each file request and we’ll ignore any delays due
to the transmission of packets across the internet. We’ll also assume that this
is your first visit to the site, so that none of the files have been stored in
your browser’s cache.
Note: 1 Kbps = 1000 bits/second, 1 byte = 8 bits.
i
Content to download:
HTML file is 6934 bytes
CSS file is 2360 bytes
Six images of 4034 bytes each = 24 204 bytes
Banner image is 20 849 bytes
23
Block 1: Basic web technologies
Part 1 - A brief history of the internet
Total content = 54 347 bytes
ii
The total file size in bits:
54 347 × 8 = 434 776 bits
iii
Download speed is expressed as kilobits per second (Kbps):
56 kilobits = 56 000 bps
iv
The transmission time of the nine files in seconds is calculated as
follows:
File size in bits/transmission speed in bps
434 776/56 000 = 7.763 seconds
v
The delay (in seconds) incurred by the server processing nine files is
calculated as follows:
8 ms x 9 = 0.072 seconds
vi Total time to download is the transmission time plus the delay:
7.763 + 0.072 seconds
= 7.835 seconds.
You’ll note from the above calculation that for static web pages the server
delay is trivial when compared with the delivery time of the content, so it is
important to keep code tidy and image file sizes to a minimum.
So, if we know the file sizes and the bandwidth speed we can estimate how
long it will take a user to receive their request for digital content.
Activity 3 Download time calculation
Assume that the user in the previous example above upgrades their internet
connection to an average data transmission rate of 220 kilobits per second
and without clearing the browser cache requests another web page from the
site comprising 8054 bytes of text and a new banner size 27 748 bytes. How
long would it take to download the page?
Answer
i
Content to download:
8054 bytes {HTML text} + 27748 bytes {banner image}
8054 bytes + 27 748 bytes = 35 802 bytes
ii
Convert the total file size from bytes into bits:
35 802 × 8 = 28 6416 bits
iii
Download speed is expressed as kilobits per second (Kbps):
220 000 bps
iv
Transmission time of the two files in seconds is calculated:
File size in bits/transmission speed in bps
286 416/220 000 = 1.302 seconds
v
The delay (in seconds) incurred by the server processing two files is:
8 ms × 2 = 0.016 seconds
vi
Total download time:
1.302 + 0.016 seconds
24
10 The need for speed – downloading web content
= 1.318 seconds.
Again, note that the server delay is trivial when compared to the delivery time
of the content, so for efficient delivery of web content it is important to keep
code tidy and image file sizes to a minimum.
25
Block 1: Basic web technologies
Part 1 - A brief history of the internet
11 The W3C and standards
11.1 The International World Wide Web
Consortium
I’ve touched on the role the W3C plays in developing standards and we’ve
seen Tim Berners-Lee’s original proposal for efficient document exchange at
CERN expand into what we know as the internet today. With all the network
technologies and protocols in place, the Web exists as a loosely organised
global collaboration of autonomous servers and browsers, supporting host-tohost communication through voluntary adherence to open standards defined
by the internet and the W3C. It is that compliance with standards with the
loose connection between different devices and different servers that
underpins the internet and illustrates its success.
That’s quite something to hold up. What keeps the internet expanding and
developing and stable is that standards are developed to keep up with the
demand for services and to ensure that developers for all web connectivity
create user agents that can read and interpret web standards and that can also
deliver content to the client device that will be accessible and usable to its
users.
I’ve looked at requests for content that are unsuccessful, either because the
permissions and security are denied, or because the request hits a dead-end.
There is little worse than a collapse of a request for data without a clear
response – where there are dead-ends or failed or broken links; clearly
delivering material and coding html to standard, and correctly maintaining
the content are so very important.
So, with the language of the Web and the appropriate exchange protocols in
place, then the Web should work perfectly.
Well, yes and no…
Historically, there have been times when a technology develops faster than
the standards body can respond – and in those times there have been issues
with accessibility. In the mid-1990s were the so-called ‘Browser Wars’ (a
term that refers to the need to gain dominance for one browser in the
marketplace creating their own non-standard mark-up tags). Mark-up had
become so loose that browsers such as Internet Explorer had to have the
ability to work in ‘quirks mode’ in order to interpret some of the code and
in some cases browsers couldn’t interpret the code at all. None of this was
good for the original vision of the Web. It is important that lessons are
learned from these experiences and developers continue to work with the
W3C, rather than independently. Clearly the W3C needed to take control of
web standards and that meant working closely with developers and bringing
them inside the organisation.
26
11 The W3C and standards
11.2 The expanding work of the W3C
With the support of developers the W3C has continued to expand and
develop and refine the standards for a range of mark-up languages for the
Web. With the Web diversifying at an ever-growing rate, it can be argued
that the role of the W3C is more important now than it has ever been.
From the first version of HTML (version 1.0) the standard has evolved
through a number of different versions to reach the final stable version of
HTML 4.1.
The W3C additionally has the wider responsibility of standardising any
technology related to the Web.
Among the many initiatives it continues to develop are standards for the
Cascading Style Sheets (CSS) a simple means of adding style to web
documents and Extensible Mark-up Language (XML) standards, as well as
related standards and recommendations for documents addressing on the
Web. In its spirit of openness it also solicits and encourages proposals for
extensions to existing web technologies.
The next implemented step is XHTML 1.0, the W3C version of HTML
which builds on the stability of HTML 4.01 and yet it is at the same time
XML-compliant.
As a side note: it should be noted that at the time of writing there is a
breakaway version of HTML from The Web Hypertext Application
Technology Working Group (WHATWG) called HTML 5. With the
emergence of HTML 5 we do see something akin to the Browser Wars of
the mid 1990s – there are reasons for the development of this outside the
W3C – but this is currently an organic version of HTML that attempts to
stay ahead of the development of the Web. Whilst the W3C are attempting
to stay connected with HTML 5, particularly in the context of developing for
mobile technologies it remains that the last stable standards-compliant
version of HTML is the XML-compliant version XHTML 1.0 and unless
stated otherwise that is the standard that this module will focus on.
27
Block 1: Basic web technologies
Part 1 - A brief history of the internet
12 Summary
This week we have looked at the internet and the Web and we have looked
at the standards and protocols that underpin the function of the Web.
I have introduced the client–server model for the exchange of data across
networks as well as the concepts of usability and accessibility.
We have looked at the continuing role standards have to play in the
development of web technologies and we shall look further at the work of
the W3C next week. We shall also look at what it means to have valid
XHTML coding and we will begin to look at the structure and anatomy of
web pages and what it means to code in XHTML.
As we develop through this block week on week you will build towards
creating a simple static website.
Don’t forget that you can use the forums to share any additional thoughts or
comments you may have about this week’s study.
28
13 References
13 References
AHRC (2000), ‘Bruce Lindsay Maguire v Sydney Organising Committee for the
Olympic Games’, Australian Human Rights Commission, http://www.hreoc.
gov.au/disability_rights/decisions/comdec/2000/DD000120.htm (accessed
2 November 2011).
Berners-Lee, T. (1989) ‘Information management: a proposal’, http://www.w3.
org/History/1989/proposal.html (accessed 2 November 2011).
IETF (2011) ‘Mission Statement’, Internet Engineering Task Force, http://www.
ietf.org/about/mission.html (accessed 2 November 2011).
29
Block 1: Basic web technologies
Part 1 - A brief history of the internet
Where next
Now go to …
You should now go to Part 2 The role of standards and the anatomy of
basic web pages
30