lawrence wrote:
[color=blue]
>[/color]
<shortened>[color=blue]
>
> Nice to know. Those are two functions that played a role in the old
> design but are useless in the new design.
>
> On another subject, where do you learn all this stuff? I'm wondering
> where I can find out stuff like this, other than newsgroups. In
> particular, cross-browser stuff seems tough to glean from the
> reference material, which tends to talk about EMCAscript as a
> stand-alone ideal, or talks about how any particular browser does
> things.[/color]
ECMAScript is a nice idea, and it has gone a long way in standardizing
the language (and to some extent, stunting it as well), but JScript and
JavaScript have managed to keep certain aspects of their respective
languages "proprietary" -- so there is a "core" JavaScript/JScript that
are ECMA compliant and there are extra features to both that are
exclusive to each (most documentation will tell you which parts are ECMA
compliant). They are, roughly, about 95% (or better) compatible. It's
when you start interacting with other parts of the environment that are
"exposed" to JS that things "get interesting." On the upside:
cross-browser issues seem to have considerably lessened in the last
couple of years.
There is plenty in the way of online documentation for dealing with
various scripting languages and DOMs...
For JavaScript, I live by this:
http://devedge.netscape.com/library/...erenceJS13.zip
This is NOT the latest information, but it is the one that is the best
presentation -- you can go back for the JS1.5 reference as an addendum.
Download it and install it in a convenient location -- Bookmark the index...
The corresponding guide is okay -- but mostly unused -- you'll probably
never need it.
For a DOM reference, I like:
http://msdn.microsoft.com/library/de...ence_entry.asp
for best results, you should probably view this site in IE6 if you're
using a PC. If you navigate around, you'll find Scripting (->JScript)
documentation there as well (but it's generally pretty bad.)
If after these two, I run into trouble with mozilla, I'll go to the source:
http://www.mozilla.org/catalog/web-developer/
or
http://www.mozilla.org/docs/dom/domref/
I occasionally will shortcut through all of this by checking:
http://javascript.faqts.com first... A lot of questions have been
answered there and it's fairly easily searched [plus, under the
Documentation column, there are many links like the ones I've referenced
for you available there.]
[color=blue]
>
>
>
>
>
>
>
>[color=green]
>>BTW -- these two
>>errors appear in the JavaScript Console in Netscape/Mozilla apps as
>>Error: functionName is not defined.
>>
>>declare the functions (even if they are empty for now):
>>(e.g.:)
>>function
>>scrollTop()
>>{
>>}
>>
>>... or remove the handler references.[/color]
>
>
>
> I'll remove the handler references.
>
>
> But let me get philosophical for a momement. Javascript is a script
> language. It's suppose to break with maximum grace, yes? It isn't
> Java, one isn't expecting strong typing or a maximum of rule
> enforcement. So why does IE die on an error like this?[/color]
[guessing:] I'd have to say because they are event handlers... IE
doesn't usually stop executing scripts for relatively minor errors.
Technically, IE does not "die" with this, it just stops executing your
scripts... or parts of your scripts... You can't really "nail" IE with
this one, mozilla will do some pretty weird things sometimes with a
messed up script [like things will work up to a point, then whole layers
will just disappear!!!]. The point is: if there is an error in the
script, it needs to be fixed. It's actually "poor form" to release a
page to the public with errors on it... especially if it's IE (the
majority) since it's plainly visible from the front of the browser that
there are problems with a script.
[*you'll see a small yellow triangle icon in the lower left corner of
the browser with "Error on Page" in the status bar when there is an
error on the page -- double clicking on it will give you the line number
of the error and some arcane message like "Object expected" (big help
<sarcasm>)-- you can usually figure out what the problem is inpecting
the code where the error occurs. Unfortunately, IE's reporting can be
"off" from your source code, so what I usually do is View Source, then
copy and paste the code as "IE sees it" and then track down the line
number of the error (this seems to work in most cases -- find an editor
that displays line numbers like Crimson Editor or similar) -- otherwise,
use Netscape's(/mozilla's) JavaScript Console][color=blue]
>[/color]
Why not just[color=blue]
> throw a warning and move on? Given the environment it works in, I'd
> think there would be premium on allowing a script to work if at all
> possible.[/color]
I think you can change a couple of settings in Tools -> Internet Options
[Advanced] [] Disable Script debugging and/or [] Display a notification
about every script error -- you'll want to uncheck the first one and
check the second.
[color=blue]
> What is Microsoft's reasoning here?[/color]
I'll venture a guess that it has to do with *their* idea of your
convenience.
I mess around with my settings every so often, so I don't remember if
the debugging settings are default, or something I chose to deselect...I
find the script error notification to be truly annoying when surfing...
