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