UBUNTU
DOWNLOAD
next
Jumat, 22 Januari 2010
JavaScript
What Is JavaScript?
When JavaScript first appeared in 1995, its main purpose was to handle some of the input validation
that had previously been left to server-side languages such as Perl. Prior to that time, a round
trip to the server was needed to determine if a required field had been left blank or an entered
value was invalid. Netscape Navigator sought to change that with the introduction of JavaScript.
The capability to handle some basic validation on the client was an exciting new feature at a time
when use of telephone modems (operating at 28.8 kbps) was widespread. Such slow speeds
turned every trip to the server into an exercise in patience.
Since that time, JavaScript has grown into an important feature of every major Web browser on
the market. No longer bound to simple data validation, JavaScript now interacts with nearly all
aspects of the browser window and its contents. Even Microsoft, with its own client-side scripting
language called VBScript, ended up including its own JavaScript implementation in Internet
Explorer from its very earliest version.
In this chapter, you will learn how and why JavaScript came about, from its humble beginnings to
its modern-day, feature-packed implementations. To be able to use JavaScript to its full potential, it
is important to understand its nature, history, and limitations. Specifically, this chapter examines:
❑ The origins of JavaScript and client-side scripting
❑ The different parts of the JavaScript language
❑ The standards related to JavaScript
❑ JavaScript support in popular Web browsers
A Short History
Around 1992, a company called Nombas began developing an embedded scripting language
called C-minus-minus (Cmm for short). The idea behind Cmm was simple: a scripting language
powerful enough to replace macros, but still similar enough to C (and C++) that developers could learn
it quickly. This scripting language was packaged in a shareware product called CEnvi, which first
exposed the power of such languages to developers. Nombas eventually changed the name Cmm to
ScriptEase because the latter sounded “too negative” and the letter C “frightened people” (http://
www.nombas.com/us/scripting/history.htm). ScriptEase is now the driving force behind Nombas
products. When the popularity of Netscape Navigator started peaking, Nombas developed a version of
CEnvi that could be embedded into Web pages. These early experiments were called Espresso Pages, and
they represented the first client-side scripting language used on the World Wide Web. Little did Nombas
know that its ideas would become an important foundation for the Internet.
As Web surfing gained popularity, a gradual demand for client-side scripting languages developed. At
the time, most Internet users were connecting over a 28.8 kbps modem even though Web pages were
growing in size and complexity. Adding to users’ pain was the large number of round-trips to the server
required for simple form validation. Imagine filling out a form, clicking the Submit button, waiting 30
seconds for processing, and then being met with a message telling you that you forgot to complete a
required field. Netscape, at that time on the cutting edge of technological innovation, began seriously
considering the development of a client-side scripting language to handle simple processing.
Brendan Eich, who worked for Netscape at the time, began developing a scripting language called
LiveScript for the upcoming release of Netscape Navigator 2.0 in 1995, with the intention of using it both
in the browser and on the server (where it was to be called LiveWire). Netscape entered into a development
alliance with Sun Microsystems to complete the implementation of LiveScript in time for release.
Just before Netscape Navigator 2.0 was officially released, Netscape changed the name to JavaScript in
order to capitalize on Java as a new Internet buzzword. Netscape’s gamble paid off and JavaScript
became a must-have from that point on.
Because JavaScript 1.0 was such a hit, Netscape released version 1.1 in Netscape Navigator 3.0. Right
around that time, Microsoft decided to throw its hat into the ring and released Internet Explorer 3.0 with
a JavaScript-clone called JScript (so-called in order to avoid any possible licensing issues with Netscape).
This major step for Microsoft into the realm of Web browsers is now a date that lives in infamy for
Netscape, but it also represented a major step in the development of JavaScript as a language.
After Microsoft threw its hat into the ring, three different JavaScript versions were floating around:
JavaScript in Netscape Navigator, JScript in Internet Explorer, and CEnvi in ScriptEase. Unlike C and
many other programming languages, JavaScript had no standards governing its syntax or features, and
the three different versions only highlighted this problem. With industry fears mounting, it was decided
that the language must be standardized.
In 1997, JavaScript 1.1 was submitted to the European Computer Manufacturers Association (ECMA) as a
proposal. Technical Committee #39 (TC39) was assigned to “standardize the syntax and semantics of a general
purpose, cross-platform, vendor-neutral scripting language” (http://www.ecma-international
.org/memento/TC39.htm). Made up of programmers from Netscape, Sun, Microsoft, Borland, and other
companies with interest in the future of scripting, TC39 met for months to hammer out ECMA-262, a standard
defining a new scripting language named ECMAScript.
The following year, the International Organization for Standardization and International Electrotechnical
Commission (ISO/IEC) also adopted ECMAScript as a standard (ISO/IEC-16262). Since that time, Web
browsers have tried, with varying degrees of success and failure, to use ECMAScript as a basis for their
JavaScript implementations.
JavaScript Implementations
Although ECMAScript is an important standard, it is not the only part of JavaScript, and certainly not
the only part that has been standardized. Indeed, a complete JavaScript implementation is made up of
three distinct parts (see Figure 1-1):
❑ The Core (ECMAScript)
❑ The Document Object Model (DOM)
❑ The Browser Object Model (BOM)
ECMAScript
ECMAScript doesn’t have ties to any browser in particular and, actually, has no methods for user input
or output to speak of. (It is not unlike languages such as C, which rely on external libraries to accomplish
such tasks.) So what is ECMAScript? ECMA-262 (p. 2) describes it like this:
“ECMAScript can provide core scripting capabilities for a variety of host environments, and therefore
the core scripting language is specified...apart from any particular host environment.”
AWeb browser is considered a host environment for ECMAScript, but it is not the only host environment.
Indeed, numerous other environments (such as Nombas’s ScriptEase and Macromedia’s ActionScript,
used in both Flash and Director MX) can host ECMAScript implementations. So what does ECMAScript
specify outside of a browser? To put it simply, ECMAScript describes the following:
❑ Syntax
❑ Types
❑ Statements
❑ Keywords
❑ Reserved Words
❑ Operators
❑ Objects
ECMAScript is simply a description, defining all the properties, methods, and objects of a scripting language.
Other languages implement ECMAScript, as JavaScript does (see Figure 1-2), as the baseline for
functionality.
JavaScript
ECMAScript DOM BOM
Each browser has its own implementation of the ECMAScript interface, which is then extended to contain
the DOM and BOM (discussed in the following sections). There are other languages that also implement
and extend ECMAScript such as Windows Scripting Host (WSH), ActionScript in Macromedia
Flash and Director, and Nombas ScriptEase.
next
When JavaScript first appeared in 1995, its main purpose was to handle some of the input validation
that had previously been left to server-side languages such as Perl. Prior to that time, a round
trip to the server was needed to determine if a required field had been left blank or an entered
value was invalid. Netscape Navigator sought to change that with the introduction of JavaScript.
The capability to handle some basic validation on the client was an exciting new feature at a time
when use of telephone modems (operating at 28.8 kbps) was widespread. Such slow speeds
turned every trip to the server into an exercise in patience.
Since that time, JavaScript has grown into an important feature of every major Web browser on
the market. No longer bound to simple data validation, JavaScript now interacts with nearly all
aspects of the browser window and its contents. Even Microsoft, with its own client-side scripting
language called VBScript, ended up including its own JavaScript implementation in Internet
Explorer from its very earliest version.
In this chapter, you will learn how and why JavaScript came about, from its humble beginnings to
its modern-day, feature-packed implementations. To be able to use JavaScript to its full potential, it
is important to understand its nature, history, and limitations. Specifically, this chapter examines:
❑ The origins of JavaScript and client-side scripting
❑ The different parts of the JavaScript language
❑ The standards related to JavaScript
❑ JavaScript support in popular Web browsers
A Short History
Around 1992, a company called Nombas began developing an embedded scripting language
called C-minus-minus (Cmm for short). The idea behind Cmm was simple: a scripting language
powerful enough to replace macros, but still similar enough to C (and C++) that developers could learn
it quickly. This scripting language was packaged in a shareware product called CEnvi, which first
exposed the power of such languages to developers. Nombas eventually changed the name Cmm to
ScriptEase because the latter sounded “too negative” and the letter C “frightened people” (http://
www.nombas.com/us/scripting/history.htm). ScriptEase is now the driving force behind Nombas
products. When the popularity of Netscape Navigator started peaking, Nombas developed a version of
CEnvi that could be embedded into Web pages. These early experiments were called Espresso Pages, and
they represented the first client-side scripting language used on the World Wide Web. Little did Nombas
know that its ideas would become an important foundation for the Internet.
As Web surfing gained popularity, a gradual demand for client-side scripting languages developed. At
the time, most Internet users were connecting over a 28.8 kbps modem even though Web pages were
growing in size and complexity. Adding to users’ pain was the large number of round-trips to the server
required for simple form validation. Imagine filling out a form, clicking the Submit button, waiting 30
seconds for processing, and then being met with a message telling you that you forgot to complete a
required field. Netscape, at that time on the cutting edge of technological innovation, began seriously
considering the development of a client-side scripting language to handle simple processing.
Brendan Eich, who worked for Netscape at the time, began developing a scripting language called
LiveScript for the upcoming release of Netscape Navigator 2.0 in 1995, with the intention of using it both
in the browser and on the server (where it was to be called LiveWire). Netscape entered into a development
alliance with Sun Microsystems to complete the implementation of LiveScript in time for release.
Just before Netscape Navigator 2.0 was officially released, Netscape changed the name to JavaScript in
order to capitalize on Java as a new Internet buzzword. Netscape’s gamble paid off and JavaScript
became a must-have from that point on.
Because JavaScript 1.0 was such a hit, Netscape released version 1.1 in Netscape Navigator 3.0. Right
around that time, Microsoft decided to throw its hat into the ring and released Internet Explorer 3.0 with
a JavaScript-clone called JScript (so-called in order to avoid any possible licensing issues with Netscape).
This major step for Microsoft into the realm of Web browsers is now a date that lives in infamy for
Netscape, but it also represented a major step in the development of JavaScript as a language.
After Microsoft threw its hat into the ring, three different JavaScript versions were floating around:
JavaScript in Netscape Navigator, JScript in Internet Explorer, and CEnvi in ScriptEase. Unlike C and
many other programming languages, JavaScript had no standards governing its syntax or features, and
the three different versions only highlighted this problem. With industry fears mounting, it was decided
that the language must be standardized.
In 1997, JavaScript 1.1 was submitted to the European Computer Manufacturers Association (ECMA) as a
proposal. Technical Committee #39 (TC39) was assigned to “standardize the syntax and semantics of a general
purpose, cross-platform, vendor-neutral scripting language” (http://www.ecma-international
.org/memento/TC39.htm). Made up of programmers from Netscape, Sun, Microsoft, Borland, and other
companies with interest in the future of scripting, TC39 met for months to hammer out ECMA-262, a standard
defining a new scripting language named ECMAScript.
The following year, the International Organization for Standardization and International Electrotechnical
Commission (ISO/IEC) also adopted ECMAScript as a standard (ISO/IEC-16262). Since that time, Web
browsers have tried, with varying degrees of success and failure, to use ECMAScript as a basis for their
JavaScript implementations.
JavaScript Implementations
Although ECMAScript is an important standard, it is not the only part of JavaScript, and certainly not
the only part that has been standardized. Indeed, a complete JavaScript implementation is made up of
three distinct parts (see Figure 1-1):
❑ The Core (ECMAScript)
❑ The Document Object Model (DOM)
❑ The Browser Object Model (BOM)
ECMAScript
ECMAScript doesn’t have ties to any browser in particular and, actually, has no methods for user input
or output to speak of. (It is not unlike languages such as C, which rely on external libraries to accomplish
such tasks.) So what is ECMAScript? ECMA-262 (p. 2) describes it like this:
“ECMAScript can provide core scripting capabilities for a variety of host environments, and therefore
the core scripting language is specified...apart from any particular host environment.”
AWeb browser is considered a host environment for ECMAScript, but it is not the only host environment.
Indeed, numerous other environments (such as Nombas’s ScriptEase and Macromedia’s ActionScript,
used in both Flash and Director MX) can host ECMAScript implementations. So what does ECMAScript
specify outside of a browser? To put it simply, ECMAScript describes the following:
❑ Syntax
❑ Types
❑ Statements
❑ Keywords
❑ Reserved Words
❑ Operators
❑ Objects
ECMAScript is simply a description, defining all the properties, methods, and objects of a scripting language.
Other languages implement ECMAScript, as JavaScript does (see Figure 1-2), as the baseline for
functionality.
JavaScript
ECMAScript DOM BOM
Each browser has its own implementation of the ECMAScript interface, which is then extended to contain
the DOM and BOM (discussed in the following sections). There are other languages that also implement
and extend ECMAScript such as Windows Scripting Host (WSH), ActionScript in Macromedia
Flash and Director, and Nombas ScriptEase.
next
Selasa, 19 Januari 2010
Three Layers
Keeping different kinds of code as separate as possible is a good idea in any kind
of programming. It makes it easier to reuse portions of that code in future projects,
it reduces the amount of duplicate code you end up writing, and it makes it easier
to find and fix problems months and years later.
When it comes to the Web, there’s one more reason to keep your code separate: it
lets you cater for the many different ways in which people access web pages.
Depending on your audience, the majority of your visitors may use well-appointed
desktop browsers with cutting-edge CSS and JavaScript support, but many might
be subject to corporate IT policies that force them to use older browsers, or to browse
with certain features (like JavaScript) disabled.
Visually impaired users often browse using screen reader or screen magnifier software,
and for these users your slick visual design can be more of a hindrance than
a help.
Some users won’t even visit your site, preferring to read content feeds in RSS or
similar formats if you offer them. When it comes time to build these feeds, you’ll
want to be able to send your HTML content to these users without any JavaScript
or CSS junk.
The key to accommodating the broadest possible range of visitors to your site is to
think of the Web in terms of three layers, which conveniently correspond to the
three kinds of code I mentioned earlier. These layers are illustrated in Figure 1.2
When building a site, we work through these layers from the bottom up:
1. We start by producing the content in HTML format. This is the base layer, which
any visitor using any kind of browser should be able to view.
2. With that done, we can focus on making the site look better, by adding a layer
of presentation information using CSS. The site will now look good to users able
to display CSS styles.
3. Lastly, we can use JavaScript to introduce an added layer of interactivity and
dynamic behavior, which will make the site easier to use in browsers equipped
with JavaScript.
If we keep the HTML, CSS, and JavaScript code separate, we’ll find it much easier
to make sure that the content layer remains readable in browsing environments
where the presentation and/or behavior layers are unable to operate. This “start at
the bottom” approach to web design is known in the trade as progressive enhancement.
Let’s look at each of these layers in isolation to see how we can best maintain this
separation of code.
next
of programming. It makes it easier to reuse portions of that code in future projects,
it reduces the amount of duplicate code you end up writing, and it makes it easier
to find and fix problems months and years later.
When it comes to the Web, there’s one more reason to keep your code separate: it
lets you cater for the many different ways in which people access web pages.
Depending on your audience, the majority of your visitors may use well-appointed
desktop browsers with cutting-edge CSS and JavaScript support, but many might
be subject to corporate IT policies that force them to use older browsers, or to browse
with certain features (like JavaScript) disabled.
Visually impaired users often browse using screen reader or screen magnifier software,
and for these users your slick visual design can be more of a hindrance than
a help.
Some users won’t even visit your site, preferring to read content feeds in RSS or
similar formats if you offer them. When it comes time to build these feeds, you’ll
want to be able to send your HTML content to these users without any JavaScript
or CSS junk.
The key to accommodating the broadest possible range of visitors to your site is to
think of the Web in terms of three layers, which conveniently correspond to the
three kinds of code I mentioned earlier. These layers are illustrated in Figure 1.2
When building a site, we work through these layers from the bottom up:
1. We start by producing the content in HTML format. This is the base layer, which
any visitor using any kind of browser should be able to view.
2. With that done, we can focus on making the site look better, by adding a layer
of presentation information using CSS. The site will now look good to users able
to display CSS styles.
3. Lastly, we can use JavaScript to introduce an added layer of interactivity and
dynamic behavior, which will make the site easier to use in browsers equipped
with JavaScript.
If we keep the HTML, CSS, and JavaScript code separate, we’ll find it much easier
to make sure that the content layer remains readable in browsing environments
where the presentation and/or behavior layers are unable to operate. This “start at
the bottom” approach to web design is known in the trade as progressive enhancement.
Let’s look at each of these layers in isolation to see how we can best maintain this
separation of code.
next
Keep ’em Separated
Keep ’em Separated
Not so long ago, professional web designers would gleefully pile HTML, CSS, and
JavaScript code into a single file, name it index.html,2 and call it a web page. You
can still do this today, but be prepared for your peers to call it something rather less
polite.Somewhere along the way, web designers realized that the code they write when
putting together a web page does three fundamental things:
■ It describes the content of the page.
■ It specifies the presentation of that content.
■ It controls the behavior of that content.
They also realized that keeping these three types of code separate, as depicted in
Figure 1.1, made their jobs easier, and helped them to make web pages that work
better under adverse conditions, such as when users have JavaScript disabled in
their browsers.
Now, realizing this is one thing, but actually doing it is another—especially if you’re.
not a computer geek. I am a computer geek, and I’m tempted to do the wrong thing
all the time.
I’ll be happily editing the HTML code that describes a web page’s content, when
suddenly I’ll find myself thinking how nice that text would look if it were in a
slightly different shade of gray, if it were nudged a little to the left, and if it had that.
hee-larious photocopy of my face I made at the last SitePoint office party in the
background. Prone to distraction as I am, I want to make those changes right away.Now which is easier: opening up a separate CSS file to modify the page’s style sheet,
or just typing those style properties into the HTML code I’m already editing?
Like behaving yourself at work functions, keeping the types of code you write separate
from one another takes discipline. But once you understand the benefits, you
too will be able to summon the willpower it takes to stay on the straight and narrow.
next
Not so long ago, professional web designers would gleefully pile HTML, CSS, and
JavaScript code into a single file, name it index.html,2 and call it a web page. You
can still do this today, but be prepared for your peers to call it something rather less
polite.Somewhere along the way, web designers realized that the code they write when
putting together a web page does three fundamental things:
■ It describes the content of the page.
■ It specifies the presentation of that content.
■ It controls the behavior of that content.
They also realized that keeping these three types of code separate, as depicted in
Figure 1.1, made their jobs easier, and helped them to make web pages that work
better under adverse conditions, such as when users have JavaScript disabled in
their browsers.
Now, realizing this is one thing, but actually doing it is another—especially if you’re.
not a computer geek. I am a computer geek, and I’m tempted to do the wrong thing
all the time.
I’ll be happily editing the HTML code that describes a web page’s content, when
suddenly I’ll find myself thinking how nice that text would look if it were in a
slightly different shade of gray, if it were nudged a little to the left, and if it had that.
hee-larious photocopy of my face I made at the last SitePoint office party in the
background. Prone to distraction as I am, I want to make those changes right away.Now which is easier: opening up a separate CSS file to modify the page’s style sheet,
or just typing those style properties into the HTML code I’m already editing?
Like behaving yourself at work functions, keeping the types of code you write separate
from one another takes discipline. But once you understand the benefits, you
too will be able to summon the willpower it takes to stay on the straight and narrow.
next
Jumat, 15 Januari 2010
The Three Layers of the Web
Once upon a time, there was … ‘A king!’ my little readers will say right away. No,
children, you are wrong. Once upon a time there was a piece of wood…
—The Adventures of Pinocchio
You can do a lot without JavaScript. Using Hypertext Markup Language (HTML),1
you can produce complex documents that intricately describe the content of a
page—and that content’s meaning—to the minutest detail. Using Cascading Style
Sheets (CSS), you can present that content in myriad ways, with variations as subtle
as a single color, as striking as replacing text with an image.
No matter how you dress it up, though, HTML and CSS can only achieve the static
beauty of the department store mannequin—or at best, an animatronic monstrosity
that wobbles precariously when something moves nearby. With JavaScript, you can
bring that awkward puppet to life, lifting you as its creator from humble shop clerk
to web design mastery!
1 Throughout this book, we’ll refer to HTML and XHTML as just HTML. Which you choose is up to you,
and doesn’t have a much to do with JavaScript. In case it matters to you, the HTML code we’ll present
in this book will be valid XHTML 1.0 Strict.But whether your new creation has the graceful stride of a runway model, or the
shuffling gait of Dr. Frankenstein’s monster, depends as much on the quality of its
HTML and CSS origins as it does on the JavaScript code that brought it to life.
Before we learn to work miracles, therefore, let’s take a little time to review how to
build web sites that look good both inside and out, and see how JavaScript fits into
the picture.
next
children, you are wrong. Once upon a time there was a piece of wood…
—The Adventures of Pinocchio
You can do a lot without JavaScript. Using Hypertext Markup Language (HTML),1
you can produce complex documents that intricately describe the content of a
page—and that content’s meaning—to the minutest detail. Using Cascading Style
Sheets (CSS), you can present that content in myriad ways, with variations as subtle
as a single color, as striking as replacing text with an image.
No matter how you dress it up, though, HTML and CSS can only achieve the static
beauty of the department store mannequin—or at best, an animatronic monstrosity
that wobbles precariously when something moves nearby. With JavaScript, you can
bring that awkward puppet to life, lifting you as its creator from humble shop clerk
to web design mastery!
1 Throughout this book, we’ll refer to HTML and XHTML as just HTML. Which you choose is up to you,
and doesn’t have a much to do with JavaScript. In case it matters to you, the HTML code we’ll present
in this book will be valid XHTML 1.0 Strict.But whether your new creation has the graceful stride of a runway model, or the
shuffling gait of Dr. Frankenstein’s monster, depends as much on the quality of its
HTML and CSS origins as it does on the JavaScript code that brought it to life.
Before we learn to work miracles, therefore, let’s take a little time to review how to
build web sites that look good both inside and out, and see how JavaScript fits into
the picture.
next
Langganan:
Postingan (Atom)
