Omissions are inevitably too numerous to list. With a subject so vast
there is little chance of covering everything in 14 short pages.
However, one serious omission arises from providing example mark-up in
XHTML style while promoting browser-scripting strategies that will fail
if they are exposed to an XHTML DOM. That contradiction really deserves
some words of explanation.
It is also a significant omission not to explain the extent to which the
example code is IE only (or at least effective only in IE and it's close
imitators) and/or relies on browsers operating in 'quirks' mode.
While the majority of the approaches and techniques presented are
sub-optimal (in the code they use and in cross-browser scripting terms)
actual errors mostly relate to the discussion and examples of (X)HTML
mark-up. This is well illustrated by this section opening paragraphs:-
<quote
cire="
http://www.geocities.com/binnyva/code/javascript/advanced_tutorial
/">
JavaScript or JScript is a language that can be seen as the next step
from HTML. HTML is concerned with the simple display and presentation of
text and images. JavaScript offers more interactivity for the user and
above all more choice and understanding of the world wide web.
</quote>
-, the many examples of invalid mark-up, and particularly this section:-
<quote
cite="
http://www.geocities.com/binnyva/code/javascript/advanced_tutorial
/div_span.html">
Span is a tag very similar to DIV in its properties. The difference
between the two is the while the DIV is a block-level element, SPAN is
an inline element. Both DIV and SPAN are grouping elements. The DIV and
SPAN elements, in conjunction with the id and class attributes, offer a
generic mechanism for adding structure to documents.
So when do you use SPAN and when do you use DIV? Use DIV if you want do
enclose lengthy contents or if the enclosed text will have HTML tags in
them. Use span for enclosing very small contents.
....
<style type="text/css">
div.thequote {
border:1px dashed black;
padding-left:50px;
padding-right:50px;
}
span.quoter {
padding-left:40px;
font-style:italic;
}
</style>
<div class="thequote">I accidentally shot my father-in-law
while deer hunting. It was an <u>honest</u> mistake.
I came out of the tent in the morning and thought <b>I saw
a deer in an orange vest making coffee</b>.<br />
<span class="quoter">Steven Wright</span></div>
If you are serious about web development, you should know these two tags
very well - they have awesome powers. These tags in alliance with CSS
are currently posing a great threat to the other tags. If these two tags
and CSS had their way, many old and obsolete tags would die - the first
to go will be the font tag. Next in line will be other tags like
b(bold) - will be replaced by <strong>, i(italics) - to be replaced by
<em>, etc. I have even heard reports that div is going to replace the
old(and faithful) table tag in layout! These tags with some others are
promising to bring about the HTML utopia - the separation of design and
content.
</quote>
Which demonstrates an apparent absence of technical understanding of
HTML mark-up.
Every tutorial has its pros and its cons. The cons is that
there are zillions of tutorials floating around,
There is nothing wrong with having zillions of tutorials around.
the pros are that with every
tutorial you might learn something new.
The expression that a little knowledge can be a dangerous thing can be
very applicable to javascript tutorials fond on the Internet.
Besides, writing or developing such a tutorial allows
(and in the end requires) you to understand the
presented matter.
Unfortunately that just is not true. It is true of writing a good
tutorial, by which I mean a tutorial that is complete, technically (and
otherwise) accurate, useful and capable of being understood by its
readers. Writing a bad tutorial requires no more than an ability to
churn out words (and certainly no understanding of the subject).
The problem with having zillions of tutorials available on the Internet
is that they range in quality form the very good to the catastrophically
bad, and that the vast majority (numerically) are at the bottom end of
that spectrum.
There is nothing to stop anybody writing a javascript "tutorial" and
publishing it on the Internet. A significant factor in their doing so is
their confidence in their own abilities and knowledge of the subject.
And confidence can be derived from superficial achievement, and
bolstered by isolation and an under-awareness of the full set of issues
that apply to Internet browser scripting.
A newcomer to the language, having learnt to (more of less) use the
language constructs will frequently find themselves massively frustrated
by their first exposures to having to get scripts to operate in more
than one browser (and people still talk of "both browsers", when there
are at lest 5 distinct flavours of dynamic visual browser in current
use, let alone all the other scriptable but less dynamic, or less
visual, browsers). Having experienced the initial extreme of frustration
the achievement of getting even one non-trivial script (say, a drop down
menu or similar) to satisfy some demonstrable criteria of "working" in
two or three test browsers can be a massive boost to the self-confidence
of its author.
I know that that was how it worked for me, and find it difficult to
express my gratitude towards the regulars of this group for totally
destroying my confidence in my own ability to script web browsers in
very short order after I started to post here. Without that I would not
now be in a position to appreciate how little I really understood at the
time, and how misplaced that initial confidence was.
Writing an explanation of a subject (that may take the form of a
tutorial, or be regarded as such) actually is a very good way of testing
your own understanding of a subject. If you can explain something to
someone else in a way that they understand then the chances are very
good that you understand what you were explaining yourself.
However, it is also possible to do a good job of explaining your
misconceptions to someone else such that they will share your
misconceptions, and unfortunately that is an issue with many web
tutorials. One way of avoiding that is to get critical feed-back about
your understanding and explanations from suitably qualified individuals.
In this respect participating in technical newsgroups is extremely
valuable as it presents an opportunity to try to provide technical
explanations on specific aspects of a subject under the scrutiny of at
least some individuals with a potentially better understanding, and so
misconceptions (and unconsidered issues) are likely to be raised in
response. And you often get to find out how well the individual
receiving the explanation understood it from how they respond.
It is probably the experience of critical feed-back that makes for a
good tutorial, but is would be best if that experience was gained prior
to writing the tutorial. Asking for a review of a completed tutorial is
probably better than nothing (assuming a willingness to re-write it in
response) but it is not very practical for anyone to make a full
response to 14 wide-ranging pages littered with incomplete and dubious
advice, and so the types of response elicited are likely to be easily
dismissed (to the detriment of the result).
Unfortunately a very low average quality also blights books on
javascript. I recall reading an example chapter from a javascript book
that featured the word "advanced" in its title, to find it filled with
bad advice, (IE) browser specific code and examples that would be better
described as needlessly convoluted than advanced.
"Advanced" is of course a relative term, and depends on where you are
observing from. The 'tutorial' mentioned above does not deserve the
label as its contents and subjects are very run of the mill browser
scripting. I am reminded of the interview for my current job, which was
advertised a requiring "advanced DHTML", and for which the interviewers
set a 'technical' test. I found that test very disappointing as it
hardly probed the knowledge of the candidates at all, requiring no more
than a broad familiarity with the more commonly used features of a
browser's object model, some familiarity with CSS and the ability to
recognise some really glaring syntax errors.
I stated after the test that I thought anyone who did not get 100%
should not be employed to script web browsers at all, and later
discovered that one of the reasons that I was offered the job was that
none of the other candidates had passed that same test. Which means that
every other applicant had believed themselves capable of writing
"advanced DHTML"[1] while actually not being qualified to script
browsers at all (or they were planning of trying to wing it).
[1] An alternative explanation would be that they didn't take the job
adverts' wording seriously, which is actually understandable as most
browser-scripting related job adverts betray apparent incomprehension on
the part of the prospective employer as to what they actually want
(proposing as they do combinations such as graphic design and DHTML,
advanced javascript and Dreamweaver, and so on).
I am sorry, I didn't look for errors or omissions, but just
browsed through it and it has several neat thingamajiggys
in it ;-) one of them is the possibility (with the evil
"eval()") to execute your own javascript or test results.
One of the rare justified employments for the eval function is
demonstrating the execution of javascript source code. Which doesn't
alter the assertion that eval is almost never of use in javascript
authoring, as pages with javascript as their subject, using eval for
demonstration purposes are a very tiny proportion of the applications
of javascript.
now on this I have the following question, and I hope
someone can answer this:
I use Firefox (1.0.6) and on the page
at the end, you can "move" two <div>s containing jokes around.
when I initially load the page and write:
alert(document.getElementById("joke_2").style.left)
I get a blank alert box, but as soon as I write:
document.getElementById("joke_2").style.left = 120;
document.getElementById("joke_2").style.width = 290;
alert(document.getElementById("joke_2").style.left)
the alert box returns 120px.
That is an interesting observation that I will return to later.
Why is
document.getElementById("joke_2").style.left
blank at the beginning?
This is a common question and arises from an under appreciation of the
role of an element's - style - object, and the application of styles
through CSS. On a previous page in the 'tutorial' you find:-
<quote
cite="
http://www.geocities.com/binnyva/code/javascript/advanced_tutorial
/styles.html">
.... . The style can be anything that can be used as a CSS style. The
following format is to be used for all style changes.
document.getElementById('ID_OF_THE_ELEMENT').style.TYPE = 'NEW_VALUE';
The equivalent CSS statement will be
#ID_OF_THE_ELEMENT {
TYPE : NEW_VALUE;
}
An example
document.getElementById('name').style.color = 'blue';
And the CSS will be
#name {
color : blue;
}
</quote>
- in which the property of the - style - object is equated with the type
of style declaration that you would find in a STYLE element or an
external style sheet.
CSS may be declared/defined in many ways in an HTML document. It may be
found in external style sheets (imported as files), it may be found on
the page in STYLE elements, e.g.:-
<style type="text/css">
..someClass {
position:relative;
}
</style>
- or it may be specified as an attribute of an element, e.g.:-
<div style="position:relative;"> ... </div>
How CSS rules are applied to HTML elements is determined by a number of
factors. There is the cascade (the C in CSS), in which the last
(applicable (possibly by media type)) rule encountered overrides
equivalent properties from rules previously encountered. And there is
specificity, where the most specific rule applies to any given element.
The CSS specification is the best guide to how these mechanisms work.
However, the style attribute of an element is the most specific way of
assigning CSS to an element and so the contents of a style attribute
override all other CSS rules (well almost, as rules that are declared as
!Important can still come into play (useful in print style sheets where
elements dynamically positioned/hidden through their style attributes
may need more printer-friendly styling)).
In the DOM, an Element object's - style - property is the representation
of the element's style _attribute_ in the HTML, only. It does not
represent the CSS applied to an element through style sheets or
declarations in STYLE elements on the page, only the contents of the
style attribute.
Thus if you read from a property of an Element's - style - object you
will only initially find values where those values are assigned in the
style attribute in the HTML.
If you assign values to the (recognised) properties of an Element's
style object you are effectively re-defining its style attribute (this
is in terms of the live DOM and may not be reflected in values read
using getAttribute('style') on the element). Such assignments are an
effective mechanism for setting CSS values because it is in the nature
of the style attribute to override all other CSS assignments in other
locations.
shouldn't the style be computed and
filled in by the agent?
The style is computed, and computed styles are available on W3C DOM
styles implementing browser through the getComputedStyle method of the
defaultView interface, and on IE 5+ through the currentStyle object that
is also a property of Elements (though currentStyle properties are not
as accurately representative as those derived from the getComputedStyle
method, where available).
But because the style property of elements is a representation of the
style attribute in the HTML it should not initially be assigned values
that do not appear in the attribute in the HTML. That is; it is not a
general representation of an element's applied styling, but just the
representation of the element's style attribute.
Returning to your observation that the alert reported "120px" when you
had assigned the numeric value 120; the Rules of CSS require that
non-zero length values explicitly state the units in which they are
defined (px, pt, em, cm, and so on). Internet Explorer has always
error-corrected values provided without the CSS units, assuming that
they are px values and assigning the value as a string with 'px' on the
end. Other browsers have sometimes followed IE in this respect, others
follow IE in "quirks" mode and insist upon correct CSS in "strict" mode
(and there are probably browsers that are always strict in their
interpretation of CSS, though I cannot think of any right now).
The practical upshot of this is that if you omit the CSS units from an
assignment you are writing code that will not function under some
circumstances. If, on the other hand, you habitually include the CSS
units you will be writing code that will work exactly the same on all
of the browsers (and in all of the circumstances) where assigning just
the number would work, and also work on all the browsers (and in all
of the circumstances) where a correct CSS value would be required.
E.G.:-
document.getElementById("id").style.top = 120+'px';
Generally, where one approach is available that satisfies all of the
browsers that are capable of a particular action (setting properties on
an element's style object in this case) it is best to learn to always
use that approach habitually, rather than having to think about whether
you can get away with omitting the CSS units (as might be practical on
an IE only Intranet).
Richard.
