developers' wonderland

T A B L E O F C O N T E N T .

Page

Responsive Web Design

Where Do I Start? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1How the Web Works? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2HTML Versus XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Agile Development

Creating a Simple Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Cascading Style Sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Structural Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Development Frameworks

Understanding the standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Big Data

Special Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Hands On With the Nokia Lumia 925 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Google I/O 2013: What to Expect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15The Nature of Web Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Developer's Wonderland Learning Web Design

Where Do I Start?Komal Baig | May 15, 2013

The Web has been around for well over a decade now, experiencing euphoric early expansion, an economic-drivenbust, an innovation-driven rebirth, and constant evolution along the way. One thing is certain: the Web as a communi-cation and commercial medium is here to stay. For many people, it’s a call to action—a new career opportunity, an in-centive to keep up with competitors, or just a chance to get stuff out there for the world to see. But the world of webdesign can also seem overwhelming. Through my experience teaching web design courses and workshops, I’ve hadthe opportunity to meet people of all backgrounds who are inter ested in learning how to build web pages. Allow meto introduce you to just a few: “I’ve been a print designer for 17 years, and now all my clients want web sites.” “I workas a secretary in a small office. My boss has asked me to put together a small internal web site to share company in-formation among employees.” “I’ve been a programmer for years, but I want to try my hand at more visual design. Ifeel like the Web is a good opportunity to explore new skills”. “I am an artist and I want to know how to get samplesof my paintings and sculpture online.” “I’m a designer who has watched all my colleagues switch to web design in thelast few years. I’m curious about it, but I feel like I may be too late.” Whatever the motivation, the first question is al-ways the same: “Where do I start?” It may seem like there is an overwhelming amount of stuff to learn and it’s noteasy to know where to jump in. But you have to start somewhere.This chapter attempts to put the learning curve inperspective by answering the most common questions I get asked by people ready to make the leap. It provides anintroduction to the disciplines, technologies, and tools associated with web design. That’s an easy one—absolutelynot! Although it may seem that everyone in the whole world has a personal web page, or that your colleagues are alllightyears ahead of you in web experience, I can assure you that you’re not late. The Web has become an essentialpart of standard business practice. We’re at the point where we just assume that a business, regardless of its size, willhave a useful web site. It also remains a uniquely powerful tool for self-publishing, whether to a small circle of friendsor to a worldwide audience. We can be certain that there will be a steady need for web designers and developers.

Your particular starting point will no doubt depend on your background and goals. However, a good first step foreveryone is to get a basic understanding of how the Web and web pages work. That you are reading this booknow shows that you are already on the right track. Once you learn the fundamentals, there are plenty of resourceson the Web and in bookstores for you to further your learning in specific areas. One way to get up to speed quickly isto take an introductory web design class. If you don’t have the luxury of a full-semester course, even a weekend orone-day seminar can be extremely useful in getting over that first hump. You’ll learn that the term “web design” hascome to encompass many skills, and you don’t necessarily need to learn all of them (most people don’t). This chapterintroduces the various disciplines and paths you may take. Similarly, there are many levels of involvement in web de-sign, from just building a site for yourself to making it a full-blown career. You may enjoy being a full-service web sitedeveloper or just specializing in one skill, like Flash development. There are a lot of ways you can go.


1

How the Web Works?Abbas Saifuddin Mundrawala | May 15, 2013

As a web designer, you spend a lot oftime creating pages and tweakingthem until they look good in yourbrowser. Before you grow too at-tached to the way your page looks onyour screen, you should now that it islikely to look different to other peo-ple. That’s just the nature of web de-sign—you can’t guarantee that every-one will see your page the way youdo. The way your site looks and per-forms is at the mercy of a number ofvariables such as browser version,platform, monitor size, and the pref-erences or special needs of each in-dividual user. Your page may also beviewed on a mobile device like a cellphone, or using an assistive devicelike a screen magnifier or a screenreader. This unpredictable nature ofthe Web is particularly challenging ifyou have experience designing forprint, where what you design staysput. As a print designer who madethe transition to web design, I found Ineeded to let go of controlling thingssuch as page size, typography, andprecise color. Having a solid under-standing of the web environment al-lows you to anticipate and plan forthese shifting variables. Eventually,you’ll develop a feel for it. This chap-ter looks at the ways in whichbrowsers, user configurations, plat-form, connection speed, computermonitors, and alternative browsingenvironments affect the design andfunctionality of web pages. It sug-gests some tips for coping along theway.

One of the biggest challenges in de-signing for the Web is dealing with

the multitude of browsers in currentuse. Although the current version ofMicrosoft Internet Explorer runningon Windows makes up the lion’sshare (60 to 80% as of this writing),there are at least a dozen browserversions that web developers pay at-tention to,and hundreds more ob-scure or antiquated browsers still inuse. See the sidebar, Browser RollCall, for more information on rele-vant browsers. In the no-so-distantpast, browsers were so incompatiblethat web authors were forced to cre-ate two separate sites, one for Inter-net Explorer and one for Netscape(the only two players at the time).Fortunately, things have improveddramatically now that browsers havebetter support for web standards es-tablished by the World Wide WebConsortium (W3C for short). The sit-uation will continue to improve asolder, problematic browser versionssuch as Internet Explorer 5 andNetscape 4 fade out of existence.Fortunately, nearly all browsers inuse today support HTML 4.01 andXHTML standards, with only a fewexceptions. That doesn’t mean thatan (X)HTML document will look iden-tical on all browsers—there may stillbe slight differences in the defaultrendering of text and form elements.That’s because browsers have theirown internal style sheets that deter-mine how each element looks by de-fault. Instead, the new challenge forcross-browser consistency comes inthe varying support of certain as-pects of Cascading Style Sheets(CSS). Although most of the basicstyle sheet properties can be used re-liably, there are still some bugs andinconsistencies that may cause unex-pected results.

Browsing Environments

The previous section focused on is-sues relevant to graphical browsersused on desktop or laptop comput-ers. It is critical to keep in mind, how-ever, that people access content on

the Web in many different ways.Web designers must build pages in amanner that creates as few barriersas possible to getting to information,regardless of the user’s ability andthe device used to access the Web.In other words, you must design foraccessibility. Accessibility is a majortopic of discussion in the web designworld, and a priority for all web de-signers. While intended for userswith disabilities such as poor visionor limited mobility, the techniquesand strategies developed for accessi-bility also benefit other users withless-than-optimum browsing experi-ences,such as handheld devices, ortraditional browsers over slow mo-dem connections or with the imagesand JavaScript turned off. Accessiblesites are also more effectively in-dexed by search engines such asGoogle. The extra effort in mak-ing your site accessible is well worththe effort.

The Mobile Web

The increased popularity of the Web,combined with the growing relianceon handheld devices such as cellphones, PDAs, and palm-top comput-ers, has resulted in web browserssqueezing into the coziest of spaces.Although most content accessible onmobile devices has been developedspecifically for that type of browser,an increasing number of devicesnow include microbrowsers capa-ble of displaying the same web con-tent that you’d see on your PC. Mi-crobrowsers are designed to accom-modate limited display area, lowermemory capacity, and low bandwidthabilities. Some have only basic HTMLsupport and others support the cur-rent web standards. One limitation ofhandheld devices is screen size. Mo-bile displays are roughly only 240pixels square, although some have di-mensions as small as 128 pixels or aslarge as 320. That’s not much room tolook at a typical web site.


2

HTML Versus XHTMLSarmad Saleem | May 15, 2013

The argument about whether to use HTML or XHTML isone that comes up time and time again. Not so long ago,everyone was advising the use of XHTML almost withoutquestion, for no other reason than that it’s a newer imple-mentation of HTML and therefore the better option. How-ever, many people who once recommended using XHTMLhave since changed their minds on the topic—includingsome SitePoint authors who made very strong argumentsas to why examples in their books should be presented inHTML 4 rather than XHTML 1.1.5 It seems that we needto clarify what HTML and XHTML are, what their differ-ences are, and why one or the other should be used. The firstthing you should realize is that using HTML is not wrong aslong as you specify that you’re using HTML with the appro-priate doctype (p. 6), and the HTML you use is valid for thatdoctype. If you want to use HTML 4.01, no one can stop you!Ignore anyone who tells you that XHTML is way to go, andthat using HTML.

You may have heard or read that choosing XHTML meansthat you can’t use certain presentational elements such ascenter (p. 176), font (p. 188), basefont (p. 172), or u (p. 225).But this isn’t strictly true. You may use these elements inXHTML Transitional and Frameset just as you could inHTML Transitional and Frameset—the difference is thatthey’re not allowed in the Strict versions of these markuplanguages. Hopefully that’s a myth busted! If you do opt touse XHTML Strict (or HTML Strict), and you thereby losethese presentational elements, you’ll definitely need to relyon CSS to do the work of prettying things up; this approachalso places just a little more emphasis on the use of morestructurally orientated elements available in HTML andXHTML. But don’t be led to believe that XHTML is in someway more structural than HTML 4.01. You’re not going to beadding new structural features through your use of XHTM-L—headings, paragraphs, block quotes, and so on were allpresent in HTML 4.01. Regardless of the flavor of markupyou choose—HTML or XHTML—you can easily mark up yourpage using a series of div (p. 44) and span (p. 218) elements,style it entirely in CSS, validate it, and still be left with a doc-ument that offers no apparent meaning or structure aboutthe content it contains. In short, the language is only as goodas the pair of hands responsible for crafting it, and thusXHTML doesn’t guarantee a better end result! One possiblereason for using HTML 4.01 over XHTML (of any kind or lev-el of strictness) might be that page size is a very importantconsideration. For example, you may be creating a page thatneeds to be downloaded over a restricted connection, per-haps to a mobile device of some kind. By using HTML 4.01,you’re able to reduce the markup by not using quote marksand not using closing tags where the spec indicates thatthey’re optional. If you’re building your own personal website, or you’re building a site for an organization that doesn’thave (or expect) huge amounts of traffic, the aim ofachieving slightly leaner page weights probably won’t be astrong case for using HTML 4.01. However, if we’re talking

about a site that receives a significant amount of traffic, thesavings may well add up, so you might need to get your cal-culator out! The argument about whether to use HTML orXHTML is one that comes up time and time again. Not solong ago, everyone was advising the use of XHTML al-most without question, for no other reason than that it’s anewer implementation of HTML and therefore the betteroption. However, many people who once recommended us-ing XHTML have since changed their minds on the topic—in-cluding some SitePoint authors who made very strong ar-guments as to why examples in their books should be pre-sented in HTML 4 rather than XHTML 1.1.5 It seems that weneed to clarify what HTML and XHTML are, what their dif-ferences are, and why one or the other should be used. Forexample, if your use of HTML 4.01 means that you can omit100 bytes of characters from a given document (withoutthose deletions having an adverse effect on the document’spresentation in the browser), and if that document receivesone million hits a day, over the course of a month that savingwill amount to almost 3GB of bandwidth. Now, this is justa hypothetical scenario, and this is but one page in a website, but depending on the number of visitors your site at-tracts document (without those deletions having an adverseeffect on the document’s presentation in the browser), andif that document receives one million hits a day, over thecourse of a month that saving will amount to almost 3GB ofbandwidth. Now, this is just a hypothetical scenario, and thisis but one page in a web site, but depending on the numberof visitors your site attracts, a shaving of markup here, and acorner cut there—all the while ensuring that your page vali-dates as HTML 4.01—really can encourage you to use HTMLrather than XHTML.The first thing you should realize is thatusing HTML is not wrong as long as you specify that you’reusing HTML with the appropriate doctype (p. 6), and theHTML you use is valid for that doctype. If you want to useHTML 4.01, no one can stop you! Ignore anyone who tellsyou that XHTML is way to go, and that using HTML

For example, if your use of HTML 4.01 means that you canomit 100 bytes of characters from a given document (with-out those deletions having an adverse effect on the docu-ment’s presentation in the browser), and if that documentreceives one million hits a day, over the course of a monththat saving will amount to almost 3GB of bandwidth.


3

Creating a Simple PageManish Kumar | May 15, 2013

In the previous chapter, you learned the hows and whys of (X)HTML markup. This chapter introduces the elements you haveto choose from for marking up text content. There probably aren’t as many of them as you might think, and really just a hand-ful that you’ll use with regularity. Before we get to the element roll-call, this is a good opportunity for a reminder about theimportance of meaningful (semantic) and well-structured markup. In the early years of web design, it was common to chooseelements based on how they looked in the browser. Don’t like the size of the h1? Hey, use an h4 instead. Don’t like bullets onyour list? Make something list-like using line break elements. But no more! Those days are over thanks to reliable browser sup-port for style sheets that do a much better job at handling visual presentation than (X)HTML ever could. You should alwayschoose elements that describe your content as accurately as possible. If you don’t like how it looks, change it with a style sheet.A semantically marked up document ensures your content is available and accessible in the widest range of browsing environ-ments, from desktop computers to cell phones to screen readers. It also allows non-human readers, such as search engine in-dexing programs, to correctly parse your content and make decisions about the relative importance of elements on the page.

Your content should also read in a logical order in the source. Doing so improves its readability in all browsing environments.Information that should be read first should be at the beginning of the (X)HTML source document. You can always use stylesheets to position elements where you want them on the final web page. With these guidelines in mind, it is time to meet the(X)HTML text elements, starting with the block-level elements.

Building Blocks

When creating a web page, I always start with my raw content in a text file and make sure that it has been proofread and isready to go. I put in the document structure elements (html, head, title, and body). I also identify which version of (X)HTMLI’m using in a DOCTYPE declaration, but we’ll get to that in Chapter 10, Understanding the Standards. Then I am readyto divide the content into its major block-level elements. Block-level elements make up the main components of contentstructure. As mentioned in Chapter 4, Creating a Simple Page, block-level elements always start on a new line and usuallyhave some space added above and below, stacking up like blocks in the normal flow of the document. There are surprisinglyfew text block-level elements. Table 5-1 lists (nearly) all of them (see note).

Paragraphs


4

Paragraphs are the most rudimentary elements of a text document. You indicate a paragraph with the p element. Simplyinsert an opening tag at the beginning of the paragraph and a closing tag after it, as shown in this example. Serif typefaceshave small slabs at the ends of letter strokes. In general, serif fonts can make large amounts of text easier to read. Sans-serif fonts do not have serif slabs; their strokes are square on the end. Helvetica and Arial are examples of sans-serif fonts.In general, sans-serif fonts appear sleeker and more modern. Paragraphs may contain text, images and other inline ele-ments, but they may not contain other block elements, including other p elements, so be sure never to put the elements list-ed in Table 5-1 between paragraph tags.Paragraphs may contain text, images and other inline elements, but they may notcontain other block elements, including other p elements, so be sure never to put the elements listed in Table 5-1 betweenparagraph tags.

Headings

In the last chapter, we used the h1 and h2 elements to indicate headings for our Black Goose Bistro page. There are actuallysix levels of headings in (X)HTML, from h1 to h6. Because headings are used to provide logical hierarchy or outline to a doc-ument, it is proper to start with the Level 1 heading (h1) and work down in numerical order. Doing so not only improvesaccessibility, but helps search engines (information in higher heading levels is given more weight). Using heading levelsconsistently throughout a site—using h1 for all article titles, for example—is also recommended. This example shows themarkup for four heading levels. Additional heading levels would be marked up in a similar manner.You can use a style sheetto specify the appearance of the heading levels. By default, they will be displayed in bold text, starting in very large type forh1s with each consecutive level in smaller text. Heading elements implement six levels of document headings.

The Inline Text Element Round-up

Most (X)HTML text elements are inline elements, which means they just stay in the flow of text and do not cause linebreaks. Inline text elements fall into two general categories: semantic elements and presentational elements. Those termsshould be familiar by now. The semantic elements describe the meaning of the text; for example, an acronym or emphasizedtext. The presentational elements provide descriptions of the element’s typesetting or style, such as bold, italic, or under-lined. It should come as no surprise that the presentational inline elements are discouraged from use in contemporary webdesign where style information should kept be separate from the markup. For that reason, we’ll pay more attention to thepreferred semantic elements in this section.

Semantic inline elements

The semantic text elements describe the enclosed text’s meaning, context or usage. The way they look when they appear inthe browser window depends on a style sheet, either one you provide or the browser’s built-in default rendering. Despiteall the types of information you could add to a document, there are only a dozen of these elements in (X)HTML. Table 5-2lists all of them. We’ll discuss each in more detail in this section.Now that you’ve gotten your feet wet formatting text, areyou ready to jump into the deep end? .


5

Cascading Style SheetsAbbas Saifuddin Mundrawala | May 15, 2013

You’ve seen style sheets mentioned quite a bit already, and now we’ll finally put them to work and start giving our pagessome much needed style.Cascading Style Sheets (CSS) is the W3C standard for defining the presentation of documentswritten in HTML, XHTML, and, in fact, any XML language. Presentation, again, refers to the way the document is displayedor delivered to the user, whether on a computer screen, a cell phone display, or read aloud by a screen reader. With stylesheets handling the presentation, (X)HTML can get back to the business of defining document structure and meaning, asintended. CSS is a separate language with its own syntax. This chapter covers CSS terminology and fundamental conceptsthat will help you get your bearings for the upcoming chapters, where you’ll learn how to change text and font styles, addcolors and backgrounds, and even do basic page layout using CSS. Will you be a style sheet expert by the end of Part III?Probably not. But you will have a solid foundation for further reading, and lots of practice.

The Benefits of CSS

Not that you need further convincing that style sheets are the way to go, but here is a quick run-down of the benefits ofusing style sheets.Better type and layout controls. Presentational (X)HTML never gets close to offering the kind of controlover type, backgrounds, and layout that is possible with CSS. Less work. You can change the appearance of an entire siteby editing one style sheet. Making small tweaks and even entire site redesigns with style sheets is much easier than whenpresentation instructions are mixed in with the markup.Potentially smaller documents and faster downloads. Old schoolpractices of using redundant font elements and nested tables make for bloated documents. Not only that, you can applya single style sheet document to all the pages in a site for further byte savings. More accessible sites. When all matters ofpresentation are handled by CSS, you can mark up your content meaningfully, making it more accessible for nonvisual ormobile devices.

Reliable browser support.

Nearly every browser in current use supports all of CSS Level 1 and the majority of CSS Level 2. (See the sidebar, Meet the Stan-dards, for what is meant by CSS “levels.”) Come to think of it, there really aren’t any disadvantages to using style sheets. Thereare some lingering hassles from browser inconsistencies, but they can either be avoided or worked around if you know where


7

to look for them. It’s by no means a reason to put off using CSS right away. The power of CSS We’re not talking aboutminor visual tweaks here, like changing the color of headlines or adding text indents. When used to its full potential, CSSis a robust and powerful design tool. My eyes were opened by the variety and richness of the designs at CSS Zen Garden(www.csszengarden.com). Figure 11-1 shows just a few of my favorites. All of these designs use the exact same XHTML sourcedocument. Not only that, it doesn’t include a single img element (all of the images are used as backgrounds). But look how dif-ferent each page looks—and how sophisticated—that’s all done with style sheets. Granted, it takes a lot of practice to be ableto create CSS layouts like those shown in Figure 11-1. Killer graphic design skills help too (unfortunately, you won’t get thosein this book). I’m showing this to you up front because I want you to be aware of the potential of CSS-based design, particu-larly because the examples in this beginners’ book tend to be simple and straightforward. Take your time learning, but keepyour eye on the prize. How Style Sheets Work It’s as easy as 1-2-3! Start with a document that has been marked up in HTML orXHTML. Write style rules for how you’d like certain elements to look. Attach the style rules to the document. When the brows-er displays the document, it follows your rules for rendering elements (unless the user has applied some mandatory styles, butwe’ll get to that later). OK, so there’s a bit more to it than that, of course. Let’s give each of these steps a little more considera-tion.

The good news is that I’ve whipped up a little XHTML document for you to play with.Selectors In the previous small style sheetexample, the h1 and p elements are used as selectors. This most basic type of selector is called an element type selector. Theproperties defined for each will apply to every h1 and p element in the document, respectively. In upcoming chapters, I’ll intro-duce you to more sophisticated selectors that you can use to target elements, including ways to select groups of elements andelements that appear in a particular context. Mastering selectors—that is, choosing the best type of selector and using it strate-gically—is an important step in becoming a CSS Jedi Master.

Declarations

The declaration is made up of a property/value pair. There can be more than one declaration in a single rule; for example,the rule for p element above has both the font-size and font-family properties. Each declaration must end with a semicolonto keep it separate from the following declaration (see note). If you omit the semicolon, the declaration and the one follow-ing it will be ignored. The curly brackets and the declarations they contain are often referred to as the declaration block(Figure 11-3). Because CSS ignores whitespace and line returns within the declaration block, authors typically write eachdeclaration in the block on its own line, as shown in the following example. This makes it easier to find the properties ap-plied to the selector and to tell when the style rule ends.


8

Structural ElementsAbbas Saifuddin Mundrawala | May 15, 2013

The blockquote element is a mecha-nism for marking up a block of textquoted from a person or another doc-ument or source. It may be just a fewlines, or it may contain several para-graphs (which you’d mark up usingnested p (p. 70) elements). The W3Crecommendation states that web pageauthors should not type quota-tion marks in the text when they’re us-ing blockquote—we can leave it to thestyle sheets to take care of this ele-ment of presentation (just as it shouldbe when the q (p. 202) element is usedfor short, inline quotations). In practice,though, many authors do choose to in-clude quote marks, as browser supportfor automatically insertingthe language-appropriate quotationmarks is extremely poor. By default,most browsers’ basic built-in stylesheets render blockquote content withleft and right indentations, as shown inFigure 2.1. As a consequence,many people learned to use blockquoteto indent the text as a way to draw at-tention to a paragraph or section of apage. Of course, this is bad prac-tice—it’s simply the wrong markup forthe job. Only use blockquote if you’reactually quoting a source; to visually in-dent a block of text that’s not a quota-tion, use CSS (margin-left, or any otherstyle property you care to choose).As well as the core (p. 496) and eventattributes (p. 507), which are usedacross all HTML elements, blockquotehas the cite attribute, which is used toidentify the online source of the quo-tation in the form of a URI (for exam-ple, "http://sourcewebsite.doc/docu-ment.html"); the value of the cite at-tribute is not rendered on the screen.As such, browser support for this at-tribute is marked as none, but becauseit has other potential uses (for example,in search engine indexing, retrieval ofits content via DOM Scripting, andmore), and since improved native sup-port for the attribute is anticipated infuture browser versions, youshould use the cite attribute when youuse blockquote.The text attribute was used in older

browsers to change the default bodytext. The specified settings would ap-ply to any text, be that a heading, a

paragraph, or a block quote (link colorswere set using their own attributes,alink (p. 33), link (p. 36), and vlink (p.38), all of which are now deprecat-ed). This attribute is also deprecated,so you should avoid using it. Instead,use CSS to set the color of body text.The example shown above wouldtranslate to the following CSS: body{background:black;color:lime;}.Visited links will display in purple withan underline, which may not be suffi-ciently different to the default bluelink display for some users (see the sec-tion on the (p. 36) attribute for more).The vlink attribute allows you tochange the color of all links to pagesthat have previously been visited. Thisattribute is deprecated, so you shouldavoid using it. Instead, use theCSS equivalent to set link colors:a:visited {color:gray;}. Note that thevisited state is based on the browser’shistory. If the user clears the browser’shistory log, the visited links will onceagain render as unvisited links. The brelement’s purpose is very simple: it cre-ates a line break within a block of text,leaving no padding or margins be-tween the two blocks of text created bythe line break. While it’s still perfectlyvalid to use this element in XHTMLStrict pages (it’s not on the list of dep-recated elements), you need to takecare that you don’t misuse it, because:

The div is a generic block-level ele-ment. It doesn’t convey any meaningabout its contents (unlike a p elementthat signifies a paragraph, or an h1 (p.46) or h2 (p. 50) element that would in-dicate a level 1 or level 2 heading, re-spectively); as such, it’s easy to cus-tomize it to your needs. The div ele-ment is currently the most com-mon method for identifying the struc-tural sections of a document and forlaying out a web page using CSS. Somedevelopers perceive similarities be-tween the p and the div elements, see-ing them as being interchangeable, butthis isn’t the case. The p element offersmore semantic information (“this is aparagraph of text, a small collection ofhoughts that are grouped together;the next paragraph outlines some dif-ferent thoughts”), while the div ele-

ment can be used to group almost anyelements together. Indeed, it can con-tain almost any other element, unlike p,which can only contain inline elements.The h1 element is used to indicate themost important (or highest-level) head-ing on the page. In total, we have sixheading levels to choose from—h1 toh6—to add structure to the web page.h1 is the highest heading level (and, bydefault, the largest in terms of fontsize) and h6 the lowest (and smallest).

A document’s first heading should bean h1, followed by one or more h2headings; each of these h2 headingscan then have a further series of h3headings below them, and so on, righton down to heading level 6. The HTML4 spec states that heading levelsshould not be skipped (that is, youshouldn’t have a series of headings intheorder h1, h2, h2, h4, which skips theh3 entirely), although it isn’t alwayspossible to guarantee such rigidity inthe markup, particularly if your pagesare generated by a CMS. However, thisgoal is certainly one for which youshould aim. Headings add semanticrichness to a document, which can helpwith search engines’ understanding ofthe makeup of that document, and pro-vide users of assistive devices (such asscreen readers) with an addition-al—and quick—method by which tonavigate through a document: they canskip from heading to heading. Figure2.4 shows a comparison of the sixheading levels in a fictional web site,as rendered by Firefox’s default brows-er style sheet. In total, we have sixheading levels to choose from—h1 toh6—to add structure to the web page.h1 is the highest heading level (and, bydefault, the largest in terms of fontsize) and h6 the lowest (and smallest).


9

Understanding the standardsAbbas Saifuddin Mundrawala | May 15, 2013

I’m going to warn you right now... this is a big, geeky chapterfull of some pretty dry material. But I know you can handleit. If you have any notion of doing web development pro-fessionally, you’ll be required to know it. Even if you don’t,it’s important stuff.Professional web designers know thatthe best way to ensure consistency and accessibility acrossmultiple browsers and devices is to write standards com-pliant web documents. Standards compliance simply meansthat your documents abide by all of the rules in the latestr-ecommendations published by the World Wide Web Con-sortium (the W3C). That includes HTML and XHTML formarkup, but also other standards for style sheets (CSS)and accessibility. This chapter covers what it takes to getcompliant. It gets into the nittygritty on HTML and XHTMLand their various versions. It begins with a fair amount ofstory-telling, painting the picture of (X)HTML’s past, pre-sent, and future. Once you have a feel for the big picture,the markup requirements that follow will make a lot moresense. So sit back and enjoy the tale of HTML and XHTML.(If you’re thinking, “C’mon! I don’t have time for this... justtell me what I need to put in my document!” then you canskip to the last section in this chapter, Putting It All Togeth-er, for the bottom line.)

Everything You’ve Wanted toKnow

By now you’re familiar with (X)HTML—you’ve even gottenhandy with it. But did you know that there have been manyversions of HTML since its creation by Tim Berners-Lee in1991? The quick rundown that follows sums up HTML’sjourney and should provide some useful context for wherewe are today. Read the sidebar, HTML Version History, formore details. HTML and what we know as the Web got theirstart at a article physics lab ( CERN) in Switzerland whereTim Berners-Lee had an idea for sharing research docu-ments via a hypertext system. Instead of inventing amethodGeneralized Markup Language) as the basis for whathe coined the Hypertext Markup Language (HTML forshort). He took many elements such as p and h1 throughh6 right from SGML, then invented the anchor (a) elementfor adding hypertext links.Early versions of HTML (HTML+ and HTML 2.0) built on Tim’s early work with the intentof making it a viable publishing option for a greater world-wide audience.

HTML gets muddied

In 1994, Mosaic Communications introduced the Netscapebrowser and took the Web by storm. Their most notable“contribution” to web technology was the introduction ofmany proprietary extensions to HTML that improved thepresentation of web documents (in Netscape only, natural-ly). When Microsoft finally entered the browser scene in1996 with Internet Explorer 3.0, they countered by devel-

oping their own proprietary HTML extensions and webtechnologies. This divisive one-upping is generally referredto as the Browser Wars, and we are still living with the fall-out. international academic community, but it lagged behindcommercial development, and Netscape and Microsoftweren’t waiting for it. Finally, the newly-formed W3C put astake in the ground and released its first Recommendation,HTML 3.2, in 1996. HTML 3.2 documented the current stateof HTML markup, including many of the popular presenta-tional elements and attributes introduced by the browserdevelopers and gobbled up by site designers. The integrityof HTML had been compromised, and we’re still cleaning upthe mess....and back on track. HTML 4.0 and 4.01 (the slightrevision that superseded it in 1999) set out to rectify thesituation by emphasizing the separation of presentationfrom content. All matters of presentation were handed offto the newly developed Cascading Style Sheets (CSS) stan-dard. The other major advances in HTML 4.0 and 4.01 werea number of accessibility and internationalization fea-tures that aimed to make the Web available to everyone.HTML 4.01 is the most current version of HTML. (We’ll getto its prim and proper identical cousin, XHTML, in a mo-ment.) It would be nice if we could just end there and say,“so use HTML 4.01,” but it’s not so simple. There are actuallythree versions of HTML 4.01 to be aware of: Transitional,Strict, and Frameset. Let’s look at what they are andhow they differ.

HTML in three flavors

The authors of the HTML 4.01 Recommendation had adilemma on their hands. They had a vision of how HTMLshould work, given the standardization of style sheets andscripting languages. Unfortunately, the practical fact was, bythat time, millions of web pages had been written in legacyHTML. They could not enforce a radical change to the stan-dard overnight.To address this problem, they created sever-al versions of HTML. Transitional The “Transitional” versionincludes most of the presentational extensions to HTMLthat were in common use. This option was made available toease web authors as well as browser and tools developersout of their old habits. The presentational elements (likecenter) and attributes (like bgcolor and align) were markedas deprecated, indicating that they would be removedfrom future versions of HTML. The HTML 4.01 Recommen-dation urges the web community to avoid using deprecatedelements and attributes. Now that CSS is well supported byvirtually all browsers, that is finally easy to do.

Strict

At the same time, the W3C created a “Strict” version ofHTML 4.01 that omits all of the deprecated elements andgets HTML into the state they ultimately wanted it to bein. The third version of HTML is the “Frameset” version,which describes the content of framed documents. Frames


10

make it possible to divide the browser into multiple win-dows, each displaying a different HTML document.Frames are constructed with a frameset document that de-fines the frame structure and the content of each frame.Frameset documents are fundamentally different from oth-er HTML documents because they use the frameset ele-ment instead of body. This technicality earned them theirown HTML specification. Now you know that HTML hasthree versions, but let’s talk about it in a slightly more tech-nical way, using some terminology that will come inhandy later. When you create a markup language such asHTML, it is useful to document it in a Document Type Defi-nition, or simply DTD, particularly if large groups of peoplewill be using that language. A DTD defines all of the ele-ments and attributes in the language, as well as the rulesfor using them. What the W3C actually did was write threeslightly different DTDs for HTML 4.01: the TransitionalDTD, Strict DTD, and Frameset DTD. DTDs are dense docu-ments with a syntax that takes a while to learn to read. Luck-ily, you probably will never need to. But just to give you anidea, Figure 10-1 shows a small snippet of the HTML 4.01DTD that defines the p and h1–h6 elements and their avail-able attributes. If you are the curious type, you can take apeek at the full Strict DTD here: www.w3.org/TR/html4/strict.dtd. Don’t worry about understanding exactly whateverything means; it is sufficient to know that there arethree HTML 4.01 DTDs. That’s where the development ofHTML stopped, but the story doesn’t end there.

Namespace and language re-quirements

In addition to the rules listed above, because XHTML is anXML language,there are a few required attributes for thehtml root element that are not used in HTML. The html ele-ment for XHTML documents must be written like this: Thexmlns attribute stands for XML namespace. A namespaceis a convention established in XML to identify the language(also called a vocabulary) used by a document or element.Because XML allows several languages to be used in a doc-ument, there is the potential for overlap in element names.For example, how is an XML parser to know whether the aelement is an XHTML anchor or an “answer” from some hy-pothetical XML language used for testing? With XML name-spaces, you can make your intention clear. In XHTML doc-

uments, you must identify the xmlns as XHTML using theunique identifier for XHTML, as shown. The lang andxml:lang attributes are two ways of specifying the languageof the document. The value is a standardized two- or three-letter language code. Chances are if you are reading thisbook, you will be authoring documents in English (en). Fora complete list of language codes, see www.loc.gov/stan-dards/ iso639-2/langcodes.html. This is a good time to putsome of this book-learning to use. Exercise 10-1gives you achance to convert an HTML document to XHTML. I’m go-ing to warn you right now... this is a big, geeky chapter fullof some pretty dry material. But I know you can handle it.If you have any notion of doing web development profes-sionally, you’ll be required to know it. Even if you don’t, it’simportant stuff.Professional web designers know that thebest way to ensure consistency and accessibility across mul-tiple browsers and devices is to write standards compliantweb documents. Standards compliance simply means thatyour documents abide by all of the rules in the latest r-ec-ommendations published by the World Wide Web Consor-tium (the W3C). That includes HTML and XHTML formarkup, but also other standards for style sheets (CSS)and accessibility. This chapter covers what it takes to getcompliant. It gets into the nittygritty on HTML and XHTMLand their various versions. It begins with a fair amount ofstory-telling, painting the picture of (X)HTML’s past, pre-sent, and future. Once you have a feel for the big picture,the markup requirements that follow will make a lot moresense. So sit back and enjoy the tale of HTML and XHTML.(If you’re thinking, “C’mon! I don’t have time for this... justtell me what I need to put in my document!” then you canskip to the last section in this chapter, Putting It All Togeth-er, for the bottom line.) I’m going to warn you right now...this is a big, geeky chapter full of some pretty dry material.But I know you can handle it. If you have any notion of doingweb development professionally, you’ll be required to knowit. Even if you don’t, it’s important stuff.Professional web de-signers know that the best way to ensure consistency andaccessibility across multiple browsers and devices is towrite standards compliant web documents. Standards com-pliance simply means that your documents abide by all ofthe rules in the latest r-ecommendations published by theWorld Wide Web Consortium (the W3C). That includesHTML and XHTML for markup, but also other standards forstyle sheets (CSS) and accessibility.


11

Special FilesSarmad Saleem | May 15, 2013

Special files constitute the most unusu-al feature of the UNIX file system. EachI/O device supported by UNIX is asso-ciated with at least one such file. Spe-cial files are read and written just likeordinary disk files, but requests toread or write result in activation of theassociated device. An entry for eachspecial file resides in directory /dev, al-though a link may be made to one ofthese files just like an ordinary file.Thus, for example, to punch paper tape,one may write on the file /dev/ppt. Spe-cial files exist for each communica-tion line, each disk, each tape drive, andfor physical core memory. Of course,the active disks and the core special fileare protected from indiscriminate ac-cess. There is a threefold advantage intreating I/O devices this way: file anddevice I/O are as similar as possible;file and device names have the samesyntax and meaning, so that a programexpecting a file name as a parametercan be passed a device name; finally,special files are subject to the sameprotection mechanism as regular files.Although the root of the file system isalways stored on the same device, it isnot necessary that the entire file sys-tem hierarchy reside on this device.There is a mount system request whichhas two arguments: the name of an ex-isting ordinary file, and the name of adirect-access special file whose associ-ated storage volume (e.g. diskpack) should have the structure of anindependent file system containing itsown directory hierarchy. The effect ofmount is to cause references to theheretofore ordinary file to refer in-stead to the root directory of the filesystem on the removable volume. In ef-fect, mount replaces a leaf of the hier-archy tree (the ordinary file) by a wholenew subtree (the hierarchy stored onthe removable volume). After

the mount, there is virtually no distinc-tion between files on the removablevolume and those in the permanent filesystem. In our installation, for example,the root directory resides on the fixed-head disk, and the large disk drive,which contains user’s files, is mountedby the system initialization program,the four smaller disk drives are avail-able to users for mounting their owndisk packs. A mountable file system isgenerated by writing on its corre-sponding special file. A utility programis available to create an empty file sys-tem, or one may simply copy an existingfile system. There is only one exceptionto the rule of identical treatment offiles on different devices: no link mayexist between one file system hierar-chy and another. This restriction is en-forced so as to avoid the elaboratebookkeeping which would otherwisebe required to assure removal ofthe links when the removable volume isfinally dismounted. Inparticular, in theroot directories of all file systems, re-movable or not, the name “..” refers tothe directory itself instead of to its par-ent.

Although the access control scheme inUNIX is quite simple, it has some un-usual features. Each user of the sys-tem is assigned a unique user identifi-cation number. Whena file is created, it is marked with theuser ID of its owner. Also given for newfiles is a set of seven protection bits.Six of these specify independentlyread, write, and execute permission forthe owner of the file and for all otherusers. If the seventh bit is on, the sys-tem will temporarily change the useridentification of the current user tothat of the creator of the file wheneverthe file is executed as a program. Thischange in user ID is effective only dur-

ing the execution of the program whichcalls for it. The set-user-ID feature pro-vides for privileged programs whichmay use files inaccessible to otherusers. For example, a program maykeep an accounting file which shouldneither be read nor changed except bythe program itself. If the set-useridenti-fication bit is on for the program, it mayaccess the file although this accessmight be forbidden to other pro-grams invoked by the given program’suser. Since the actual user ID of the in-voker of any program is always avail-able, set-user-ID programs may takeany measuresdesired to satisfy themselves as totheir invoker’s credentials. This mecha-nism is used to allow users to executethe carefully written commands whichcall privileged systementries. For example, there is a systementry invocable only by the “super-user” (below) which creates an emptydirectory. As indicated above, directo-ries are expected to have entries forand The command which creates a di-rectory is owned by the super user andhas the set-user-ID bit set.After it checks its invoker’s authoriza-tion to create the specified directory, itcreates it and makes the entries forand Since anyone may set the set-user-ID bit on one of hisown files, this mechanism is generallyavailable without administrative in-tervention. For example, this protec-tion scheme easily solves the MOO ac-counting problem posed in [7]. The sys-tem recognizes one particular user ID(that of the “super-user”) as exemptfrom the usual constraints on file ac-cess; thus (for example) programs maybe written to dump and reload the filesystem without unwanted interfer-ence from the protection system.


12

Hands On With the Nokia Lumia 925Sarmad Saleem | May 15, 2013

The Lumia 925 is another notch on the photographic bed-post of Nokia’s burgeoning cameraphone arsenal. The firstin its flagship metal range, the company cites a "materials-based design approach," and it certainly feels sturdy andcomfy in hand while being noticeably lighter and slimmerthan its Lumia siblings.The new design incorporates a slim matte-finish aluminiumband running around its edge that divides the polycarbon-ate rear from the sculpted edge-to-edge Gorilla Glassscreen. It not only looks good but acts as the 925’s antennatoo. It’s a positive step away from the usual Lumia designand at only 0.33 inch thin and 4.9 ounces (that’s 1.6 ounceslighter than the Lumia 920) conspires to make the 925 aphone you’ll want to hold and stroke while making the olderLumias look almost clunky by comparison.Internally it’s Lumia business as usual despite the 925’s less-er dimensions and weight. It runs the same dual-core1.5GHz processor with 1GB of RAM and up to 16GB of non-expandable storage (although Nokia said Vodafone wouldbe offering an exclusive deal for a 32GB version in the U.K.,Germany, Spain and Italy).Available in three "colours" — black, white and grey and var-ious two-tone combinations thereof, the 925 has a seriousbut sophisticated look and feel that I like more than the hall-mark primary colors of the existing Lumia line.The Lumia 925 lacks the 920’s integrated Qi wireless charg-ing, but you can get it back — along with those bright colors— with an accessory. To wireless charge, you’ll need to buy asnap-on cover that acts and looks like any typical phone caseand comes in the full gamut of Lumia colours — black, red,white and a particularly punchy yellow.

Screen Idol

Another change from the existing Lumia range but followingon from the announcement of last week’s 928 is the new4.5-inch OLED display delivering 1,280 x 768 pixels. It’s stillpeddling the ClearBlack technology that suitably blackensblacks and by contrast helps colours to pop, and in our testmodel the Windows Live Tiles were clear and sharply de-fined, though the underground bunker location didn’t giveus a chance to test it in direct sunlight where OLED can suf-

fer over IPS displays. A nice touch is the ability to incremen-tally tailor color saturation and vibrancy for the screen as awhole to set it just how you like it.

Smart Camera

Typical to the Lumia range, the 925’s fanfare parade is forits camera. Sporting the same 8.7-megapixel sensor from itsprevious models, Nokia promises us it’s made huge improve-ments to the camera lens and software algorithms thatmake it the "most advanced lens technology" available.Importantly, the 925’s camera has the PureView label, andits Carl Zeiss lens has a new addition — a new lens. Thelens has six elements (one glass, five plastic) compared tothe iPhone’s five, which Nokia claims has significantly im-proved its low-light credentials. Strangely there’s no xenonflash as added to last week’s 928, so we have to settle withthe dual LED instead, but in the ‘photos in the dark’ testroom it proved to be as adept as we’d hoped for and a betterlow-light performer than most smartphone cams.It’s not just in the hardware the Nokia has made improve-ments to its camera. Smart Camera is a new app that hoststhe camera’s myriad functionality, making it super easy andquick to shoot and edit your pics all from one place. Shooting10 frames each time you click, you’re then presented withfive editing modes including Best Shot, Action Shot, MotionBlur, Change Faces and Fade Effect.I have to say, it’s startlingly easy to use and in less than aminute I was chopping and changing in all sorts of ways,from fading colors out to blurring backgrounds with twoswipes and a tap of the screen. The Fade Effect is anotherparticularly nice touch that lets you create some strangeghosting effects that could have kept me occupied for hours.Granted, even with two errant skateboarders showing off,the launch event isn’t the best place to test this tech to themax, but I was left itching to have another go in "real world"conditions. Punchy and clear on the new OLED screen, the925 may now have set the benchmark for smartphone cam-era photography and editing.

Best of the Rest

Internally, the 925 differs little from the 920 (and the 928from what we’ve seen) and as such performance is almostidentical, which is not a bad thing. Standard web browsingwas fine with pages loading quickly and cleanly, while emailtook a little longer but that was mostly down to the pedes-trian Wi-Fi I was using.In truth, the real differentiators over the 920 and 928 arein design and the camera upgrades. Design- and looks-wise,the 925 has left the existing Lumias lagging way behind,boosted by the hefty weight loss and the inclusion of thatsubtle metal styling.


14

http://mashable.com/category/pureview/

Google I/O 2013: What to ExpectKomal Baig | May 15, 2013

Google’s annual developer conference, Google I/O, beginsWednesday morning, and it has a tough act to follow. Thecompany set the bar high last year with a product- andevent-dominated agenda, including the well-reviewedNexus 7 tablet, a big step up for Android in version 4.1 "JellyBean" and an amazing skydiving stunt to hype Google Glass.Even the Nexus Q media console — a dud if there ever wasone — was notable: It didn’t just fail, it failed spectacularly.So how can Google top itself for 2013? Answer: by not try-ing. Ahead of the conference, Google’s Android head SundarPichai sought to manage expectations in an interviewwith Wired. Don’t expect the same product carnival we sawin Google I/O 2012. This year, Google is amping up the geekfactor (if that’s possible) and focusing on developers. Thatdoesn’t mean there won’t be any product announcements,just that the majority of them will probably be softwarerather than hardware. We also likely won’t see any newgame-changers the way Google Glass stole headlines lastyear. In 2012, Google was planting seeds; now it’s wateringthem. Here’s what we expect to see growing in that garden:

Glass Gets Clearer

Google Glass isn’t just a weird object sitting on a fewGooglers’ faces anymore. Now, thousands of developershave the hardware, and most of them will be at I/O. Googleis loading Day 2 of the conference with several sessions ded-icated to developing for Glass, and there’s a good chance itwill use the conference to reveal more official apps. Maybewe’ll finally see automatic picture-taking mode. Might wesee Sergey Brin interrupt another one of his executives onstage during Wednesday’s keynote to showcase anotherlarger-than-life Glass stunt? Anything’s possible, but he’dhave a hard time topping last year’s skydive — especiallynow that Glass is a real thing in developers’ hands and notsome semi-mythical device.

Android Game Center

The most credible rumor about the coming conference isthat Google will announce an official Android Game Center— a central hub for games on the platform where players canpost scores, compete with each other and even engage inmultiplayer gaming.

It’s an overdue feature, and would finally give Android theequivalent of Game Center on iOS. The introduction ofGoogle Game Center for Android (as it’s rumored to becalled) will make it easier for developers to create engaging,multiplayer games by standardizing the tools involved. An-droid phones, tablets and gaming devices such as Nvidia’sProject Shield will all benefit.Might the introduction of an Android Game Center mean areturn of the Nexus Q as a gateway to Android gaming on aTV? That’s doubtful, but if we don’t see some kind of rebirthfor the Q at I/O 2013, we can consider it dead and buried.

Android Update

There will definitely be some kind of update to Android atGoogle I/O 2013, but it’s unclear how big of an update. Earlyrumors pegged the conference as the launchpad for version5.0 "Key Lime Pie," but now the buzz is pointing to a less mo-mentous change in the ecosystem. Yes, we may get anoth-er flavor of Jelly Bean before we can stuff ourselves withPie. Android 4.3 supposedly upgrades the OS to BluetoothSmart Ready, meaning phones will support low-energy de-vices such as heart-rate monitors. As for other features,we’ll have to wait and see, but they’re sure to be similarly mi-nor.

Hardware

A new tablet? Yes, that’s probably on deck, but it looks likeit’ll be an update to Google’s succesful Nexus 7 rather thansomething new. A Nexus 8 — something to compete moredirectly with the iPad mini — has occasionally been ru-mored, but reports about it petered out, suggesting it wasnever real, or may debut later. What about the Motorola Xphone, which has been talked about for months? That’s al-most certainly in development, but if it makes an appearan-ce at I/O, it’ll probably be in an early preview form ratherthan a launch. Given how most companies reveal phonesthese days, Google would be breaking sharply from the cur-rent pattern if it unveiled something that won’t be on storeshelves for months.

Babel

One of the bigger software announcements that’s been ru-mored is Google Babel (or Babble), which will represent aunification of Google’s myriad chat services. With Babel,products such as Drive, Gmail and Google+ will all use thesame communication tools. Babel looks very likely becauseit’s something Google really needs. However, various sitesare reporting that Babel is just a code name, and Google willinstead adopt terminology from Google+, and just call thenew tool Hangouts.


15

The Nature of Web DesignAbbas Saifuddin Mundrawala | May 15, 2013

I got started in web design in early 1993—pretty close to thestart of the Web itself. In web time, that makes me an old-timer, but it’s not so long ago that I can’t remember the firsttime I looked at a web page. It was difficult to tell where theinformation was coming from and how ait all worked. Thischapter sorts out the pieces and introduces some basic ter-minology you’ll encounter. If you’ve already spent time pe-rusing the Web, some of this information will be a review. Ifyou’re starting from scratch, it is important to have all theparts in perspective. We’ll start with the big picture andwork down to specifics.We now know that the server doesthe servin’, but what about the other half of the equation?The software that does the requesting is called theclient. On the Web, the browser is the client software thatmakes requests for documents.The server returns the documents for the browser to dis-play. The requests and responses are handled via the HTTPprotocol, mentioned earlier. Although we’ve been talkingabout “documents,” HTTP can be used to transfer images,movies, audio files, and all the other web resourcesthat commonly make up web sites or are shared over theWeb.Often in web design, you’ll hear reference to “client-side” or “server-side” applications.These terms are used toindicate which machine is doing the processing. Client-side applications run on the user’s machine, while server-side applications and functions use the processing power ofthe server computer.With all those web pages on all thoseservers, how would you ever find the one you’re looking for?Fortunately, each document has its own special addresscalled a URL (Uniform Resource Locator).

The Internet Versus the Web

No, it’s not a battle to the death, just an opportunity to pointout the distinction between these two words that are in-creasingly being used interchangeably. The Internet is a net-work of connected computers. No company owns the Inter-net (i.e., it is not equivalent to a service like America Online);it is a cooperative effort governed by a system of standardsand rules. The purpose of connecting computers together,of course, is to share information. There are many ways in-formation can be passed between computers, includ-ing email, file transfer (FTP), and many more specialized

modes upon which the Internet is built. These standardizedmethods for transferring data or documents over a networkare known as protocols. The World Wide Web (known af-fectionately as “the Web”) is just one of the ways informa-tion can be shared over the Internet. It is unique in that it al-lows documents to be linked to one another using hypertextlinks—thus forming a huge “web” of connected information.The Web uses a protocol called HTTP ( HyperText Trans-fer Protocol). If you’ve spent any time using the Web, thatacronym should look familiar because it is the first four let-ters of nearly all web site addresses, as we’ll discuss in anupcoming section. Let’s talk more about the computers thatmake up the Internet. Because they “serve up” documentsupon request, these computers are known as servers. Moreaccurately, the server is the software (not the computer it-self) that allows the computer to communicate with othercomputers; however, it is common to use the word “server”to refer to the computer, as well. The role of server softwareis to wait for a request for information, then retrieveand send that information back as quickly as possible.

There’s nothing special about the computers them-selves…picture anything from a high-powered Unix machineto a humble personal computer. It’s the server software thatmakes it all happen. In order for a computer to be part of theWeb, it must be running special web server software that al-lows it to handle Hypertext Transfer Protocol transactions.Web servers are also called “HTTP servers.” There are manyserver software options out there, but the two most popu-lar are Apache (open source software, see sidebar) and Mi-crosoft Internet

Information Services (IIS). Apache is freely available forUnix-based computers and comes installed on Macs runningMac OS X. There is a Windows version as well. Microsoft IISis part of Microsoft’s family of server solutions. Each com-puter on the Internet is assigned a unique numeric IP ad-dress (IP stands for Internet Protocol). For example, thecomputer that hosts oreilly.com has the IP address208.201.239.37. All those numbers can be dizzying, so for-tunately, the Domain Name System (DNS) was developedthat allows us to refer to that server by its domain name, or-eilly.com, as well.


16

developers' wonderland

Documents