HTML and CSS Reference
In-Depth Information
provides the highest value.
Writing
the test, including all the surrounding thought
process is what we primarily learn from. Keeping the tests allows us to revisit a
given exercise at a later time, or run it in a newly discovered browser to see if our
experience still serves us well. Browsing through a suite of learning tests written by
someone else might provide a few nuggets of information, but is unlikely to embed
knowledge inside our brains the same way writing learning tests does.
4.1.1 Pitfalls of Programming by Observation
When we talk about JavaScript, we are really talking about several dialects; Mozilla's
JavaScript
™
, Microsoft's JScript and Webkit's JavaScriptCore to name a few. These
all stem from the original JavaScript language invented by Netscape and have
their common ground in ECMA-262, or ECMAScript, a standardization of that
very language. Because we are really targeting several dialects when writing client
side scripts, there is no canonical source of information of the kind we retrieved
in the two learning tests from the previous section. In other words, there is no
authoritative interpreter to ask for information about JavaScript—they all have
their bugs and quirks, they all have their proprietary extensions, and their mar-
ket share is more evenly distributed than ever (even though Microsoft still domi-
nates with Internet Explorer versions 6-8 combined)—meaning there are no single
browser that can be considered “best,” our scripts will have to run in all of them
anyway.
Because there are so many versions of the language in active use, we cannot
blindly trust the results of some statements run in a single browser alone. And
when results differ between browsers, which one do we trust? When in doubt, we
need to consult the source—the ECMA-262 specification. When browsers behave
differently on language features, we need to consult the spec they are trying to im-
plement to understand properly what the correct answer is. Only when we know
how something is intended to work can we get to work fixing it, either by over-
writing the built-in implementation for misbehaving browsers, or by providing an
abstraction.
By writing the two learning tests in the previous section, we learned a few
things about the
Array.prototype.splice
method by observing the results
of running our test in a browser. Drawing conclusions based on a small sample of
observations can prove to be a dangerous approach, especially when dealing with
browser differences.
White-space matching in regular expressions using
\
s
is an example of how
observations may lead us astray. Until recently, no implementation correctly matched
all white-space characters defined by ECMA-262. Tests for certain white-space
