2008/5/13 Stut <[EMAIL PROTECTED]>: > > On 13 May 2008, at 10:32, Robin Vickery wrote: > > > 2008/5/13 Stut <[EMAIL PROTECTED]>: > > > > > On 13 May 2008, at 09:04, Peter Ford wrote: > > > > > > > > > > I think the onus is on the coders of Urchin to document how to avoid > > > > > > > errors when Javascript is disabled, not the site developer who uses it. > > > > > > Just to repeat a point I made yesterday which was clearly either > > > misunderstood or ignored... Urchin *will not* cause Javascript errors if > > > Javascript is disabled. Odd though it may seem, it's actually not > possible > > > to write Javascript code that will cause Javascript errors if Javascript > is > > > disabled. > > > > > > If you choose to use an addon that disables some Javascript but not all > of > > > it you need to be willing to live with the errors that may cause. > > > > > > > While I completely agree with everything you say there, I do think there > is a > > point to the other side side of the argument as well; It *is* sloppy > > practice to > > assume that some resource has already been initialised without checking, > > especially when you're relying on a third-party script. > > > > I agree to a certain extend, but the Javascript spec specifies that it's > executed in the order it's found on the page. So if you include an external > file before calling the code it contains it's perfectly acceptable to assume > that code has already been included, parsed and is available to you.
There's so many things that are out of your control when you include a third-party script that could stop it loading; misconfigured servers on their end, network outages, corporate firewalls blocking their server, etc. You can't stop any of that. But you can check for it very simply. But hey, we basically agree. So I'm going to stop there, before I start getting too involved in arguing the point. -robin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
