This is a bit off-topic, but since Peter appears to have missed the
point of my post I feel I must reply. It may also be interesting to
the list.
On 12 May 2008, at 14:43, Peter Ford wrote:
Stut wrote:
On 12 May 2008, at 09:39, Peter Ford wrote:
tedd wrote:
Hi gang:
This is what I did this morning:
http://webbytedd.com/bb/tribute/
It speaks for itself.
Cheers,
tedd
tedd,
Nothing to do with the subject matter, but I noticed because it is
one of your more simple pages: I get a JS "urchinTracker() not
defined" error on your site, almost certainly because NoScript is
blocking UrchinTracker...
Perhaps you should wrap that naked call to urchinTracker() in a
conditional - maybe as simple as
if (urchinTracker) urchinTracker();
<pet-peeve>
I really hate seeing JS errors on published sites (i.e. not
development sandboxes)
</pet-peeve>
'course, there are many sites that make the same call to
urchinTracker(), and many many worse errors...
I see your pet peeve and I'll raise you one of mine...
<pet-peeve>
People who use Javascript blockers, especially Javascript blockers
that do a half-arsed job which causes errors.
</pet-peeve>
If you're going to block Javascript, block it. Don't use something
that tries (and apparently fails) to block it intelligently.
What are you so afraid of?
-Stut
Your pet peeve seems to be a rather thinly veiled personal attack -
I tried to be clear to tedd that my comment was not personal, but
highlighted by his page.
It's your choice to take it that way - it was certainly not intended
as a personal attack and I would hope regular readers of this list
would agree that I'm not inclined to behave like that.
Javascript is a very powerful but rather blunt instrument, and I
prefer to be judicious in my use of power.
Blunt in what way? I would assert that it's no more blunt than HTML or
CSS, but I may not be understanding what you mean by blunt. Javascript
can be written such that it eats CPU and/or memory but this is of no
benefit to anyone so unless you're running on a prehistoric machine I
can't see that being an issue. And it's worth noting that even if a
script starts hammering the machine most browsers these days will
notice that, suspend it and offer to kill it.
NoScript is not causing the error. The absence of UrchinTracker is
causing the error. I choose not to allow UrchinTracker into my system.
It is causing the error since it has blocked loading the external file
but not the call to the code it contains. This, to me at least, seems
half-arsed. The error only exists on the page if you deny it something
that it needs to run correctly. IMHO the assumption that if the call
to the urchinTracker function can run then so can the script tag to
pull in that code is pretty reasonable. In fact I make it all the time
in the code I write and I think the same would go for 99.999% of
developers using Javascript.
NoScript is certainly not doing a half-arsed job - it's working
perfectly, unless you think I should suffer extra CPU cycles while
the browser parses every line of Javascript to see what will happen
before running it. That would be a job for a compiler, rather than a
scripting engine.
What I'm most "afraid" of are assumptions that something I didn't
ask for exists in the environment I use to work in. If a page
features a message that says "we use Urchin Tracker to (...whatever
it is that Urchin Tracker does...) and you may see errors if you
block it", then I can understand.
Urchin Tracker is a simple(!) analytics package and poses no danger to
you or your computer. In fact I would suggest it's anti-productive to
block it since it prevents the sites you visit from using the data it
provides to modify their site to make the experience better for you.
What I also am "afraid" of is that I don't know everything that I
should be afraid of - using NoScript is a good way of giving me
chance to research the stuff that is being pushed into my browser.
Of course, in some cases I don't feel the need to research, and
block unconditionally until I see a problem with that approach.
That's fine, and at the end of the day that's your choice. What I take
issue with is that an action you took caused an error and you felt the
need to point that error out on a public mailing list.
That error is caused by your use of selective Javascript-blocking
technology, and while I work very hard to ensure the sites I develop
work as well as possible without Javascript I think it's unreasonable
to expect them to work with selective blocking.
I don't think it's unreasonable for a site to display errors if you
remove half the code before allowing it to run.
A developer should not make assumptions about the existence of a
feature in the target system - he should specify requirements and
let the end-user decide if his product is acceptable, or check that
a feature is present and work around it if not.
I agree that if you're using features of Javascript provided by the
browser, such as XMLHttpRequest, you should check that it exists
before calling it. However, when your site is providing code I don't
think it's unreasonable to assume that if some of it runs all of it
will run.
I can even tolerate "This site requires Internet Explorer 5.3 or
later" (as my credit card company does) if the providers are upfront
about it...
But here's the thing... Tedd's site does not *require* Javascript.
Well, some of his pages do but that's complicating the issue. As far
as I can tell the only bit of Javascript common to all Tedd's pages is
the Google Analytics code which is not required for you to use the
site, it just enhances the ability for Tedd to analyse how people are
using it.
I don't consider being afraid as a weakness - but blasé indifference
to danger can be a fatal weakness.
It can and I care greatly about security, but Javascript is very well
locked down these days, and it's fairly difficult to get it to do
anything malicious. Can it do annoying things, yes (but rarely these
days, and usually only on 'special' sites), but I've not come across
anything malicious for quite some time.
In summary I can understand where you're coming from, and it's totally
your choice to use something that modifies your browsing experience,
but to then complain that it's causing errors on the sites you visit
is, to me, beyond ridiculous. That's all I was trying to point out.
-Stut
--
http://stut.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
